Source: https://guthlabs.ai/docs/field-guides/outreach-rules/steps/ field guide / candidate # Outreach rules โ€” steps The distinct steps record for Outreach rules. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: field-guide:outreach-rules **Parent lifecycle**: candidate **Page lane**: plan **Lane lifecycle**: proposed **Owner**: Wick **Owner role**: Not separately recorded **Owner status**: Not separately recorded **Qualification result**: NOT RUN ยท held for evidence and human review **Working browser surface:** [Field guides โ€” documentation]() โ€” Inspect the guide and persist local checkpoints. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held. ## Ordered procedure - Confirm that the work is an instance of one or more source-listed related jobs: World-post research, Outreach dossiers, Message drafts, Response triage, or Campaign chronology. - Open the guide in Notebook Field Guides and create or link the relevant local job and project records; preserve canonical IDs, origin, source locator, source SHA-256, provenance, lifecycle, and revisions. - Capture the source reference agents/index.html#wick and identify Wick as the listed owner agent. Do not add ownership, authority, provider, customer, or publication claims not present in the source record. - For World-post research, record each research item separately with its source locator, capture time, evidence summary, uncertainty, and a link to the related dossier. If no source locator or verifiable evidence is available, mark the item held rather than filling the gap with inference. - For Outreach dossiers, assemble only source-backed context, intended audience, objective, constraints, relevant evidence, and open questions. Link every factual assertion to its evidence record or mark it as an unverified working note. - For Message drafts, prepare a draft in Notebook Messages with recipient fields, purpose, supporting context, proposed wording, linked dossier, reviewer, and review deadline. Keep final send human-held. - For Response triage, create a local triage record that preserves the received or reported context, response category, evidence links, proposed next action, urgency, owner, and review state. Do not treat a draft classification as an external response or customer record. - For Campaign chronology, order local events and records by recorded date or explicitly mark the date as unknown. Preserve revisions and distinguish planned, drafted, reviewed, held, and completed-local states. - Create deadlines and workbacks in Notebook To-dos or Agenda using dueAt, priority, completion state, tags, and revision history. Use explicit dates only when supplied by the operator; otherwise record the deadline as unspecified and create a review task to obtain it. - Submit each dossier, draft, triage decision, and chronology change for human review in Notebook Approvals. Preserve the approval receipt and decision state as Needs review, Approved, or Held. - Use PointGuard only as a contextual room linking the relevant Notebook records. Treat Notebook as the local record owner for these records and do not interpret PointGuard presence as evidence of connected outreach capability. - Close the guide only after local evidence, links, review state, deadlines, and unresolved holds are recorded. External send, publication, provider writes, customer indexing, and production effects remain held. ## Deadline and chronology rules - Never invent an outreach, publication, or response deadline. - When a deadline is supplied, record its date, timezone if supplied, owner, priority, dependency, and review status. - Create a workback with research, dossier, draft, review, and follow-up checkpoints only when those checkpoints are supported by the operator's requested work. - If a deadline is missing, create a dated task to obtain or confirm it rather than assigning a guessed date. - A missed or conflicting deadline moves the affected record to Needs review or Held; it does not trigger external automation. - Do not imply that an Agenda entry writes to an external calendar or provider. ## Failure branches during execution - Sparse source scope may be mistaken for a complete outreach policy; unresolved policy questions must remain visible. - A named Wick owner agent does not prove current execution authority or connected outreach capability. - Research notes without locators, provenance, or hashes can become unsupported claims. - Drafted messages can be mistaken for sent messages; final send must remain human-held. - Response triage can expose or infer private customer information; keep visibility and access state explicit. - Chronology can conflate planned events with completed events unless lifecycle labels and receipts are preserved. - Agenda and To-do surfaces may look operational while provider effects remain held. - Accessibility risk: every checkpoint, hold reason, approval state, and deadline must be available as readable labels and not only color or visual ordering. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:field-guide:outreach-rules` - `agents/index.html#wick` - `observed_native_contract:records` - `observed_native_contract:deadlines` - `observed_native_contract:pointguard` - `app_route:/app/notebook/field-guides/` - `app_route:/app/notebook/messages/` - `app_route:/app/notebook/approvals/` - `app_route:/app/notebook/agent-logs/`