Source: https://guthlabs.ai/docs/field-guides/public-claim-routes/steps/ field guide / candidate # Public-claim routes โ€” steps The distinct steps record for Public-claim routes. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: field-guide:public-claim-routes **Parent lifecycle**: candidate **Page lane**: plan **Lane lifecycle**: proposed **Owner**: Tilly **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 - Open the source-bound field guide from Notebook Field Guides and create a local working record owned by Tilly. - Copy the claim verbatim into the Claim intake section; record the canonical source ID, origin, locator, source SHA-256, provenance, revision, and lifecycle. If any source locator or integrity value is missing, branch to Hold. - Classify the requested work as independent review, instrument qualification, evidence reconciliation, grant research and drafts, or website claim review. Do not treat the related job name as proof that work is active or complete. - Create or link an evidence record for every material assertion. Preserve conflicting evidence and gaps rather than resolving them by inference. - If an instrument is relevant, select only an exact slug from the verified instrument directory and record its status. Do not present an instrument as connected to a web feature or as evidence of production behavior. - Set a to-do with an explicit relative workback: intake at T-5 business days, evidence collection at T-4, independent review at T-3, wording and accessibility review at T-2, approval decision at T-1, and final human-held communication review at T. Replace T with a recorded deadline before scheduling. - Route the claim to the responsible reviewer and mark the approval record Needs review. Preserve reviewer identity, decision rationale, source links, revisions, and receipt IDs. - Draft public wording only after evidence mapping. Include attribution, scope, limitations, and a clear distinction between a proposed draft and a published or deployed statement. - Run the acceptance checks for traceability, evidence sufficiency, duplicate or doorway documentation avoidance, accessibility, and held external effects. - Mark Approved only when all acceptance checks pass and an authorized human records the decision. Otherwise mark Held, record the failure branch, and create the next due item. - Hand off the approved or held record through PointGuard or the relevant specialist surface. Treat Notebook as the record workspace and retain specialist execution ownership where applicable. - Close only when the decision, evidence links, revisions, receipts, unresolved hazards, and next review date are recorded. Closure does not imply publication, deployment, provider connection, customer indexing, or qualification. ## Deadline and chronology rules - A claim must have a recorded target deadline before a scheduled review is created. - Use the relative workback T-5, T-4, T-3, T-2, T-1, T sequence unless the owner records a justified alternative. - Escalate any missed checkpoint on the same review record and create a new due item; do not silently move the deadline. - No final outward communication is due for automatic sending; human review remains the final gate. - Set a next review date for claims dependent on changing evidence, revisions, or qualification state. ## Failure branches during execution - A source locator, hash, provenance value, or revision may be absent or stale. - A claim may exceed what its evidence supports or conflate a named native surface with a connected web feature. - Conflicting evidence may be hidden by premature wording or unrecorded reconciliation. - An instrument may be incorrectly treated as an approval, qualification, live lookup, or production dependency. - Prototype or indexed routes may be mistaken for deployed capabilities or authoritative customer records. - Draft messages, exports, uploads, and publication actions may create unintended external effects. - Private evidence may be exposed through public-facing wording or search. - Missing deadlines, owners, or receipts may make a review appear complete when it is not. - Accessibility omissions may prevent reviewers from detecting Held or Needs review states. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:field-guide:public-claim-routes` - `agents/index.html#tilly` - `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/approvals/` - `App route: /app/notebook/agent-logs/` - `App route: /app/pointguard/`