Outreach rules — steps

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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/