Source: https://guthlabs.ai/docs/jobs/stan-sre-and-incident-command/forms/ job / candidate # SRE and incident command โ€” forms The distinct forms record for SRE and incident command. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: job:stan:sre-and-incident-command **Parent lifecycle**: candidate **Page lane**: package **Lane lifecycle**: proposed **Owner**: Stan **Owner role**: Chief Security and Engineering Officer **Owner status**: VERIFIED **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. ### Work intake Define the bounded reliability or incident task and its source-backed context. - work type: incident, reliability review, security review, continuity, or follow-up - request summary - requester and accountable human - affected system or surface - source locator(s) - source SHA-256 when available - known customer or public impact, explicitly marked unverified if unknown - requested completion deadline - visibility: private, held, or reviewable ### Incident assessment Capture a consistent operational picture without treating confidence as permission. - incident identifier - detectedAt - lastUpdatedAt - severity proposal - symptoms and observed signals - affected scope - known start time and uncertainty - current status: investigating, contained, monitoring, resolved, or held - dependencies and suspected failure modes - communications status - safety or data-integrity concern ### Workback and deadlines Turn the task into ordered, reviewable work with explicit due dates. - milestone name - task description - task owner - priority - dueAt - recurrenceCandidate - blocking dependency - completion state - human-review required - fallback or failure state - revision note ### Evidence and receipts Preserve traceability for observations, proposals, and bounded calculations. - evidence type - source label or locator - capturedAt - content hash or checksum where applicable - linked record IDs - observation versus inference classification - receipt status - access or custody note - redaction note ### Authority and approvals Separate preparation from effects and make gates explicit. - proposed action - action category - risk and reversibility - required approver role - approval state: needs review, approved, or held - approval receipt reference - rollback or recovery plan - credential, money, legal, destructive, or deployment impact - reason for hold if not approved ### Closure and continuity Record outcome, residual risk, and follow-up ownership. - resolution summary - validated versus unvalidated claims - remaining risk - monitoring plan - continuity or recovery changes proposed - post-incident review dueAt - lessons learned - handoff owner - closure approval - final record revision ### 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. ### Request and operating context Define the reliability, security, incident, or continuity question without granting effect authority. - request title - request type: reliability, security, architecture, incident, continuity - reported-by identity - reported-at timestamp - affected surface or record locator - observed symptoms - known scope - user impact description - urgency level - requested outcome - source references ### Incident command packet Capture a structured incident brief and assign bounded coordination responsibilities. - incident identifier - incident start time - detection source - current status - impact summary - known facts - working hypotheses - unknowns - incident commander - communications owner - technical lead - next review time - decision log - recovery criteria ### Evidence and provenance Preserve inspectable support for findings and distinguish observation from inference. - evidence type - source locator - source SHA-256 when available - captured-at timestamp - record owner - relevance note - attachment or local file reference - revision identifier - provenance status - visibility classification ### Authority and approval gates Route actions that require human review instead of treating a proposal as permission. - proposed action - reason - affected system or record - reversibility - destructive-remediation flag - credential-change flag - money-or-purchasing flag - public-deployment flag - legal-filing flag - required approver - approval state: needs review, approved, held - approval receipt ### Continuity and workback Turn approved preparation into bounded tasks with owners, dependencies, and explicit deadlines. - target deadline - time zone - task owner - dependency - task description - priority - due date - recurrence candidate - completion state - fallback path - review checkpoint - blocking condition ## Required or proposed record references No record existence is asserted by this documentation page. - job:stan-sre-and-incident-command - incident record with canonical ID, severity, timeline, owner, status, and source provenance - current-work packet - source-labelled notes and evidence references - incident todo/deadline records - approval record for gated actions - agent log and receipt ledger entry - continuity or recovery plan record - post-incident review record - Job record for the bounded work request - Incident or reliability work packet - Current-work packet - Source-labelled notes and file references - Receipt ledger entry - Approval record for gated actions - Revision and provenance metadata ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `agents/index.html#stan` - `source_record:job:stan:sre-and-incident-command` - `source_record.owner_agent=Stan` - `source_record.owner_role=Chief Security and Engineering Officer` - `source_record.existing_tools=Assurance preflight; Terminal courier; Receipt ledger; Source-bound recall` - `source_record.existing_guides=Security field guides; Supabase field guide; Cloudflare operations; Current-work packets` - `source_record.principal_gates=Destructive remediation; Money or purchasing; Credential changes; Public deployment; Legal filing` - `source_record.never_rules=Manufacture Antonio's authority; Treat confidence as permission; Convert a proposal into an effect` - `observed_native_contract.records` - `observed_native_contract.deadlines` - `observed_native_contract.pointguard` - `observed_native_contract.web_boundary` - `app_routes:/app/pointguard/` - `app_routes:/app/notebook/approvals/` - `app_routes:/app/notebook/agent-logs/` - `app_routes:/app/notebook/to-dos/` - `app_routes:/app/notebook/messages/` - `app_routes:/app/business/home/` - `app_routes:/app/business/vault/` - `job:stan:sre-and-incident-command` - `Observed native contract: project_and_field_guide_collections` - `Observed native contract: deadlines` - `Observed native contract: records` - `Observed native contract: pointguard` - `Observed native contract: web_boundary` - `/app/pointguard/` - `/app/notebook/approvals/` - `/app/notebook/agent-logs/` - `/app/notebook/field-guides/` - `/app/notebook/projects/` - `/app/notebook/search/`