Experiment run — deadlines

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.

Deadline and workback rules

• A decision deadline is required before the project can leave intake planning.
• Every milestone must have an owner, planned finish date, output, and acceptance condition.
• The final evidence deadline must precede interpretation approval by at least one review interval recorded in the project.
• The last allowable run date must precede the final evidence deadline and include an explicit buffer.
• A dependency marked blocking must have a due date, owner, readiness evidence, and fallback or escalation path.
• Overdue items remain open until a person records completion, revised date, or held status; no automatic completion is implied.
• Any protocol change after the first completed run requires a new protocol revision and approval before affected runs are interpreted.
• Closure is blocked while required approvals, run dispositions, evidence review, or critical risks remain unresolved.
• Target run date is optional until supplied; no inferred date may be displayed as a commitment.
• When a target run date exists, generate local draft tasks for protocol freeze, fixture readiness, materials readiness, review, analysis, and receipt completion.
• Reject or visibly flag workback dates that fall after their dependent deadline.
• Show timezone and whether a deadline is planned, overdue, completed, or held.
• Recurring tasks remain candidates until a human confirms recurrence.
• Changing the target date creates a revision and preserves prior workback tasks rather than silently moving completed tasks.
• External calendar writes, reminders, messages, and notifications remain held.

Workback sequence

1. Create the experiment-run project record and assign an owner.
2. State the objective, hypothesis, variables, controls, fixtures, and stopping rules.
3. Add prerequisites and create local workback tasks from the target run date.
4. Freeze or revise the protocol before recording run results.
5. Create one run record per attempt and link the applicable protocol revision and fixture.
6. Record deviations and failures separately from observations; do not overwrite prior run history.
7. Link source-labelled files and receipts without implying upload or protected-storage completion.
8. Run bounded calculations and record inputs, outputs, assumptions, and instrument status.
9. Draft an interpretation with uncertainty and competing explanations.
10. Send the project to local review; preserve approval or held state and revision history.

Scheduling records

• milestone to-dos
• deadline and workback records
• dependency records
• owner assignments
• NotebookTodo records for deadlines and workback steps

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