Incident response — qualification

Record status

Record ID

project:incident-response

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.

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.

• Blank required identity, owner, severity, detection source, and authority acknowledgement fields block save and identify each field programmatically.
• Invalid severity, visibility, lifecycle, decision state, completion state, or closure state is rejected deterministically.
• Whitespace-only text is rejected; bounded text fields enforce declared length limits and preserve entered content without silent truncation.
• A target recovery deadline before detectedAt is rejected with an inline, programmatically associated error.
• A dueAt without timezone, with an invalid date-time, or outside the declared project schedule is rejected.
• A dependency cycle, missing dependency, or completion attempt before dependency completion is rejected and leaves prior state unchanged.
• Changing any deadline, owner, severity, scope, or decision creates a new revision and preserves the prior revision and source provenance.
• Reloading or navigating away after a failed save does not discard unsaved values without a warning; retry does not duplicate records.
• Keyboard-only users can reach every field, dependency control, approval action, revision control, and destructive action in logical order.
• Every validation error is announced to assistive technology, linked to its field, not conveyed by color alone, and remains visible until corrected.
• Focus moves to the first invalid field after failed submission; status and success messages use an appropriate live region.
• The form has visible labels, sufficient contrast, no required field identified by color alone, and usable zoom/reflow without loss of controls.
• Destructive actions such as delete, discard revision, remove evidence reference, or close incident require explicit confirmation naming the target and consequence.
• Canceling a destructive confirmation makes no mutation; confirming records actor, timestamp, target ID, and resulting lifecycle or deletion state.
• A user without recorded authority cannot approve containment, mark recovery verified, close the project, or authorize external send.
• Provider, credential, database, customer, publication, and external-send effects remain held; attempted effects show a clear held state and preserve the local draft.
• If a referenced record, attachment, or source locator is missing, inaccessible, or hash-mismatched, the project enters Held or Needs review and does not claim evidence completeness.
• If saving fails, show a retryable error, retain form values locally for the session, avoid duplicate records, and provide a non-destructive recovery path.
• If a deadline conflict is detected, show the conflicting items and require a human choice; do not auto-move deadlines or write to a provider.
• Closure is rejected when required recovery evidence, residual-risk disposition, follow-up owner, or retrospective record is missing.
• Search and visibility tests confirm private or held records are not exposed through broader indexed views without the declared visibility permission.

Negative and held-state tests

• False closure caused by marking tasks complete without dependency or evidence checks.
• Exposure of incident details, personal data, credentials, or sensitive evidence through notes, search, messages, or indexed views.
• Destructive deletion or revision replacement without confirmation and an auditable receipt.
• Unauthorized containment, recovery, approval, closure, or external communication.
• Silent deadline shifts, recurrence, provider writes, or customer-facing effects.
• Evidence loss, altered provenance, missing hashes, broken links, or duplicate records after retry.
• Accessibility failures that prevent keyboard, screen-reader, zoom, contrast, or error recovery use.

Qualification claim boundary

Potentially allowed only after the stated evidence

• This is a proposed project template for coordinating incident-response records.
• The template can specify local records, deadlines, dependencies, approvals, evidence references, revisions, and held actions.
• The observed Notebook contract includes project collections, to-do deadline fields, record provenance and revisions, and a PointGuard context surface.

Still held

• deployment or production qualification
• provider, credential, database, customer, or publication connection
• external calendar writes or message sends
• complete evidence custody or incident containment
• security, regulatory, legal, or operational compliance
• qualification of any live incident

Sources and evidence

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

• source_record:project:incident-response
• NotebookCollectionKind.project
• NotebookTodoPayload.dueAt
• Notebook Agenda deadlines/workbacks
• Notebook records provenance and revisions
• PointGuard persistent cross-app context surface
• /app/notebook/projects/
• /app/notebook/to-dos/
• /app/notebook/agenda/
• /app/notebook/approvals/
• /app/notebook/messages/
• /app/notebook/files/