Source: https://guthlabs.ai/docs/project-templates/native-release/qualification/ project template / candidate # Native release โ€” qualification The distinct qualification record for Native release. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:native-release **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. - Required identity fields reject blank or whitespace-only values; project owner and decision authority must be named before submission. - Build version, build identifier, source revision, and evidence reference must be present before a candidate can enter qualification. - Build evidence tied to a different candidate cannot satisfy the current candidate's check unless explicitly marked comparable and reviewed by a human. - Each qualification check must have exactly one status from pass, fail, blocked, or not applicable; pass requires a non-empty evidence locator or a documented observation record. - A failed or blocked check prevents the project from reaching a proposed Approved state; the only allowed outcomes are Needs review or Held. - A missing prerequisite, overdue blocking dependency, unavailable artifact, or unresolved critical defect produces a visible blocked or held state and an actionable failure message. - Dependency cycles are rejected or surfaced as blocking conflicts; a task cannot depend on itself or on a later task in an impossible workback. - Duplicate task or evidence identifiers do not overwrite an existing record; the system preserves the canonical record and creates a revision or conflict state. - Editing a qualified record creates a new revision, preserves the prior values and evidence, identifies the editor and timestamp, and flags affected checks for requalification. - A user can cancel or navigate away from an incomplete form without destructive data loss; unsaved changes are clearly identified. - Destructive actions such as deleting a build candidate, evidence record, approval proposal, or project require explicit confirmation naming the target and consequence; cancel leaves the record unchanged. - No destructive action is triggered by keyboard focus, pressing Enter in an unrelated field, double-clicking, or a failed network/local save. - Approval controls are unavailable to unauthorized users; an approval proposal cannot claim authority from a draft, Agent, or unverified provider connection. - The interface states that submission, credentials, provider connections, database writes, customer indexing, publication, and production release remain held. - External-send or external-write failures leave the local proposal intact, display a specific retry or hold state, and do not report success without a receipt. - Accessibility checks require keyboard completion, visible focus, logical heading and form-label structure, programmatic error association, sufficient contrast, non-color-only status communication, and a usable narrow viewport. - Validation errors are announced to assistive technology, identify the affected field, explain the correction, and preserve entered values. - Private evidence and visibility classification are shown before saving; search and public documentation must not expose records marked private or held. - Unverified, missing, or unreadable attachments cannot be treated as qualification evidence; the record shows the failure reason and offers a local replacement or hold path. - The final decision summary lists all checks, unresolved risks, dependencies, revisions, evidence references, authority boundaries, and the human reviewer identity. ## Negative and held-state tests - Confusing a local prototype or index with a connected Apple release workflow. - Treating a named build or artifact reference as proof of successful packaging, signing, submission, publication, or production state. - Approving a stale candidate after build or source revision changes. - Missing accessibility or privacy failures because checks are informal or status is color-only. - Exposing private build evidence, credentials, customer information, or local paths through search, public documentation, or attachments. - Allowing an Agent or unverified user to approve, delete, submit, publish, or perform another irreversible external action. - Losing evidence or creating conflicting records during revision, retry, cancellation, or partial-save failure. - Scheduling a review without accounting for time zones, overdue dependencies, or workback conflicts. - Using an unsupported or unavailable provider integration as a prerequisite without marking it held. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - This project is a proposal for human-reviewed qualification of an Apple app build. - The project defines local records, checks, evidence requirements, deadlines, dependencies, revisions, and approval boundaries. - The current Guth routes provide prototype or indexed review surfaces as described by the observed native contract. ### Still held - That an Apple build has been packaged, signed, installed, submitted, approved, published, or released. - That any provider, credential, database, customer, publication, or production connection is active. - That qualification has passed or that a human has approved a release. - That evidence is complete, current, authentic, or externally verifiable. - That any route is a connected production feature rather than a local prototype or index. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:native-release` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Notebook records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, and attachments` - `PointGuard persistent cross-app context surface` - `/app/notebook/projects/` - `/app/notebook/to-dos/` - `/app/notebook/agenda/` - `/app/notebook/files/` - `/app/notebook/approvals/` - `/app/notebook/agent-logs/`