Outreach campaign — deadlines

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

1. Create the campaign project and assign an owner.
2. Set the target completion date and define the campaign objective and success criteria.
3. Add account dossier records with source-labelled notes and local file references.
4. Define ordered outreach stages and assign each stage an owner and review requirement.
5. Create the workback from the target date, including dependencies, buffers, and review milestones.
6. Draft account-specific messages and link each draft to its dossier, stage, and source context.
7. Run completeness checks for missing evidence, recipients, dates, dependencies, and approvals.
8. Submit drafts and proposed stage transitions to local review.
9. Record approval, hold, or revision decisions with receipts and revision history.
10. 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