Source: https://guthlabs.ai/docs/project-templates/grant-application/qualification/ project template / candidate # Grant application โ€” qualification The distinct qualification record for Grant application. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:grant-application **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. - Submitting with a missing title, owner, funding organization, external deadline, or time zone is rejected with an inline, programmatically associated error. - An external deadline earlier than the current project creation time is rejected unless the record is explicitly marked historical or overdue. - An internal deadline on or after the external deadline is rejected. - A workback with any missing owner, due date, dependency, or buffer is rejected as incomplete. - Completing a dependent task while its predecessor is incomplete or held is blocked and explains the dependency. - Changing the external deadline presents the affected workback milestones and requires explicit confirmation before revision. - Saving a revision preserves the prior draft, author, timestamp, source references, and revision relationship. - A destructive action such as deleting the project, draft, attachment reference, or approval receipt requires a clearly labelled confirmation naming the affected records; cancel leaves all records unchanged. - Undo or cancellation of a destructive action is available where supported; otherwise the action remains held pending explicit confirmation. - No form or button labelled submit, send, publish, upload, connect, or export may create an external effect; it must show a held state and explain the required human action. - Approval cannot be marked Approved when required sections, attachments, unresolved blocking issues, or privacy checks remain incomplete. - A package manifest must identify every included record or file reference and flag missing, duplicate, stale, or superseded revisions. - Changing a source note or attachment revision marks dependent claims or package entries as needing review. - All required fields have visible labels, instructions, and errors; keyboard focus moves to the first invalid field and error text is announced to assistive technology. - The complete form is usable by keyboard alone, has logical focus order, visible focus indicators, sufficient contrast, and no information conveyed by color alone. - Form controls, status badges, dependency warnings, and held-state messages have accessible names and text alternatives. - Long error messages and validation summaries remain readable at enlarged text and reflow without loss of content or action. - Private project records are excluded from public or customer indexing and search results unless explicitly designated otherwise. - Sensitive applicant, financial, demographic, or attachment metadata is not copied into public context, messages, or documentation by default. - Record ownership, provenance, source locator, source SHA-256 when available, lifecycle, tags, links, attachments, and revisions remain inspectable. - If saving, indexing, scheduling, or validation fails, no partial success is claimed; the interface preserves entered values where safe, identifies the failed operation, and offers retry or local recovery. - If a dependency record is missing or inaccessible, the project enters Needs review or Held rather than treating the dependency as complete. - If an attachment reference is unavailable, type or size cannot be inspected, or the source changes, packaging is blocked with a specific remediation message. - If an approval or revision write fails, the prior authoritative local state remains visible and the user is told that no new approval or revision was recorded. ## Negative and held-state tests - Accidental external submission or publication caused by misleading action labels. - Missed deadline caused by time-zone ambiguity, silent date changes, or incomplete workback dependencies. - Unsupported claims, stale sources, or superseded attachments remaining in the final package. - Exposure of private applicant, budget, demographic, or collaborator information through shared context or search. - Destructive deletion of drafts, evidence, revisions, or approval receipts without recovery. - Accessibility barriers preventing review, correction, or approval. - False completion caused by partial saves, stale indexes, failed validation, or unavailable attachments. - Unauthorized approval or unclear ownership of the final package. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - This is a proposal-only grant-application project template. - The template can organize research, drafts, deadlines, reviews, dependencies, and a package manifest. - External submission, provider effects, credentials, publication, database authority, and customer indexing remain held. - The observed contract includes project collections, deadline payloads, revisions, provenance, and held web boundaries. ### Still held - Do not claim that a grant application was submitted, accepted, funded, published, or qualified. - Do not claim a connected calendar, funding-provider, storage, database, customer, or submission integration. - Do not claim that any deadline reminder, upload, export, approval, or package is operational in production. - Do not claim that the application is complete or eligible without explicit human review and preserved evidence. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:grant-application` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `PointGuard is a persistent cross-app context surface; specialist apps remain the execution and canonical-record owners.` - `Notebook records preserve canonical IDs, origin, source locators, source SHA-256, provenance, revision, lifecycle, tags, links, attachments, and record revisions.` - `Current GuthHub app routes are local prototypes or indexes; Provider, credential, database, customer, publication, and production effects are held.`