Source: https://guthlabs.ai/docs/field-guides/security-field-guides/steps/ field guide / candidate # Security field guides โ€” steps The distinct steps record for Security field guides. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: field-guide:security-field-guides **Parent lifecycle**: candidate **Page lane**: plan **Lane lifecycle**: proposed **Owner**: Stan **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 - Confirm that the canonical record is field-guide:security-field-guides:plan, the lane is plan, and the supplied title, slug, owner agent, related jobs, and source reference are unchanged. - Record Stan as the proposed owner and list the related jobs exactly as supplied; do not assign additional owners or authority. - Create a source-labelled note containing the supplied source record and the source reference agents/index.html#stan; preserve provenance and revision metadata where available. - Define the guide scope as a proposal for security-guide definition, source binding, review, indexing, and handoff. Mark implementation, provider, credential, database, customer, publication, and production effects as held. - Add prerequisites as explicit to-dos: source review, scope confirmation by Stan, evidence specification, accessibility review, and approval review. Give each an owner, priority, due date, and completion state. - Draft the procedure with one record owner per step, observable evidence, a checkpoint after source-boundary review, a checkpoint after procedure review, and a final approval checkpoint. - Link relevant notes, files, projects, to-dos, approvals, and agent-log entries to the field-guide record. Use local file references only; do not imply upload or protected-storage completion. - Review each proposed security claim against the supplied source. Remove any claim that would imply deployment, connected web behavior, provider connection, database authority, customer indexing, publication, or qualification. - Run the acceptance tests, including source fidelity, route discoverability, ownership clarity, held-state labeling, deadline completeness, accessibility, and receipt preservation. - Submit the proposal for human review. If approved locally, preserve the approval receipt and retain the record as proposal-only unless a separately verified lifecycle transition is available. ## Deadline and chronology rules - Every unresolved prerequisite must have a named human owner, priority, due date, and completion state. - Use dueAt and revision fields where supported by NotebookTodoPayload; do not create recurring automation from recurrenceCandidate. - Set review deadlines before any proposed lifecycle transition. - If a dependency lacks a source, owner, or due date, mark the item blocked and retain the guide as proposed. - A missed deadline creates a review to-do; it does not authorize deployment, publication, external messaging, or provider writes. ## Failure branches during execution - The supplied source contains ownership and related-job labels but no detailed security procedure; adding technical controls without a new source would exceed the boundary. - A named agent or native route does not prove that a connected security web feature exists. - Local approval is not deployment, qualification, publication, or authorization for external effects. - Unverified source locators, missing digests, stale revisions, or incomplete provenance can make evidence non-reproducible. - Security records may contain sensitive information; visibility, attachments, and file references must remain explicitly reviewed. - Deadline fields can be mistaken for automation; recurrenceCandidate must not be treated as an active schedule. - Instrument output is educational or verification support only and cannot establish production security posture. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:field-guide:security-field-guides` - `agents/index.html#stan` - `field-guide:security-field-guides` - `Observed native contract: project_and_field_guide_collections` - `Observed native contract: deadlines` - `Observed native contract: records` - `Observed native contract: pointguard`