Source: https://guthlabs.ai/docs/project-templates/outreach-campaign/deadlines/ project template / candidate # Outreach campaign โ€” deadlines The distinct deadlines record for Outreach campaign. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:outreach-campaign **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 and actionable task must have an owner, status, and due date or an explicitly recorded reason for omission. - Use dueAt, priority, completion state, tags, and revisions for workback tasks; do not treat recurrenceCandidate as an executed schedule. - Set the target outcome date before calculating the workback. - Reserve separate deadlines for research completion, evidence review, draft completion, approval, and closure. - Hard deadlines require a timezone and source; soft deadlines require an owner who can reschedule them. - A missed deadline creates a visible exception task and risk record; it does not trigger an external action. - Conflicting deadlines remain unresolved until a named owner records a decision. - Final external sending is never a project-completion condition unless separately performed and verified by a human outside this proposal. - Target completion date is required before generating a workback. - Milestone dates must not be later than the target date unless explicitly marked post-campaign follow-up. - A dependent milestone cannot be completed while its dependency is incomplete or held. - Every outreach stage must have an owner, due date, and review status. - Overdue items are calculated locally from dueAt and completion state; no notifications are sent. - Missing target date, owner, recipient, evidence, or approval produces a visible incomplete state rather than an implied pass. - Rescheduling creates a revision and preserves the previous due date; it does not silently overwrite history. - Recurring items are only labelled recurrence candidates and never become hidden automation. ## Workback sequence - Create the campaign project and assign an owner. - Set the target completion date and define the campaign objective and success criteria. - Add account dossier records with source-labelled notes and local file references. - Define ordered outreach stages and assign each stage an owner and review requirement. - Create the workback from the target date, including dependencies, buffers, and review milestones. - Draft account-specific messages and link each draft to its dossier, stage, and source context. - Run completeness checks for missing evidence, recipients, dates, dependencies, and approvals. - Submit drafts and proposed stage transitions to local review. - Record approval, hold, or revision decisions with receipts and revision history. - Review the PointGuard projection and campaign status; keep all external sends and provider writes held. ## Scheduling records - to-dos with dueAt and owner tags - workback milestone records ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:outreach-campaign` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `PointGuard` - `Notebook records provenance and revisions` - `/app/notebook/projects/` - `/app/notebook/to-dos/` - `/app/notebook/agenda/` - `/app/notebook/messages/` - `/app/notebook/approvals/` - `/app/notebook/files/` - `/app/notebook/agent-logs/` - `Notebook records provenance and revision contract` - `PointGuard persistent cross-app context surface` - `Web boundary: provider, credential, database, customer, publication, and production effects held`