Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

project template / candidate

Experiment run — field guides

The distinct field guides record for Experiment run. This page is proposal-only.

Status: proposedLifecycle: candidate

Record status

Record ID
project:experiment-run
Parent lifecycle
candidate
Page lane
app_features
Lane lifecycle
proposed
Owner
Not separately recorded
Owner role
Not separately recorded
Owner status
Not separately recorded
Qualification result
NOT RUN · held for evidence and human review

Working browser surface: Project templates & workflows — overview — Create a local project from this template and validate its forms. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held.

Related field-guide records

  • /app/notebook/field-guides/

Source-proposed guide paths are references, not proof that those paths resolve.

Operating sequence

  1. Create the project record from the intake request and assign an owner.
  2. Record the decision question, hypothesis, success definition, and explicit exclusions.
  3. Draft the protocol, controls, measurements, stop conditions, and limitations.
  4. Create milestones and calculate a workback from the decision deadline.
  5. Assign owners and record dependencies, readiness conditions, and fallback paths.
  6. Define fixtures, setup checks, evidence requirements, and accessibility needs before any run.
  7. Submit protocol and setup for human approval; keep the project held if approval is missing.
  8. Create one run record per planned run and preserve operator, input, fixture, and evidence references.
  9. Record failures and deviations immediately; disposition affected runs before interpretation.
  10. Assemble evidence and trace each material result to a source-labelled record or file reference.
  11. Write interpretation separately from observation, disclose assumptions, and hold unsupported claims.
  12. Route protocol changes, validity decisions, interpretation, and closure through approvals.
  13. Run the closure checklist, preserve receipts and revisions, create follow-up work, and mark unresolved items held.

Handoff boundary

  • Treating a proposed project form as evidence that an experiment occurred.
  • Confusing a native app route with a connected provider or production feature.
  • Allowing unapproved protocol changes to be interpreted as comparable runs.
  • Losing source provenance, revisions, custody notes, or evidence links.
  • Overstating results when controls, sample size, uncertainty, failures, or deviations are incomplete.
  • Silent deadline changes or automatic completion hiding schedule risk.
  • Assigning responsibility without acknowledgement or a backup owner.
  • Uploading or exposing sensitive files when only local file references are supported.
  • Using inaccessible status indicators, unlabeled controls, or keyboard-inaccessible multi-step forms.
  • Publishing customer, provider, credential, database, or production claims from local prototype records.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

  • source_record:project:experiment-run
  • NotebookCollectionKind.project
  • NotebookTodoPayload.dueAt
  • Notebook Agenda deadlines/workbacks
  • Notebook records provenance and revisions
  • PointGuard persistent cross-app context surface
  • /app/notebook/projects/
  • /app/notebook/to-dos/
  • /app/notebook/agenda/
  • /app/notebook/approvals/
  • /app/notebook/files/
  • /app/notebook/capture/
  • /app/notebook/agent-logs/
  • APP_ROUTES /app/notebook/projects/
  • APP_ROUTES /app/notebook/agenda/
  • APP_ROUTES /app/notebook/approvals/
  • APP_ROUTES /app/pointguard/
  • ALLOWED_INSTRUMENTS:scientific-calculator
  • ALLOWED_INSTRUMENTS:statistics-suite-descriptive-stats
  • ALLOWED_INSTRUMENTS:date-duration-calculator