Source: https://guthlabs.ai/docs/project-templates/instrument-qualification/forms/ project template / candidate # Instrument qualification โ€” forms The distinct forms record for Instrument qualification. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:instrument-qualification **Parent lifecycle**: candidate **Page lane**: forms **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. ## Proposed form sections Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth. ### Intake Define the qualification request, authority, target instrument records, and initial constraints. - request title - requester name or role - project owner - qualification reviewer - instrument slugs, selected only from the allowed verified-instrument directory - instrument record IDs or source locators - qualification objective - requested start date - target completion date - priority - visibility - sensitive-content flag - known constraints - intake notes - source references ### Scope Set explicit inclusion, exclusion, and qualification boundaries before work begins. - in-scope behaviors - out-of-scope behaviors - supported input types - expected output types - error and failure states to test - accessibility requirements - documentation requirements - evidence requirements - provider or credential effects to hold - publication or customer-facing effects to hold - scope acceptance statement - scope approver - scope approval date ### Milestones Create ordered deliverables with owners, dates, dependencies, and exit criteria. - milestone ID - milestone name - description - owner - planned start - planned finish - status - preceding milestone IDs - deliverable record IDs - exit criteria - reviewer - completion evidence IDs ### Deadlines and workback Translate the target completion date into dated, reviewable work items. - target completion date - workback convention and timezone - milestone due dates - task title - task owner - dueAt - priority - recurrence candidate - completion state - tags - revision note - scheduled or deadline view - buffer days - overdue handling - date-change reason ### Dependencies Track prerequisites and blocked work without hiding external effects. - dependency ID - dependency description - dependency type - blocking record or source locator - owning role - required-by date - status - verification method - fallback or workaround - blocked-since date - resolution note ### Owners and accountability Make record ownership and review responsibility explicit. - project owner - instrument owner per selected instrument - implementation owner - test owner - accessibility owner - documentation owner - approval owner - closure owner - backup role - handoff conditions - owner acknowledgement ### Tools and guides Declare the surfaces and procedures used for execution and review. - tool or route name - tool kind - intended use - canonical-record owner - guide record ID - specialist-app route - PointGuard context room - authority boundary - fallback if unavailable - usage note ### Evidence Preserve reproducible qualification receipts and source-labelled artifacts. - evidence ID - test case ID - instrument slug - input description - expected result - observed result - pass/fail/blocked - environment or prototype state - steps to reproduce - attachment or local file reference - source locator - source SHA-256 if available - captured by - captured at - revision - notes ### Approvals Require human review of scope, evidence, exceptions, and qualification outcome. - approval ID - approval stage - proposal summary - reviewer - decision: Needs review, Approved, or Held - decision date - evidence reviewed - exceptions accepted - required remediation - receipt or revision reference - next review date ### Risks and failure states Expose qualification hazards, mitigations, triggers, and escalation paths. - risk ID - risk statement - category - likelihood - impact - severity - trigger - mitigation - contingency - owner - status - review date - linked dependency - linked evidence - escalation condition ### Closure Record the final disposition, unresolved limitations, and retained receipts. - closure status: qualified, conditionally qualified, held, or not qualified - qualification decision date - decision owner - qualified instrument slugs - evidence completeness check - open risks and accepted limitations - unresolved dependencies - documentation completeness check - approval completeness check - handoff notes - retention or archive note - closure receipt - reopen condition ### Accessible state contract - Every field requires a visible and programmatic label. - Required and optional fields must be stated in text. - Invalid entries require an actionable message linked to the field. - Blocked and Held states remain visible without relying on color alone. ## Supporting documentation fields These fields come from the app_features lane and remain separate from the primary operating form. ### Project identity Define the local qualification project and its ownership boundary. - project title - instrument qualification scope - project owner - reviewers - project lifecycle - private visibility - description ### Instrument bindings Select verified instruments by exact directory slug and describe their intended use. - instrument slug - instrument name (directory-derived) - intended use - input assumptions - known limitations - binding status - source reference ### Qualification tests Capture reproducible local checks and evidence for each bound instrument. - test name - instrument binding - test category - test inputs - expected behavior - observed behavior - pass/fail/needs review - tester - tested at - evidence file reference - notes ### Hardening work Turn failures and risks into owned, deadline-bound work. - task title - risk or failure - owner - priority - due date - dependency - completion state - review required - linked test - linked record ### Deadline and workback Plan backward from a human review target without scheduling external effects. - review target date - milestone dates - buffer days - workback tasks - blocked dependencies - conflict notes - schedule status ### Qualification decision Preserve a reviewable local decision and its receipts. - decision state - qualification rationale - open risks - required follow-up - approver - approval date - receipt references - held external effects ## Required or proposed record references No record existence is asserted by this documentation page. - project record - selected instrument records with exact slugs - scope record - milestone records - deadline and workback to-dos - dependency records - owner assignments - tool and guide references - evidence records - approval records - risk records - closure record - instrument binding records - qualification test records - hardening task records - deadline and workback records - source-labelled file references - revision receipts ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:instrument-qualification` - `project:instrument-qualification` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Observed native contract: records, PointGuard, web boundary` - `/app/notebook/projects/` - `/app/notebook/to-dos/` - `/app/notebook/agenda/` - `/app/notebook/approvals/` - `/app/notebook/files/` - `/app/notebook/field-guides/` - `/app/notebook/agent-logs/` - `Notebook records canonical IDs, origin, source locators, source SHA-256, provenance, revisions, lifecycle, tags, links, and attachments` - `PointGuard persistent cross-app context surface` - `/app/pointguard/`