Qualification records — steps

Record status

Record ID

field-guide:qualification-records

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. 1. Open the Field Guides surface and create a proposal-only qualification-record guide instance linked to source record field-guide:qualification-records, owner agent Tilly, and the applicable related job.
2. 2. Define the task type as one of the supplied related jobs: Independent review, Instrument qualification, Evidence reconciliation, Grant research and drafts, or Website claim review. Record what is in scope and explicitly list production effects that are out of scope.
3. 3. Create a source-labelled note containing the source record ID, source locator, origin, source SHA-256, revision, provenance, lifecycle, and visibility. If the source cannot be located or hashed, stop and mark the record Needs review rather than filling missing values.
4. 4. Add local file references in Files when supporting material exists. Record file type, size, locator, and relationship to the qualification record; do not treat a local reference as an upload, protected-storage copy, or authoritative database record.
5. 5. Create one evidence record per claim, observation, calculation, or contradiction. Link each item to its source locator and preserve the exact observed wording or value before adding interpretation.
6. 6. If a calculation is needed, use only a verified-clean instrument with an exact allowed slug and record its inputs, units, output, date, and limitations. For checksum or source-integrity checking, use checksum-verifier. For date or deadline arithmetic, use date-duration-calculator. Do not use an instrument to establish real-world qualification or production status.
7. 7. Reconcile evidence by comparing source locators, revisions, hashes, and observations. Mark each item Supported, Conflicting, Incomplete, or Held for review. Preserve competing evidence instead of overwriting it.
8. 8. Draft the conclusion as a bounded statement: identify what the supplied evidence supports, what remains uncertain, and what cannot be claimed. Keep provider, credential, database, customer, publication, deployment, and production effects held.
9. 9. Create a deadline todo for each unresolved item or review action using the native deadline fields: dueAt, priority, completion state, tags, and recurrenceCandidate only when explicitly reviewed. Assign an owner and record the workback or dependency in the todo notes.
10. 10. Open Approvals and submit the proposed disposition for human review. A local approval changes the review state only; it does not publish, deploy, connect a provider, qualify an instrument in production, or create customer indexing.
11. 11. Preserve the receipt by linking the note, evidence records, file references, instrument record, todos, and approval record. Record revision history and provenance for every material correction.
12. 12. Search the local indexed records to confirm that the intended qualification records are discoverable only within their permitted visibility boundary. Do not infer that search results represent customer indexing or public publication.

Deadline and chronology rules

• Every unresolved evidence conflict must have an owner and dueAt before the guide can complete.
• Review deadlines must be recorded as local todos and remain human-reviewed; recurrenceCandidate must not be treated as automation.
• If a source, hash, locator, or reviewer is missing, set the item to Held or Needs review and create a corrective todo.
• Do not mark a qualification task complete solely because an instrument returns an output or a local approval exists.
• When a deadline changes, preserve the prior revision and record the reason, editor, and new dueAt.

Failure branches during execution

• A named native surface may be only a local prototype or index and does not prove a connected web feature.
• A checksum result can verify supplied data integrity but cannot prove source authority, truth, qualification, or publication status.
• Instrument outputs may be mistaken for evidence; inputs, assumptions, units, and limitations must remain attached.
• Conflicting revisions may be silently overwritten unless every material change preserves revision history.
• Local approval may be misrepresented as external approval or production authorization.
• Private, held, and public contexts may be conflated during search or linking.
• Missing source locators or hashes can lead to unsupported claims.
• Deadline todos can be mistaken for automation or completed external work.
• Accessibility failures can exclude reviewers if focus order, labels, status text, and keyboard operation are not preserved.

Sources and evidence

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

• source_record:field-guide:qualification-records
• agents/index.html#tilly
• field-guide:qualification-records
• OBSERVED_NATIVE_CONTRACT.records
• OBSERVED_NATIVE_CONTRACT.deadlines
• OBSERVED_NATIVE_CONTRACT.pointguard
• APP_ROUTES:/app/notebook/field-guides/
• APP_ROUTES:/app/notebook/notes/
• APP_ROUTES:/app/notebook/files/
• APP_ROUTES:/app/notebook/to-dos/
• APP_ROUTES:/app/notebook/approvals/
• APP_ROUTES:/app/notebook/search/
• APP_ROUTES:/app/notebook/agent-logs/
• ALLOWED_INSTRUMENTS:checksum-verifier
• ALLOWED_INSTRUMENTS:date-duration-calculator