Instrument packets — steps

Record status

Record ID

field-guide:instrument-packets

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

1. Create a local field-guide record titled Instrument packets and set lifecycle to proposed.
2. Identify the packet purpose from the supplied related jobs: Independent review, Instrument qualification, Evidence reconciliation, Grant research and drafts, or Website claim review.
3. Record Tilly as owner and link the packet to the source record field-guide:instrument-packets and source locator agents/index.html#tilly.
4. Capture the source locator, source SHA-256 when available in the record, origin, provenance, revision, and lifecycle fields before drafting any claims.
5. Choose an instrument only by copying an exact slug from ALLOWED_INSTRUMENTS; record its exact name, area, and directory status.
6. Prefer VERIFIED_CLEAN instruments for qualification packets. If a VERIFIED_WITH_ERRATA instrument is selected, record the errata risk and require explicit reviewer disposition. Do not select DISPOSED_UNVERIFIABLE_OFFLINE instruments.
7. Use the instrument directory entry only for the bounded identity and status of the instrument. Do not convert a named native surface or directory entry into a claim of connected web behavior, provider connection, publication, deployment, customer indexing, or qualification.
8. Create one evidence item per material claim and label it as observed, source-bound proposal, unresolved, or held. Attach the relevant locator and record rather than relying on keywords.
9. Reconcile duplicate or conflicting evidence by preserving both record references, describing the conflict, and routing the conflict to human review.
10. Draft the packet's proposed procedure, inputs, expected outputs, limitations, and acceptance tests. Mark all implementation and external effects as held unless directly supported by the observed contract.
11. Open the packet in Notebook Field Guides and use Notes, Files, or PointGuard only for local context and source-labelled references. Do not imply hidden upload, protected storage, external send, or database authority.
12. Create a review to-do with an explicit dueAt, owner, priority, completion state, and tags. Use Agenda only to inspect or draft local scheduling; external writes remain held.
13. Submit the packet to Approvals with decision state Needs review. Preserve the proposal, reviewer identity, findings, and receipt.
14. Apply the independent-review checkpoint. A reviewer must verify exact slug matching, source binding, provenance completeness, accessibility considerations, limitation language, and separation of observed versus proposed behavior.
15. If accepted locally, set the decision to Approved only for the local proposal and preserve the receipt. Do not represent approval as production qualification, publication, or external authorization.
16. If evidence is incomplete, conflicts remain, an instrument is not exact, or a safety or accessibility issue is found, set the packet to Held, create a corrective to-do, and retain the failed evidence trail.
17. Close only when all acceptance tests pass, every material claim has a source or is explicitly held, the instrument status is recorded, review receipts are preserved, and no prohibited production claim remains.

Deadline and chronology rules

• Every unresolved evidence conflict gets an owner and explicit dueAt.
• Independent review should be scheduled before any local Approved decision.
• A packet with missing provenance, missing exact slug, unresolved material conflict, or failed accessibility check remains Held until corrected.
• Do not create recurring external automation from recurrenceCandidate; treat it only as a local review signal.
• When a deadline is missed, preserve the overdue state, add a revised dueAt, and record the reason in a new revision.
• External publication, provider writes, customer indexing, credential use, database authority, and production qualification have no completion path in this guide and remain held.

Failure branches during execution

• A directory name or native route may be mistaken for a connected production feature.
• Selecting a slug by approximate name can create an invalid or unverified instrument reference.
• VERIFIED_WITH_ERRATA instruments may be used without recording their limitations.
• Checksum or similarity results may be overstated as proof of source authority or publication.
• Duplicate evidence may be reconciled by deletion, destroying provenance and review history.
• A local Approved state may be misrepresented as production qualification or external authorization.
• Unresolved grant, website, customer, provider, credential, database, or publication claims may leak into public copy.
• Hidden uploads, protected storage, external sends, and provider writes may be implied by interface labels.
• Accessibility review may be reduced to contrast alone and incorrectly treated as complete conformance.
• Medical, financial, engineering, or other domain instruments may be presented as individualized advice or professional certification.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• source_record:field-guide:instrument-packets
• agents/index.html#tilly
• field-guide:instrument-packets
• OBSERVED_NATIVE_CONTRACT
• ALLOWED_INSTRUMENTS