Source: https://guthlabs.ai/docs/jobs/wick-outreach-dossiers/forms/ job / candidate # Outreach dossiers โ€” forms The distinct forms record for Outreach dossiers. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: job:wick:outreach-dossiers **Parent lifecycle**: candidate **Page lane**: package **Lane lifecycle**: proposed **Owner**: Wick **Owner role**: World posts and outreach agent **Owner status**: HELD **Qualification result**: NOT RUN ยท held for evidence and human review **Working browser surface:** [Agent jobs โ€” builder overview]() โ€” Inspect the package and stage a local project. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held. ## Proposed form sections Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth. ### Outreach brief Define the bounded objective and intended audience before research or drafting. - dossier title - objective - target account or audience - channel or destination - requested-by person - owner - priority - desired review deadline - relationship context supplied by requester ### Sources and provenance Lock every factual claim to inspectable source material. - source record IDs - source URLs or locators - source excerpts - source SHA-256 when available - source freshness date - provenance notes - unknowns and unresolved claims - permitted attachments ### Account dossier Record only supported account and contact context. - account name - contact name if supplied - role if supplied - known relationship history - prior interaction date if sourced - relevant preferences or constraints - access status - confidence per fact ### Communication draft Prepare a reviewable message or world post without external effect. - draft type - channel - recipient or destination - subject or opening - body - proposed call to action - pricing language - relationship commitments - attachments - source links - impersonation check - send route verification state ### Response handling Capture an observed response and propose bounded next handling. - response source - received timestamp - verbatim response or source locator - classification - urgency - requested follow-up - relationship risk - proposed reply - human owner - escalation reason ### Approval and closeout Preserve human review, decision state, and unresolved work. - reviewer - review state - decision timestamp - approval scope - held reasons - edits requested - receipt reference - next deadline - retention or visibility label ### Accessible state contract - Every field requires a visible and programmatic label. - Required and optional fields must be stated in text. - Invalid entries require an actionable message linked to the field. - Blocked and Held states remain visible without relying on color alone. ## Supporting documentation fields These fields come from the docs_urls lane and remain separate from the primary operating form. ### Outreach brief Define the intended communication without granting authority to send or publish. - dossier title - target account or audience - communication objective - world-post or direct-outreach type - requested channel - requested due date - requesting person or team - relationship commitment involved? - pricing statement involved? ### Source lock Bind each proposed statement to reviewed source material and expose unsupported claims before drafting. - source record ID - source locator - source SHA-256 if available - source revision - provenance note - claim-to-source mapping - unverified facts to exclude - relationship-history evidence ### Account and contact context Separate account context from contact history and prevent invented relationship claims. - account name or label - known account facts - contact name or role if supported - prior-contact entries - last supported interaction date - open commitments - unknown or conflicting history - account-access status ### Draft communication Prepare a reviewable message or world post with explicit boundaries and no autonomous external effect. - draft text - proposed subject or headline - intended recipient or audience - attachments or linked records - pricing language - commitment language - impersonation risk check - unverified-route check ### Response and disposition Record how a response should be interpreted without representing that a response was received. - response record reference - classification - confidence or ambiguity note - requested follow-up - commitment created? - pricing request? - account-access request? - human decision required ### Review and release gate Capture human decisions and preserve the boundary between preparation and external action. - review status - reviewer identity - review decision - edits requested - send or publish route verification - final recipient or audience confirmation - approval receipt - held reason ## Required or proposed record references No record existence is asserted by this documentation page. - Source-linked account dossier - Contact history record - World packet - Outreach draft - Outreach queue item - Response classification - Approval receipt - Agent log - Deadline/to-do record - Source-linked outreach dossier - Account dossier - Contact history - Human review receipt ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `agents/index.html#wick` - `source_record:job:wick:outreach-dossiers` - `Observed native contract: project_and_field_guide_collections` - `Observed native contract: deadlines` - `Observed native contract: records` - `Observed native contract: pointguard` - `App route: /app/notebook/messages/` - `App route: /app/notebook/approvals/` - `App route: /app/notebook/agent-logs/` - `App route: /app/pointguard/` - `job:wick:outreach-dossiers` - `Observed native contract: records preserve canonical IDs, provenance, source locators, revisions, lifecycle, tags, links, attachments, and record revisions.` - `Observed native contract: PointGuard is a persistent cross-app context surface while specialist apps remain execution and canonical-record owners.` - `Observed native contract: current GuthHub app routes are local prototypes or indexes and provider, credential, database, customer, publication, and production effects are held.`