Source: https://guthlabs.ai/docs/field-guides/world-packets/steps/ field guide / candidate # World packets โ€” steps The distinct steps record for World packets. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: field-guide:world-packets **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 - Create a proposed world packet in Notebook Field Guides or Projects and assign Wick as owner agent; record the related jobs exactly as supplied. - Define scope, audience, visibility, target completion date, and exclusions. Mark all external effects as held. - Create a source register in Notes and Files for every supplied source locator or local reference. Preserve canonical ID, origin, locator, source SHA-256 when available, provenance, revision, lifecycle, tags, links, and attachments. - Create a research to-do with dueAt and priority. Work backward from the target completion date: finish source capture first, research review next, dossier and draft preparation next, human approval before any proposed send, and final chronology review last. - Record world-post research as source-labelled observations. Separate observed facts, interpretation, unknowns, and follow-up questions. - Assemble the outreach dossier from reviewed research. Map each proposed claim or personalization note to a source record and explicitly list claims that must not be made. - Prepare a message draft in Notebook Messages. Include recipient, purpose, source context, requested action, attachments, send-by deadline, and a visible note that final send remains human-held. - Create an approval record with Needs review, Approved, or Held state. Preserve the proposal and receipt; do not treat local approval as delivery or publication. - Record response triage only from an identified observation or supplied response reference. Do not infer provider ingestion, customer indexing, or receipt when no evidence exists. - Append each material event to campaign chronology with date or time, actor, linked record, provenance, and uncertainty note. - Run the completion review: verify required records, source mappings, deadlines, open loops, accessibility, and failure states. Mark the packet complete only as a local record state; keep external effects held. - Create a review to-do for stale sources, approaching deadlines, unanswered responses, and any revised claims. Preserve revisions rather than overwriting prior evidence. ## Deadline and chronology rules - Require a target completion date before research begins. - Set source-capture dueAt before research-review dueAt; set dossier and draft deadlines before approval deadline. - Set a send-by deadline on every message draft, but keep final send held until human approval and a verified execution surface exist. - Set response-triage dueAt based on recorded urgency; if urgency is missing, route to human review rather than guessing. - Create a stale-source review when a source is revised, unavailable, or missing provenance. - If any deadline passes, mark the to-do overdue, preserve the prior state, create a revised dueAt, and record the reason. - Do not schedule recurring external actions; recurrenceCandidate may be used only as a review signal for local maintenance. ## Failure branches during execution - A named agent or route may be mistaken for an active connected service; label all surfaces as local prototypes or indexes where applicable. - Research may drift into unsupported world or recipient claims; require source mapping and explicit unknowns. - Draft approval may be mistaken for message delivery; preserve the human-held boundary. - A response reference may be incomplete or second-hand; record observation provenance and route ambiguity to review. - Stale, conflicting, or revised sources can invalidate a dossier; preserve revisions and reopen affected claims. - Sensitive recipient context may be over-collected; capture only fields necessary for the stated outreach purpose and respect visibility partitions. - Deadline automation may be inferred from recurrenceCandidate or scheduled views; use them only as local review signals. - Distinct documentation pages must contain useful procedure content; do not create doorway or keyword-spam pages. - Instrument selection is intentionally empty because the supplied packet workflow has no verified calculation requirement. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:field-guide:world-packets` - `agents/index.html#wick` - `observed_native_contract:project_and_field_guide_collections` - `observed_native_contract:deadlines` - `observed_native_contract:records` - `observed_native_contract:pointguard` - `app_route:/app/notebook/field-guides/` - `app_route:/app/notebook/notes/` - `app_route:/app/notebook/files/` - `app_route:/app/notebook/to-dos/` - `app_route:/app/notebook/messages/` - `app_route:/app/notebook/approvals/` - `app_route:/app/notebook/agent-logs/` - `app_route:/app/notebook/projects/` - `app_route:/app/pointguard/`