Experiment run — qualification

Record status

Record ID

project:experiment-run

Parent lifecycle

candidate

Page lane

qualification

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.

Qualification status

Result

NOT RUN

Disposition

HELD

Reviewer

Not recorded

Receipt

Not recorded

This page defines proposed acceptance criteria for the qualification lane. It does not execute tests, establish compliance, qualify the subject, or authorize an effect.

Outcome definitions

Verified

All stated evidence and acceptance requirements passed for the exact reviewed revision; this still does not authorize deployment or an external effect.

Failed

One or more deterministic acceptance requirements failed with an inspectable reason.

Needs review

Evidence or interpretation is incomplete, conflicting, or awaits an identified human reviewer.

Held

Authority, required evidence, safe execution conditions, or a principal gate is absent.

The current record remains NOT RUN / HELD. These definitions describe candidate outcomes only.

Proposed deterministic acceptance tests

Route-resolution and distinct-content checks apply only to the admitted canonical routes in this record. Held source-proposed extensions are non-resolving proposals and are excluded.

• Reject submission when title, objective, owner, protocol summary, controls, or target completion date is missing.
• Reject duplicate canonical IDs and preserve the original ID across revisions.
• Reject malformed dates, missing timezone, inverted workback dates, and run counts below one.
• Reject a run plan whose identifiers are duplicated or whose required inputs and outputs are absent.
• Require a declared control condition or an explicit rationale for no control.
• Require stop conditions for experiments marked safety-sensitive or irreversible.
• Show field-level errors adjacent to fields and summarize errors at the form start.
• Do not create a completed or approved state from a draft submission.
• Create separate planned run records with stable links to the parent project.
• When a run fails, require failure reason, observed state, affected run identifier, and next action.
• A revision must preserve prior values, author, timestamp, source provenance, and a concise change summary.
• A destructive delete must require explicit confirmation, identify affected linked records, and offer hold or archive instead of silent deletion.
• A project with unresolved failures cannot enter closed or approved state.
• External messages, provider writes, publication, customer indexing, credential use, and database writes remain held and produce a visible held receipt.
• Unauthorized editors cannot change owner, visibility, approval state, deadlines, or delete/archive records.
• Search results must respect the visibility class and must not expose sensitive notes or file paths to unauthorized users.
• Keyboard-only users must reach every field, control, error, dialog, and status in logical order.
• Every control must have a programmatic label; required fields, invalid fields, and status changes must be announced without color alone.
• Focus must move to the error summary after failed submission and remain visible after dialogs open.
• The form must remain usable at enlarged text and narrow viewport widths without loss of content or horizontal scrolling for ordinary fields.
• Autosave or navigation failure must preserve the last confirmed revision and clearly label unsaved changes.
• A failed save must not report success or advance lifecycle; it must provide retry and local recovery guidance.
• Missing source references must yield a held provenance state rather than an implied verified result.
• If an instrument is later requested, it must be selected only from the allowed verified directory and exact slug.

Negative and held-state tests

• Confusing a planned run with an executed result.
• Silent deadline shifts causing missed work or invalid workback order.
• Editing a receipt or result in place and losing scientific history.
• Exposure of sensitive experiment inputs, notes, attachments, or file paths through search.
• Destructive deletion of linked runs, failures, or provenance.
• Agent or interface implying authority to send messages, write providers, publish, or alter production records.
• Accessibility failures that hide validation errors or lifecycle state.
• Partial saves producing contradictory project, to-do, agenda, or approval states.
• Unsupported interpretation presented as a verified conclusion.
• Using an unverified or unavailable instrument as evidence.

Qualification claim boundary

Potentially allowed only after the stated evidence

• This is a proposed project-record template.
• The native contract includes project collections, deadlines, revisions, provenance, lifecycle, and held external effects.
• The prototype routes identify intended local surfaces for projects, to-dos, agenda, notes, files, approvals, and logs.

Still held

• Deployment or production availability.
• Provider, credential, database, customer, publication, or external-calendar connection.
• Execution of an experiment or existence of experimental results.
• Qualification, approval, scientific validity, or safety certification.
• Persistent cross-surface synchronization beyond the observed native contract.

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 specialist-app ownership and held external effects
• /app/notebook/projects/
• /app/notebook/to-dos/
• /app/notebook/agenda/
• /app/notebook/approvals/
• /app/notebook/agent-logs/