Source: https://guthlabs.ai/docs/project-templates/security-remediation/qualification/ project template / candidate # Security remediation โ€” qualification The distinct qualification 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**: qualification **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. ## Qualification status **Result**: NOT RUN **Disposition**: HELD **Reviewer**: Not recorded **Receipt**: Not recorded This page defines proposed acceptance criteria for the qualification lane. It does not execute tests, establish compliance, qualify the subject, or authorize an effect. ### Lane-specific instrument aids No verified instrument is assigned to this qualification lane. ## Outcome definitions **Verified**: All stated evidence and acceptance requirements passed for the exact reviewed revision; this still does not authorize deployment or an external effect. **Failed**: One or more deterministic acceptance requirements failed with an inspectable reason. **Needs review**: Evidence or interpretation is incomplete, conflicting, or awaits an identified human reviewer. **Held**: Authority, required evidence, safe execution conditions, or a principal gate is absent. The current record remains NOT RUN / HELD. These definitions describe candidate outcomes only. ## Proposed deterministic acceptance tests Route-resolution and distinct-content checks apply only to the admitted canonical routes in this record. Held source-proposed extensions are non-resolving proposals and are excluded. - Submitting without a title, problem statement, source label, scope boundary, owner, or severity is rejected with field-level errors. - A scope that contains no explicit boundary or includes prohibited production, provider, credential, customer, publication, or database effects is rejected or marked Held. - An affected asset locator must be source-labelled; unsupported locators cannot be treated as authoritative. - Every linked evidence record must retain its canonical ID, origin, source locator, provenance, revision, and lifecycle metadata where available. - A task with a missing owner, invalid date, duplicate dependency, self-dependency, or dependency cycle cannot be saved as ready. - A verification deadline earlier than its prerequisite task or a review deadline earlier than verification is rejected deterministically. - Changing an approved plan creates a new revision, preserves the prior revision, and returns the project to Needs review. - A destructive action requires a plain-language impact warning, explicit confirmation, named authority, rollback or recovery plan, and an approval receipt; cancellation makes no change. - Deleting a project, evidence record, task, or approval is blocked by default and replaced with a reversible Held or archived disposition; permanent deletion requires separate authority and a second confirmation. - External sends, provider writes, credential changes, database writes, customer indexing, publication, and production changes remain visibly Held and cannot be represented as completed. - An authorization failure, unavailable source, malformed attachment, duplicate submission, or save conflict leaves the existing record unchanged and exposes a recoverable error with retry or draft-preservation guidance. - Concurrent revision conflict requires explicit comparison and user choice; last-write-wins is not acceptable for approved or evidence records. - Keyboard-only users can reach every field, error, dependency control, confirmation, and status action in a logical order. - Every input has a persistent accessible label; errors are associated with fields, announced to assistive technology, and not conveyed by color alone. - Focus moves to the first invalid field after failed submission and remains visible after destructive-action dialogs open. - Status, severity, deadlines, held effects, and approval state have text equivalents and sufficient contrast. - Sensitive evidence is minimized, redacted where possible, excluded from public search and public documentation, and never copied into an unbounded message or attachment field. - Privacy changes require re-review when scope, affected records, evidence, recipients, or visibility changes. - Only the named owner or delegated authority may approve, close, authorize destructive action, or change the canonical scope; unauthorized attempts are rejected and logged. - A failed verification cannot produce a closed or approved state; it must produce Needs revision or Held with observed failure evidence. - A blocked dependency displays the blocking record, owner, reason, and next action; the project remains visibly blocked rather than appearing complete. - A successful local save produces a canonical record ID and receipt; an uncertain save state is shown as Unknown and must not be duplicated automatically. - Search results honor visibility and lifecycle boundaries, excluding private, held, and sensitive records from inappropriate views. - Qualification is never inferred from form completion; the project remains proposal-only until human review and all acceptance criteria are explicitly recorded. ## Negative and held-state tests - Scope creep can turn a bounded investigation into unauthorized production or customer-impacting activity. - Sensitive evidence may expose credentials, personal data, security details, or private source material. - A stale or conflicting revision may overwrite approved scope, evidence, deadlines, or rollback instructions. - Incorrect dependency ordering can cause unsafe remediation or invalid verification. - A misleading completed status can conceal blocked, failed, or unverified work. - Destructive actions may be irreversible without explicit authority and recovery planning. - Provider, credential, database, customer, publication, and production effects may be mistaken for available capabilities because native surfaces are prototypes or indexes. - Accessibility failures can prevent review, confirmation, or recovery for keyboard and assistive-technology users. - Public indexing or documentation could disclose vulnerability details or private records. - Unbounded attachments or hidden uploads could violate custody, retention, or privacy expectations. - Overreliance on an instrument is unsafe because no verified instrument is necessary or designated for this project type. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - This is a proposed template for bounded security-remediation qualification. - The project design includes scope, authority, provenance, deadlines, dependencies, revisions, accessibility, privacy, and held-effect checks. - The observed native contract supports local project, task, record, revision, agenda, and approval concepts. ### Still held - Any claim that a security issue was repaired, qualified, deployed, or verified in production. - Any claim of provider, credential, database, customer, publication, or production connection. - Any claim that evidence is authoritative, complete, or customer-indexed. - Any claim that an approval, deadline write, message send, upload, export, or destructive action occurred externally. - Any claim that the project is secure, closed, or risk-free. ## 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` - `Notebook records provenance and revisions` - `PointGuard persistent cross-app context surface` - `Current GuthHub app routes are local prototypes or indexes and external effects remain held`