Source: https://guthlabs.ai/docs/project-templates/field-guide-build/forms/ project template / candidate # Field guide build โ€” forms The distinct forms record for Field guide build. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:field-guide-build **Parent lifecycle**: candidate **Page lane**: forms **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. ## Proposed form sections Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth. ### Intake Establish why the guide is needed, who requested it, and what source-bound outcome is proposed. - project title - requestor - project owner - guide author - business or operational problem - intended outcome - target audience - request date - requested completion date - priority - source record IDs - source locators - source SHA-256 values when available - known constraints - accessibility requirements - privacy or visibility classification ### Scope and boundaries Define what the guide will and will not cover before work begins. - in-scope procedures - out-of-scope procedures - assumptions - prerequisites - required inputs - expected outputs - supported lifecycle states - failure and stop conditions - human-review points - provider or external-effect boundaries - success measures - change-control rule ### Owners and responsibilities Assign accountable human roles for every major decision and deliverable. - project owner - guide author - source verifier - procedure tester - evidence owner - risk owner - approver - closure owner - backup owner - role responsibilities - handoff conditions - escalation contact ### Milestones and deliverables Turn the guide build into ordered, reviewable work. - milestone ID - milestone title - deliverable - owner - planned start - planned finish - acceptance criteria - preceding milestone IDs - status - completion evidence record IDs - review gate - rework rule ### Deadlines and workback Create explicit due dates and derive a reviewable workback schedule. - final deadline - deadline type - time zone - hard or soft deadline - buffer days - milestone due dates - review windows - approval deadline - publication or export hold state - date-change reason - revised deadline - revision owner ### Dependencies Capture conditions that can block or delay the project. - dependency ID - dependency description - dependent milestone - dependency owner - required-by date - dependency type - status - verification method - fallback plan - blocking severity - escalation date ### Tools and guides Declare which native surfaces and procedures are proposed for each activity without implying connected production behavior. - activity - designated native surface - tool or guide name - purpose - record owner - authority boundary - local prototype or indexed state - manual action required - fallback surface - known limitation ### Evidence and receipts Preserve source-bound proof for claims, tests, decisions, and completion. - evidence ID - claim or requirement supported - evidence type - source record ID - source locator - source SHA-256 - attachment or file reference ID - test performed - test result - captured by - captured at - provenance note - visibility - review status ### Approvals Make review decisions explicit and preserve the decision receipt. - approval ID - decision requested - reviewer - review scope - required evidence - decision status - decision date - conditions - rejection reason - rework owner - next review date - receipt or revision ID ### Risks and failure states Identify foreseeable failure modes and define responses before execution. - risk ID - risk statement - affected scope - likelihood - impact - severity - trigger - owner - mitigation - contingency - stop condition - escalation deadline - current status - residual risk acceptance ### Closure and maintenance Confirm completion, record unresolved items, and define future maintenance. - closure decision - completion date - final guide record ID - accepted deliverables - open items - deferred items - known limitations - maintenance owner - review cadence candidate - next review date - archive or retention instruction - closure approver - closure evidence IDs ### Accessible state contract - Every field requires a visible and programmatic label. - Required and optional fields must be stated in text. - Invalid entries require an actionable message linked to the field. - Blocked and Held states remain visible without relying on color alone. ## Supporting documentation fields These fields come from the app_features lane and remain separate from the primary operating form. ### Project identity Define the project and its source boundary. - project title - short purpose - owner label - source record IDs - source locators - source SHA-256 when available - tags - visibility label ### Guide scope Describe what the field guide will cover without asserting production qualification. - guide title - intended audience - operating context - included procedures - excluded procedures - required prerequisites - known uncertainty notes ### Deadlines and workback Create explicit milestones and derived local tasks. - target review date - target maintenance date - milestone name - milestone dueAt - priority - task duration estimate - dependency record IDs - buffer days - recurrence candidate - timezone label ### Evidence and instruments Attach source-labelled evidence and verified instruments to bounded steps. - linked note IDs - linked file reference IDs - instrument slug - instrument use - input assumptions - result receipt - review status ### Review and handoff Capture human review before a guide is treated as ready for local use. - reviewer label - review decision - review notes - open hazards - approval record ID - revision summary - held external effects ## Required or proposed record references No record existence is asserted by this documentation page. - project record - field guide record - source-labelled notes - source-labelled file references - milestone to-dos - deadline and workback entries - dependency records - evidence receipts - approval record - risk records - closure record - project record owned by Notebook Projects - field guide record owned by Notebook Field Guides - instrument or procedure references - to-dos with dueAt, priority, tags, and completion state - agenda workback blocks - revision and provenance receipts ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:field-guide-build` - `project:field-guide-build` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook records preserve canonical IDs, origin, source locators, source SHA-256, provenance, revision, lifecycle, tags, links, attachments, and record revisions.` - `Notebook Agenda deadlines/workbacks` - `/app/notebook/projects/` - `/app/notebook/field-guides/` - `/app/notebook/to-dos/` - `/app/notebook/agenda/` - `/app/notebook/files/` - `/app/notebook/approvals/` - `Notebook records canonical IDs, provenance, source locators, source SHA-256, revisions, lifecycle, tags, links, and attachments` - `PointGuard persistent cross-app context surface` - `APP_ROUTES:/app/notebook/projects/` - `APP_ROUTES:/app/notebook/field-guides/` - `APP_ROUTES:/app/notebook/to-dos/` - `APP_ROUTES:/app/notebook/agenda/` - `APP_ROUTES:/app/notebook/approvals/` - `APP_ROUTES:/app/pointguard/` - `ALLOWED_INSTRUMENTS:date-duration-calculator` - `ALLOWED_INSTRUMENTS:countdown-days-until-timer`