Source: https://guthlabs.ai/docs/project-templates/experiment-run/qualification/ project template / candidate # Experiment run โ€” qualification The distinct qualification record for Experiment run. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## 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. ### Lane-specific instrument aids No verified instrument is assigned to this qualification lane. ## 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/`