Source: https://guthlabs.ai/docs/project-templates/customer-implementation/deadlines/ project template / candidate # Customer implementation โ€” deadlines The distinct deadlines 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**: app_features **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. ## Deadline and workback rules - Every milestone must have an owner, due date, predecessor or explicit no-predecessor declaration, expected evidence, and acceptance condition. - Every deadline must use dueAt when a date and time are known; date-only deadlines must state the assumed timezone or calendar convention. - Workback dates must be calculated backward from the target completion date and must include review, evidence, approval, and contingency buffers. - A blocked dependency must create or link to a deadline todo and identify an escalation owner. - Late or missed deadlines must remain visible, preserve their revision history, and require a replan reason rather than silent date changes. - Recurring work must be marked only as a recurrence candidate until a human confirms the recurrence pattern. - External calendar writes, customer notifications, final sends, provider actions, credential use, publication, and production changes remain held for human review. - Every milestone must have an explicit dueAt or be marked undated with a reason. - A milestone cannot be marked ready for review if a required predecessor is incomplete or missing. - Workback dates are deterministic from target completion date, task duration, dependency order, and review buffer; assumptions are shown beside results. - Conflicting deadlines are surfaced before saving a schedule change. - Past-due items remain visible and are not silently rescheduled. - Recurrence is only a candidate flag and never creates hidden automation. - Date-only inputs must define timezone behavior before conversion to dueAt. - External calendar writes and notifications remain held. ## Workback sequence - Create the project record and assign a unique canonical ID. - Enter the customer display name, tenant label, visibility, scope, and out-of-scope boundaries. - Define the desired configuration outcome and evidence required for acceptance. - Add milestones with explicit dueAt values, priorities, owners, estimates, and predecessor links. - Generate a local workback from the target completion date using stored task dependencies and review buffers. - Link source-labelled notes and file references; preserve source locators, provenance, and revisions. - Review the tenant-isolation panel for unlinked or cross-customer records before progressing. - Open PointGuard to project the current milestone, next actions, blockers, and held effects. - Draft configuration changes and customer communications without sending or applying them externally. - Submit proposed decisions to Approvals and preserve the local decision receipt. - Run acceptance tests, mark only locally evidenced work complete, and leave unsupported effects held. ## Scheduling records - Milestone records - Deadline and workback todo records - Dependency records - Owner assignment records - Implementation milestone to-do records with dueAt, priority, completion state, tags, and revisions - Workback dependency records linking tasks to a target deadline ## 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`