Source: https://guthlabs.ai/docs/project-templates/website-surface/qualification/ project template / candidate # Website surface — qualification The distinct qualification record for Website surface. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:website-surface **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 [wcag-contrast-ratio-checkerrequired · Check proposed foreground/background contrast values as one accessibility input; record the result and limitations in the review record.]() ## 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. - A submission with a blank title, slug, purpose, owner, or approver is rejected with field-level errors. - A slug must be lowercase, non-empty, and contain only letters, numbers, and hyphens; duplicate slugs are rejected within the project scope. - A route entry must contain a valid path, page purpose, visibility, and crawl intent; duplicate routes are rejected. - A public claim cannot be marked allowed unless it has a source reference, provenance note, reviewer, and review status of approved; otherwise it remains Held. - A source-labelled claim change creates a revision record and preserves the prior claim, source locator, and disposition. - A task with a dueAt value lacking a time zone, invalid date, or dependency to a missing record is rejected. - A release proposal is blocked when any required gate is incomplete, any critical finding is unresolved, or any approval is Held or missing. - A crawl review must report every in-scope route as reachable, intentionally excluded with rationale, or failed; unknown status blocks release qualification. - Accessibility review must include keyboard operation, visible focus, semantic headings/landmarks, form labels and errors, text alternatives, contrast evidence, zoom/reflow, and reduced-motion behavior where relevant. - Contrast failures must identify the affected component, measured values, threshold rationale, remediation owner, and retest result. - Forms must expose labels, required state, input purpose, format guidance, inline errors, summary errors, and a non-destructive recovery path. - Privacy review must identify every collected field, purpose, visibility, retention proposal, deletion/access proposal, and authority status; unspecified fields block qualification. - Destructive actions must require an explicit confirmation naming the target and consequence, provide cancel, and preserve a receipt; cancellation must leave the record unchanged. - Approval controls must distinguish Needs review, Approved, and Held; approval must not imply publication or external effect. - On save, route, crawl, instrument, or evidence failure, the interface must show a specific error, preserve unsaved input where possible, avoid duplicate records, and provide retry or recovery guidance. - A failed dependency, unavailable provider, missing credential, held database, or held publication path must produce a visible held state rather than a success claim. - Search and visibility tests must confirm private or held records are not presented as public customer-indexed content. - A final qualification record must include owner, revision, evidence links, open hazards, decision status, deadline state, and explicit held effects. ## Negative and held-state tests - Unsupported, stale, or ambiguous claims could be presented as public facts. - A native route or named surface could be mistaken for a connected web feature or production release. - Provider, credential, database, customer, publication, and external calendar effects may be incorrectly implied. - Missing source locators, hashes, provenance, or revisions can make claims impossible to audit. - Crawl failures, duplicate canonical URLs, orphan routes, or accidental indexing could create an uncontrolled public surface. - Inaccessible keyboard flows, unlabeled fields, weak contrast, missing alternatives, or non-announced errors could exclude users. - Collecting unnecessary personal or customer data could exceed the proposed authority and privacy boundary. - Destructive edits or deletion could occur without target confirmation, cancellation, or revision recovery. - Unresolved dependencies, timezone errors, and silent deadline changes could cause missed release gates. - Partial saves, duplicate submissions, stale revisions, and provider failures could create contradictory records. - Medical, financial, legal, safety, or other high-consequence claims may require specialist review not established by this project record. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - The project is a proposed qualification template for a website surface. - The observed Guth contract includes local prototype or index routes for Notebook, Agenda, Approvals, Projects, Notes, Files, To-dos, Search, and related surfaces. - The verified instrument directory includes wcag-contrast-ratio-checker as a verified-clean instrument. - Qualification criteria, deadlines, dependencies, revisions, and approval states can be proposed as records and tests. ### Still held - That any website has been built, deployed, published, crawled, indexed, or qualified. - That any provider, credential, database, customer system, calendar, storage, or publication channel is connected. - That any route represents a production web feature or external write. - That a claim is true merely because it appears in a proposed claim register. - That accessibility, privacy, security, crawl, or release compliance has been achieved without recorded evidence and approval. - That the listed contrast checker alone establishes full accessibility conformance. - That a proposed approval means external release or customer availability. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:website-surface` - `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 app routes are local prototypes or indexes and provider, credential, database, customer, publication, and production effects are held` - `ALLOWED_INSTRUMENTS: wcag-contrast-ratio-checker (VERIFIED_CLEAN)`