Source: https://guthlabs.ai/docs/project-templates/customer-implementation/forms/ project template / candidate # Customer implementation โ€” forms The distinct forms record for Customer implementation. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:customer-implementation **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 Identify the proposed customer implementation and establish the bounded context before work begins. - project title - customer name or internal label - customer context identifier - implementation owner - customer project owner - requested start date - target completion date - business purpose - desired outcome - requesting party - visibility classification - tenant boundary statement - effect isolation statement - known source records - intake notes - accessibility or accommodation needs ### Scope Define what is included, excluded, held, and subject to later approval. - in-scope capabilities - out-of-scope capabilities - target user groups - supported Guth surfaces - customer-specific configuration items - data or records to be referenced - customer data handling constraints - provider effects marked held - credential handling marked held - database authority marked held - publication or customer indexing marked held - qualification claims marked held - scope assumptions - scope acceptance owner - scope review date ### Milestones Create ordered deliverables with explicit owners, dates, acceptance evidence, and status. - milestone name - milestone description - sequence number - start date - due date - milestone owner - reviewer - required predecessor milestones - deliverable record type - expected evidence - approval required - status - completion notes - replan reason ### Deadlines and Workback Convert the target completion date into dated, reviewable workback tasks. - target completion date - deadline name - deadline type - due date and time - priority - recurrence candidate - completion state - task owner - reviewer - workback offset - predecessor task - tags - revision note - late-state handling - customer communication needed ### Dependencies Track internal, customer-provided, technical, review, and evidence dependencies without implying live connections. - dependency name - dependency type - description - blocking status - required-by milestone - dependency owner - provider or system reference - source record reference - expected availability date - verification method - fallback plan - escalation owner - resolution status - resolution evidence ### Owners and Responsibilities Make record ownership and review authority explicit. - project owner - implementation owner - customer owner - milestone owners - deadline owners - evidence custodian - approval reviewer - risk owner - closure reviewer - Agent operator if used - backup owner - responsibility notes - handoff date - handoff receipt ### Workback Plan Provide a deterministic sequence from approved scope to closure. - target outcome - final approval date - acceptance testing date - evidence freeze date - configuration review date - customer review date - draft completion date - dependency confirmation date - scope approval date - intake date - buffer days - calendar assumptions - replan trigger - replan owner ### Tools and Guides Declare the interfaces, skills, guides, records, or providers proposed for each step and preserve authority boundaries. - tool or surface name - tool kind - purpose - step using tool - canonical record owner - local prototype or indexed state - provider effect status - credential requirement status - guide reference - fallback surface - operator notes - authority boundary acknowledged ### Evidence and Receipts Capture source-bound evidence for decisions, configuration, tests, and handoffs. - evidence title - evidence type - related milestone - source record identifier - source locator - source SHA-256 if available - provenance note - attachment or local file reference - capture date - captured by - revision identifier - visibility - evidence status - receipt description - missing-evidence reason ### Approvals Record human review of scope, configuration, acceptance, communications, and closure. - approval subject - approval type - proposed decision - reviewer - review status - decision date - decision notes - conditions - receipt reference - rejection reason - held action - next review date ### Risks and Failure States Identify conditions that could block, misconfigure, expose, or falsely represent the implementation. - risk title - risk category - description - likelihood - impact - severity - owner - mitigation - contingency - trigger - affected milestone - status - escalation path - residual risk acceptance - review date ### Closure Confirm whether the bounded implementation is complete, held, cancelled, or requires follow-up. - closure status - completion date - acceptance summary - open items - unresolved risks - handoff owner - handoff receipt - customer review status - evidence completeness - approval completeness - held production effects - follow-up deadlines - lessons learned - closure reviewer - closure decision notes ### 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 and scope Define the project and prevent cross-customer mixing. - project title - customer display name - tenant or workspace label - implementation owner - project status - scope statement - out-of-scope statement - visibility setting - tags ### Target outcome Describe the bounded configuration outcome without implying deployment. - desired product configuration - success evidence required - acceptance owner - target completion date - assumptions - known blockers ### Milestones and workback Create explicit deadlines and predecessor relationships. - milestone name - milestone owner - due date and time - priority - estimated effort - predecessor task IDs - review buffer - recurrence candidate - completion state ### Evidence and linked records Attach source-labelled references and preserve record ownership. - linked notebook record IDs - file reference IDs - source locator - source SHA-256 if available - provenance note - record lifecycle - link relationship ### External effects and approvals Make provider, credential, publication, customer, and production effects visibly held. - proposed effect description - affected surface - required reviewer - approval state - draft message ID - execution receipt placeholder - hold reason ## Required or proposed record references No record existence is asserted by this documentation page. - Project record - Customer context record - Scope decision record - Milestone records - Deadline and workback todo records - Dependency records - Owner assignment records - Tool and guide selection records - Evidence and receipt records - Approval records - Risk records - Closure record - Project record with canonical ID, lifecycle, origin, provenance, revision, tags, links, and tenant-isolation label - Customer context record with non-sensitive display name and explicit scope boundary - Implementation milestone to-do records with dueAt, priority, completion state, tags, and revisions - Workback dependency records linking tasks to a target deadline - Source-labelled file reference records - Draft message records with recipient and send-held state - Approval records for proposed configuration or effect - Agent log records for any bounded assistance - PointGuard projection record identifying current project, next actions, blockers, and held effects ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:customer-implementation` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Observed native contract: project_and_field_guide_collections` - `Observed native contract: deadlines` - `Observed native contract: records` - `Observed native contract: pointguard` - `Observed native contract: web_boundary` - `/app/notebook/projects/` - `/app/notebook/to-dos/` - `/app/notebook/agenda/` - `/app/notebook/approvals/` - `/app/notebook/files/` - `/app/notebook/field-guides/` - `/app/notebook/agent-logs/` - `/app/pointguard/` - `project:customer-implementation` - `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 and specialist apps remain execution and canonical-record owners` - `Observed native contract: provider, credential, database, customer, publication, and production effects are held`