Source: https://guthlabs.ai/docs/project-templates/engineering-build/qualification/ project template / candidate # Engineering build โ€” qualification The distinct qualification record for Engineering build. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:engineering-build **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. - VAL-01: Empty required fields prevent submission, identify each field, and move focus or provide an equivalent programmatic association to the first error. - VAL-02: Whitespace-only titles, owners, IDs, and acceptance criteria are rejected; surrounding whitespace is normalized deterministically. - VAL-03: Canonical project IDs and acceptance test IDs are unique within the project; duplicates are rejected without overwriting an existing record. - VAL-04: Invalid dates, impossible date ordering, missing time zone context, negative durations, and unsupported priority values are rejected with actionable messages. - VAL-05: A task with a blocked or held required dependency cannot be marked ready or complete; the blocking dependency is named. - VAL-06: Circular dependency graphs are detected deterministically and qualification is held until the cycle is removed or explicitly reviewed. - VAL-07: A missed deadline displays overdue state and preserves the original dueAt; no automatic external rescheduling occurs. - VAL-08: Editing scope, acceptance criteria, dependencies, or evidence creates a new revision and leaves the previous revision inspectable. - VAL-09: Qualification cannot be approved when any required acceptance test is unrun, failed, lacks evidence, or has unresolved critical hazards. - VAL-10: Invalid inputs, empty states, unavailable records, save failures, duplicate submissions, and interrupted saves show distinct recoverable states and do not claim success. - VAL-11: Destructive actions such as deleting a project, removing evidence, or invalidating a revision require an explicit confirmation naming the affected record and offer cancel; cancellation makes no change. - VAL-12: Destructive actions are reversible where possible through a held or archived state; permanent deletion is unavailable unless authority and retention rules are explicitly recorded. - VAL-13: External sends, provider writes, credential use, database writes, customer indexing, publication, and production deployment remain visibly held and cannot be represented as completed by local approval alone. - VAL-14: Private records are excluded from public or broad search results according to their visibility field; source labels and provenance remain inspectable to authorized reviewers. - VAL-15: Keyboard-only users can complete, review, correct, and submit the form; focus order follows section order and focus is never trapped unexpectedly. - VAL-16: Every control has an accessible name, every validation message is programmatically associated, status changes are announced without relying on color, and contrast meets the designated accessibility requirement. - VAL-17: Reduced-motion preferences avoid required animation; deadlines, failures, and approvals remain understandable without timing-dependent interaction. - VAL-18: A qualification receipt records project ID, revision, tests run, outcomes, unresolved failures, reviewer, decision, and timestamp without asserting deployment or production state. ## Negative and held-state tests - A prototype route may appear connected even though provider, credential, database, customer, publication, and production effects are held. - Incomplete provenance or copied evidence can make a test result non-reproducible. - Stale dependencies can make a passing build unqualified after inputs or scope change. - Automatic rescheduling or recurrence could create hidden commitments or external effects. - Destructive deletion could remove evidence or revision history needed for auditability. - Private notes, file references, or customer-like data could become visible through broad search or shared context. - Accessibility failures could prevent correction of invalid forms or conceal held and failed states. - A local approval could be misread as deployment, provider connection, publication, or production qualification. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - A proposal for a bounded software-build qualification workflow exists. - The workflow defines deterministic validation, scheduling, dependency, revision, accessibility, privacy, destructive-action, authority, and failure-state tests. - The workflow is designed around the observed Notebook records, to-dos, agenda, approvals, notes, files, and project surfaces. - Qualification decisions are intended to remain human-reviewed and receipt-backed. ### Still held - Deployment or production readiness. - Provider, credential, database, customer, publication, or production connection. - Successful execution of the engineering build. - Qualification of any particular implementation. - External calendar, messaging, storage, or deployment effects. - Authority to delete, publish, send, index, or modify external systems. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:engineering-build` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Notebook records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, and attachments` - `PointGuard remains a cross-app context surface while specialist apps own execution and canonical records` - `/app/notebook/projects/` - `/app/notebook/to-dos/` - `/app/notebook/agenda/` - `/app/notebook/approvals/` - `/app/notebook/notes/` - `/app/notebook/files/`