Source: https://guthlabs.ai/docs/project-templates/security-remediation/forms/ project template / candidate # Security remediation โ€” forms The distinct forms record for Security remediation. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:security-remediation **Parent lifecycle**: candidate **Page lane**: forms **Lane lifecycle**: proposed **Owner**: Not separately recorded **Owner role**: Not separately recorded **Owner status**: Not separately recorded **Qualification result**: NOT RUN ยท held for evidence and human review **Working browser surface:** [Project templates & workflows โ€” overview]() โ€” Create a local project from this template and validate its forms. 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. ### Intake Define the reported issue, source, urgency, and accountable owner before investigation begins. - issue title - reported by - date reported - report source and locator - affected asset or record identifier - issue description - suspected impact - confidentiality classification - initial severity: low, medium, high, critical - requested completion date - project owner - security owner - intake status: draft, needs review, accepted, rejected, held - acceptance rationale - duplicate or related project IDs ### Scope and authority Set explicit boundaries, exclusions, and permitted actions. - in-scope assets, records, routes, or code areas - out-of-scope assets and actions - authorized investigation actions - authorized repair actions - actions requiring approval - prohibited actions - credential and secret handling rule - data minimization rule - production-effect status: held unless separately approved and verified - customer or public visibility status: held - scope owner - scope approval record ID - scope revision and effective date ### Milestones Break the work into ordered, reviewable stages with owners and evidence requirements. - milestone ID - milestone name - milestone purpose - owner - start date - due date - entry criteria - planned outputs - required evidence - reviewer - approval gate - status: not started, active, blocked, complete, held - completion note - completion date ### Deadlines and workback Create source-bound deadlines and derive a visible workback without hidden automation. - target completion date - deadline type: investigation, repair, validation, approval, closure - timezone - priority - recurrence candidate - workback offset or duration - derived due date - calendar conflict note - deadline owner - escalation date - deadline status - revision reason ### Dependencies Record prerequisites and blockers that can prevent safe progress. - dependency ID - dependency description - dependency type: record, person, access, evidence, review, environment - blocking milestone - dependency owner - needed by date - status: unknown, open, ready, blocked, waived - external reference or locator - waiver approver - waiver rationale - next check date ### Owners and handoffs Make responsibility explicit for every decision and deliverable. - project owner - security owner - investigator - repair owner - validation owner - approver - closure owner - backup owner - handoff date - handoff note - authority boundary - owner acknowledgement state ### Tools and guides Link only designated interfaces, bounded procedures, and verified instruments needed for the work. - tool or guide name - kind: interface, skill, guide, record, provider - designated purpose - route or record reference - authority limit - version or revision - owner - selection rationale - availability state: proposed, available, held - fallback procedure ### Evidence Preserve source-labelled proof of findings, changes, tests, and review without hidden uploads. - evidence ID - evidence type: observation, reproduction, patch, test, log, screenshot reference, review note - description - source record ID - source locator - source SHA-256 if available - captured by - captured at - attachment or local file reference - redaction status - integrity or reproducibility note - linked milestone - visibility: private, review, held ### Approvals Gate scope changes, repairs, risk acceptance, and closure through explicit human review. - approval ID - decision type: scope, repair, exception, risk acceptance, closure - proposal summary - decision owner - reviewer - decision: needs review, approved, held - decision date - conditions - receipt or evidence reference - authority limitation - rejection or hold reason ### Risks and failure states Track harm, uncertainty, rollback readiness, and conditions that require stopping. - risk ID - risk statement - cause - affected asset or party - likelihood - impact - risk rating - mitigation - contingency or rollback plan - risk owner - trigger condition - stop-work condition - residual risk - acceptance owner - status: open, mitigated, accepted, materialized, closed ### Closure Confirm the bounded issue is addressed, evidence is complete, residual risk is explicit, and no unsupported external effect is claimed. - closure criteria checklist - final finding - repair summary - validation summary - remaining limitations - residual risks - follow-up actions - follow-up owners and due dates - linked approval IDs - evidence completeness statement - record revision summary - closure owner - closure decision: complete, held, reopened - closure date - public or customer claim status: held unless separately verified ### 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 app_features lane and remain separate from the primary operating form. ### Scope and ownership Define the bounded issue, responsible human, and authority boundary before investigation begins. - project title - issue summary - human owner - reviewer - affected surface or record locator - in-scope actions - explicitly out-of-scope actions - authority boundary acknowledgement ### Evidence and provenance Capture only source-labelled evidence and preserve traceability. - evidence description - source locator - source SHA-256 if available - record or file link - observed date - provenance note - sensitivity label - evidence confidence ### Remediation plan Turn the issue into reviewable steps with dependencies, owners, and deadlines. - remediation objective - step title - step owner - dependency - priority - due date - estimated effort - completion state - rollback or containment note - review required ### Validation and approval Record tests, unresolved risk, reviewer disposition, and held effects. - validation method - expected result - observed result - test status - residual risk - approval status - reviewer note - receipt or revision link - external effect requested - hold reason ## Required or proposed record references No record existence is asserted by this documentation page. - project record - intake record - scope record - milestone records - deadline and workback to-dos - dependency records - owner assignments - tool and guide links - evidence records - approval records - risk records - closure record - source-labelled file references - security issue note - source-labelled evidence references - remediation to-dos - deadline and workback records - approval record - agent log or investigation receipt - linked file references ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:security-remediation` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Observed native contract: records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, attachments, and record revisions` - `Observed native contract: PointGuard is a persistent cross-app context surface; specialist apps remain execution and canonical-record owners` - `Observed native contract: provider, credential, database, customer, publication, and production effects are held` - `/app/notebook/projects/` - `/app/notebook/to-dos/` - `/app/notebook/agenda/` - `/app/notebook/approvals/` - `/app/notebook/files/` - `/app/notebook/field-guides/` - `/app/notebook/agent-logs/` - `/app/pointguard/` - `Notebook records provenance and revision contract` - `PointGuard persistent cross-app context surface` - `Current GuthHub app routes and held web boundary` - `ALLOWED_INSTRUMENTS: checksum-verifier`