Source: https://guthlabs.ai/docs/project-templates/instrument-qualification/qualification/ project template / candidate # Instrument qualification — qualification The distinct qualification 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**: 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 [checksum-verifieroptional · Verify recorded evidence hashes and detect accidental evidence changes.]()[wcag-contrast-ratio-checkeroptional · Check declared foreground/background pairs against the stated contrast threshold and record the result.]() ## 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. - Required-field test: submission is rejected when project owner, scope, exact instrument slug, qualification deadline, or decision state is absent; each error is adjacent to the relevant field and announced to assistive technology. - Slug test: an instrument reference is rejected unless its slug exactly matches an entry in ALLOWED_INSTRUMENTS; disposed or unlisted slugs cannot be added. - Status test: the record displays the directory status and does not convert VERIFIED_CLEAN into a claim of deployment, connection, publication, or production readiness. - Input validation test: each instrument test case defines field type, unit, allowed range, requiredness, decimal policy, and handling for blank, malformed, infinite, and out-of-range values. - Boundary test: minimum, maximum, zero, negative, decimal, duplicate, and large-but-supported inputs produce documented deterministic results or explicit held errors. - Expected-output test: repeated execution with identical inputs, instrument revision, and test configuration produces identical output or records a declared nondeterministic limitation. - Error test: invalid inputs prevent a pass result; the interface identifies the failing field, preserves entered values where safe, and offers a recovery path. - Dependency test: a blocked prerequisite prevents dependent work from being marked complete or qualification from being approved. - Scheduling test: a workback with a milestone after the deadline, missing dueAt, or unresolved dependency is rejected with a specific correction message. - Revision test: changing a bound slug, validation rule, expected result, deadline, or authority boundary creates a new revision, preserves the prior revision, identifies the author, and marks affected tests for regression. - Regression test: after a material revision, previously passing affected cases cannot remain final until rerun or explicitly held with a reviewer and reason. - Accessibility test: all controls are keyboard reachable, have programmatic labels, preserve visible focus, expose errors in text, maintain logical heading/order structure, and do not require color alone. - Contrast test: declared contrast pairs are checked with wcag-contrast-ratio-checker when used; failing pairs remain failures and are not waived by visual judgment alone. - Privacy test: private notes, local file paths, credentials, customer details, and protected assets are not copied into public documentation, search results, or attachments without an explicit visibility state. - Destructive-action test: deleting a test, evidence reference, instrument binding, or revision requires a clearly labelled confirmation naming the target and consequence; cancellation makes no change; deletion creates a receipt or held state where supported. - Authority test: approve, qualify, export, publish, send, upload, provider-write, credential, database, customer-indexing, and production actions remain explicitly held and cannot be inferred from a local approval. - Failure-state test: timeout, unavailable instrument reference, corrupted evidence, conflicting revision, save failure, and permission failure show a recoverable error, preserve unsaved data where safe, and do not silently mark the project qualified. - Evidence test: every passed or failed case links to its inputs, expected result, observed result, test revision, reviewer, timestamp, and source-labelled evidence reference. - Decision test: qualification is unavailable when any required case is failed, unresolved, stale after revision, missing evidence, or blocked by an authority hold. - Visibility test: private and held records remain excluded from public documentation routes and are not discoverable through inappropriate search scope. - Acceptance is proposal-only: the final record states what was tested and what remains held, without claiming connected web behavior or production state. ## Negative and held-state tests - A verified directory entry may be mistaken for a connected or deployed web feature. - A local approval may be mistaken for publication, provider connection, customer indexing, database authority, or production qualification. - Missing units, ranges, rounding rules, or expected outputs can make a passing test non-reproducible. - A changed instrument or rule can invalidate earlier evidence if revision linkage and regression are omitted. - Deadline changes can hide overdue work unless prior deadlines and revisions are preserved. - Sensitive source material, local paths, credentials, or customer information may leak through notes, attachments, search, or public documentation. - Destructive cleanup may remove the only evidence unless confirmation and receipts are required. - Accessibility failures may be masked by color-only status, inaccessible errors, or keyboard traps. - A failed save or unavailable dependency may be incorrectly represented as completion. - Unsupported live, provider, export, send, upload, or publication effects may be implied by interface names. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - This is a proposed project template for binding and testing Guth instruments. - The project can define deterministic validation, scheduling, dependency, revision, accessibility, privacy, authority, and failure-state tests. - The supplied directory identifies allowed instrument slugs and stated verification statuses. - Local prototype or indexed routes may be used to organize drafts, records, and review states. ### Still held - Any claim that an instrument is deployed, connected, production-ready, or qualified in production. - Any claim of provider, credential, database, customer, publication, export, upload, send, or external calendar effect. - Any claim that a contrast check alone proves complete accessibility compliance. - Any claim that a local approval creates external authority or customer-facing availability. - Any claim that the project has run successfully without recorded evidence and reproducible observations. ## 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` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Observed native contract: records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, attachments, and record revisions` - `Observed native contract: PointGuard is a persistent cross-app context surface; specialist apps remain execution and canonical-record owners` - `Observed native contract: current GuthHub routes are local prototypes or indexes and provider, credential, database, customer, publication, and production effects are held` - `ALLOWED_INSTRUMENTS: checksum-verifier` - `ALLOWED_INSTRUMENTS: wcag-contrast-ratio-checker`