Instrument qualification — qualification

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.

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