Choose the work. Then assemble the evidence.

# Common Artifact Header

Toolkit schema: `PAISEH-TK-1.0`

Apply this header to every completed module, packet, finding register, and receipt.

| Field | Record |
| --- | --- |
| Artifact ID, type, and template version | |
| Title and purpose | |
| System, workflow, tenant/domain, and release/configuration identity | |
| Decision and consequence in scope | |
| Population, environment, region, and time horizon | |
| Owner, authors, reviewers, and decision authority | |
| Source artifact identities, versions, and accepted upstream decision IDs | |
| Downstream consumers, required handoffs, and receipt locations | |
| Evidence references and snapshot policy | |
| Known gaps, assumptions, limitations, and risks | |
| State, created/reviewed/effective dates, validity, and expiry | |
| Material-change and reopening triggers | |
| Sensitivity, access, retention, and archive class | |
| Supersedes / superseded by | |

## Lifecycle State

Use one: `draft`, `in review`, `conditionally approved`, `approved`, `effective`, `deferred`, `rejected`, `expired`, `superseded`, or `archived`.

Do not use `approved` for intended state or `effective` without a transition receipt.

This record may narrow or block an upstream decision. It must not silently broaden the upstream scope, population, authority, data use, accepted risk, guarantee, or validity; route any broadening to the authorized owner of the source artifact.

| Transition | Actor and authority | Time | Preconditions and evidence | Result or receipt | Conditions, expiry, and reversal |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

# Decision Packet Manifest

Toolkit schema: `PAISEH-TK-1.0`

Complete `common-artifact-header.md` first. Use this record for a Design Review, Release Readiness, Operations, or Change Review packet.

## Packet Decision

| Field | Record |
| --- | --- |
| Packet ID, type, purpose, and decision date | |
| Exact decision, scope, and consequence ceiling | |
| Toolkit schema, source-handbook version, and module/source-artifact compatibility | |
| Entry criteria and result | |
| Included artifact IDs and versions | |
| Required claims and evidence references | |
| Participants, expertise, review rights, and decision authority | |
| Walkthroughs, exercises, or transitions performed | |
| Findings, residual risks, exceptions, and dissent | |
| Disposition and rationale | |
| Conditions, owners, due dates, and exposure/stage limits | |
| Effective date, validity, expiry, and reopening events | |
| Decision receipt and authoritative location | |

## Applicability and Tailoring

| Module/view | Required / conditional / not applicable | Trigger or decision served | Included version | Omission/adaptation rationale | Compensating control | Accepting authority | Expiry/invalidation |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |

Identity, scope, ownership, authority, evidence, state, disposition, findings, closure, and change triggers cannot be tailored away.

A packet may narrow, block, suspend, or require stronger evidence for a source decision. It cannot silently broaden approved scope, population, authority, data use, accepted risk, guarantees, or validity.

## Evidence Index

| Evidence ID | Claim supported | Authoritative source/version/query | Candidate and population | Window/age | Result | Limitation/gap | Owner | Invalidation event |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | | |

## Finding and Closure Log

| Finding ID | Artifact/evidence | Severity/consequence | Blocking stage | Owner/due date | Required correction | Verification evidence | Closure authority/date | State/reopening trigger |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | | |

## Risk and Exception Register

| ID | Exact scope | Scenario/consequence | Control/limitation | Residual uncertainty | Accepting authority | Effective/expiry dates | Monitoring | Reopening event |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | | |

## Change-Impact Record

| Changed object/assumption | Proposed and actual effect | Affected claims/decisions/artifacts | Evidence retained | Evidence invalidated/missing | Required action/disposition | Owner/due date | Downstream update/receipt |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |

# AI System Design Brief

Toolkit schema: `PAISEH-TK-1.0`
Source artifacts: Chapter 1 **AI Systems Engineering Definition and Principle Set**; Chapter 2 **AI System Stack Reference Model**; Chapter 12 **Reference Architecture Catalog**

Complete `../common-artifact-header.md` first. This brief establishes responsibility, boundary, system shape, and open design decisions. It references, rather than replaces, focused discipline records.

## 1. Problem and Responsibility

- Business and user problem:
- Current workflow and baseline:
- Proposed product responsibility:
- Minimum useful outcome:
- Why AI is appropriate:
- Credible simpler alternative:
- Explicit non-goals:

## 2. People and Authority

- Direct users:
- People affected by outputs or actions:
- Operational teams:
- Accountable product owner:
- Accountable decision owner:
- Decisions reserved for people:
- Appeal, correction, or override path:

## 3. System Boundary and Interfaces

- Inputs and source-of-record boundaries:
- Outputs and downstream consumers:
- External effects:
- Material dependencies:
- Trust, permission, and execution boundaries:
- Durable state and ownership:

## 4. Engineering Shape

| Layer | Responsibility | Authoritative artifact/version | Owner | Material interface or invariant |
| --- | --- | --- | --- | --- |
| Business problem | | | | |
| Engineering problem | | | | |
| Architecture | | | | |
| Evaluation | | | | |
| Harness | | | | |
| Context | | | | |
| Prompt | | | | |
| Foundation model | | | | |
| Infrastructure | | | | |

- Selected architecture pattern or composition:
- Credible alternatives and rejection reasons:

## 5. Consequence and Failure

- Credible failure scenarios:
- Maximum blast radius and exposure ceiling:
- Reversibility and correction:
- Safe degraded mode:
- Stop conditions:
- Recovery owner and verification:

## 6. Design Argument

| Claim or assumption | Evidence reference | Disconfirming evidence or limitation | Decision supported | Owner | Reopening event |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

- Open decisions:
- Dependent artifact IDs:
- Current design disposition and conditions:

# AI Fit and Risk Assessment Worksheet

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 3 **AI Fit and Risk Assessment Worksheet**

Complete `../common-artifact-header.md` first. Use this worksheet before detailed design and before increasing autonomy, exposure, or tool authority.

## 1. Suitability

- Workflow or decision being improved:
- Current pain or opportunity:
- AI value hypothesis:
- Simpler deterministic alternative considered:
- Why that alternative is insufficient:
- Conditions where AI should not be used:

## 2. Decision Surface

- System role: inform / draft / recommend / route / decide / act / monitor
- User-visible output:
- Decisions influenced:
- Downstream systems affected:
- Actions initiated:
- Required abstention conditions:

## 3. Affected Parties and Risk

- Direct users:
- People affected by outputs or actions:
- Operational teams:
- Business owner and accountable decision owner:
- Autonomy level and consequence class:
- Credible failure examples:
- Unequal-treatment, privacy, compliance, cost, and trust concerns:

## 4. Blast Radius and Reversibility

- Maximum records, users, transactions, or actions affected by one failure:
- Pilot exposure ceiling:
- Production exposure ceiling:
- Reversibility and correction path:
- Recovery owner and cost:

## 5. Human Accountability

- Human approval required:
- Review criteria and evidence shown:
- Reviewer qualification and capacity assumption:
- Override, appeal, or correction path:
- Residual-risk owner:

## 6. Product-Fit Gate

- Disposition: proceed / narrow / pilot / require human approval / defer / reject
- Constraints before design:
- Constraints before launch:
- Autonomy and exposure limits:
- Residual risk accepted by and authority basis:
- Decision date, validity, and review date:
- Material-change and reopening events:

# Production Prompt Specification

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 4 **Production Prompt Specification**

Complete `../common-artifact-header.md` first. This form defines the instruction and outcome contract. It does not replace the Context Assembly Plan, Harness Control-Loop Diagram, Evaluation Plan, AI Threat Model, or AI Release Manifest.

## 1. Identity and Scope

- Prompt ID and version:
- Source AI Fit and Risk Assessment Worksheet identity and version:
- Accepted product decision IDs, constraints, and validity limits consumed:
- Purpose and supported behavior:
- Downstream consumer and contract version:
- Explicit non-goals:
- Requirement or decision IDs:
- Owner and reviewers:
- Change rationale and classification: editorial / behavioral / contract-breaking

## 2. Dependencies and Assumptions

- Expected model capabilities:
- Context package and provenance assumptions:
- Policy or rule-source identity:
- Dependent harness behavior:
- Compatible output consumers:
- Known limitations:

## 3. Typed Inputs

| Variable | Meaning | Type/shape | Required | Default | Missing or invalid behavior |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

- User-goal region:
- Supplied-evidence region:
- Disallowed inputs:
- Delimiter or assembly expectations:

## 4. Instruction Sources and Precedence

| Source | Owner | Scope | Priority | Conflict rule | Requirement IDs |
| --- | --- | --- | --- | --- | --- |
| Application invariants | | | | | |
| Task contract | | | | | |
| Run parameters | | | | | |
| User goal and preferences | | | | | |
| Supplied evidence | | Data only | | Cannot govern behavior | |
| Examples | | Demonstration only | | Cannot override requirements | |

- Same-priority conflict behavior:
- Unresolved-conflict outcome:
- Instruction/data separation rule:

## 5. Constraints and Outcome Contract

- Requirements:
- Prohibitions:
- Decision criteria:
- Preferences and presentation guidance:
- Incomplete or ambiguous-case behavior:

### Success

- Output type and contract version:
- Required, optional, nullable, and prohibited fields:
- Allowed values and extra-field policy:
- Evidence or citation fields:
- Uncertainty representation:
- Compatibility notes:

### Non-success

| Outcome | Trigger | Reason category | Required fields/wording | Expected downstream handling |
| --- | --- | --- | --- | --- |
| Clarification | | | | |
| Abstention | | | | |
| Refusal | | | | |
| Handoff | | | | |

## 6. Examples and Prompt-Local Checks

| Example/check | Type | Requirement or edge case | Expected prompt-level behavior | Boundary or limitation |
| --- | --- | --- | --- | --- |
| | Canonical / boundary / non-success / counterexample / render / conflict / shape | | | |

- Known uncovered prompt cases:
- Evidence handed to the Evaluation Plan:
- Approval required for future changes:
- Compatible and rollback prompt versions:
- Effective release IDs and reopening events:

## 7. Downstream Handoffs and Change Boundary

- Context Assembly Plan handoff: input regions, evidence semantics, provenance assumptions, and incomplete-evidence behavior:
- Harness Control-Loop Diagram handoff: outcome contract, validation boundary, and non-success states:
- Evaluation Plan handoff: requirement IDs, prompt-local invariants, covered examples, known gaps, and prompt version:
- AI Release Manifest handoff: prompt identity, compatibility, dependent contract versions, and material-change class:
- Broader purpose, population, instruction authority, output guarantee, or non-success behavior requested:
- Owning product decision and new accepted decision reference, if broadening is required:

Downstream records may narrow or reject this specification. They must not silently broaden the accepted product decision or this prompt contract.

# Context Assembly Plan

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 5 **Context Assembly Plan**

Complete `../common-artifact-header.md` first. Use one plan per distinct task or evidence contract.

## 1. Purpose and Ownership

- Supported behavior and task ID:
- Context owner and plan version:
- Prompt and harness dependencies:
- Change rationale and compatibility:

## 2. Evidence Requirements

| Requirement ID | Required fact/evidence | Required/optional | Freshness/effective-time need | Minimum support | Explicit non-requirements |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

- Evidence-sufficiency rule:
- Minimum viable context package:

## 3. Actor, Purpose, and Permission Scope

- Actor and tenant/domain inputs:
- Declared purpose and workflow role:
- Authorization decision reference and enforcement stage:
- Filtered unit: source / record / field / passage / memory item
- Time-dependent scope and cache/index constraints:
- Denial behavior that does not reveal protected metadata:

## 4. Source Policy

| Source | Authority domain | Primary/derived/advisory/user-asserted | Provenance | Freshness/effective time | Permission scope | Unavailable/stale behavior |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

- Conflict precedence rules:
- Conflicts that prohibit automatic resolution:

## 5. Assembly Pipeline

| Stage | Input | Decision/method | Output metadata | Failure state |
| --- | --- | --- | --- | --- |
| Eligibility and scope | | | | |
| Retrieval | | | | |
| Normalization and provenance | | | | |
| Deduplication and ranking | | | | |
| Coverage and conflict handling | | | | |
| Shaping and budgeting | | | | |
| Package validation | | | | |

- Query derivation and tie-breakers:
- Coverage and stopping rule:
- No-eligible-evidence representation:

## 6. Shaping, Memory, and Lifecycle

| Allocation | Hard/elastic | Capacity/priority | Shedding or overflow behavior |
| --- | --- | --- | --- |
| | | | |

- Protected-fact invariants and original-evidence recovery:
- Lossless and allowed lossy methods:
- Ordered shedding and minimum-package overflow behavior:

| Memory class | Scope/purpose | Owner/source | Provenance/precedence | Correction/deletion | Retention/expiry | Read eligibility |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

- Invalidation triggers:

## 7. Context Package Contract and Checks

- Package schema/version:
- Item provenance, authority, effective-time, and transformation lineage:
- Missing-evidence and conflict representation:
- Completeness states: complete / partial / stale / conflicting / unauthorized / unavailable
- Budget, shedding, timestamp, and assembly-version metadata:

| Check | Requirement/invariant | Test input | Expected assembly result | Evaluation handoff |
| --- | --- | --- | --- | --- |
| | Permission, freshness, coverage, provenance, conflict, protected fact, or budget | | | |

# Harness Control-Loop Diagram

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 6 **Harness Control-Loop Diagram**

Complete `../common-artifact-header.md` first. The diagram and tables form one enforceable control specification.

## 1. Workflow Definition

- Purpose and trigger/request identity:
- Harness owner:
- Authoritative state source and concurrency rule:
- Policy, Prompt Specification, and Context Plan references:
- Outer attempt, time, invocation, and resource budgets:
- Terminal outcome vocabulary:

## 2. Control-Loop Diagram

```mermaid
stateDiagram-v2
    [*] --> Admitted
    Admitted --> Prepared
    Prepared --> Invoking
    Invoking --> Validating
    Validating --> Accepted
    Validating --> Recoverable
    Validating --> AwaitingApproval
    Recoverable --> Prepared
    Recoverable --> Failed
    AwaitingApproval --> Accepted
    AwaitingApproval --> Prepared
    AwaitingApproval --> Cancelled
    Accepted --> [*]
    Failed --> [*]
    Cancelled --> [*]
```

Adapt states to the workflow while preserving active, recoverable, waiting, approval, degraded, and terminal distinctions.

## 3. State Catalog

| State | Purpose/authoritative data | Entry criteria | Allowed exits | Invariant | Timeout/cancellation |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## 4. Transition Contract

| From -> To | Trigger | Guard and decision owner | Model influence | Mutation and budget | Failure path | Control event |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## 5. Validation and Disposition

| Layer | Input/rule owner | Failure reason | Permitted disposition | Prohibited shortcut |
| --- | --- | --- | --- | --- |
| Invocation | | | | |
| Structural | | | | |
| Referential | | | | |
| Constraint | | | | |
| Admissibility | | | | |
| Completion | | | | |

## 6. Recovery, Fallback, and Approval

| Path/gate | Eligible reason or decision | Required material change/evidence | Budget or scope | Preserved/weakened guarantee | Authority/expiry | Exhaustion/rejection outcome |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## 7. Completion and Local Checks

- Terminal outcomes and completion evidence:
- Duplicate, late, stale, or conflicting event behavior:
- Replay and concurrency checks:
- Budget and recovery-exhaustion checks:
- Approval binding, expiry, rejection, and timeout checks:
- Cancellation and terminal-state checks:
- Effective release and emitted receipt references:

# Tool Permission Matrix

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 7 **Tool Permission Matrix**

Complete `../common-artifact-header.md` first. Define who or what may request, approve, execute, reconcile, and verify each effect.

## 1. Permission Matrix

| Tool/action | Represented principal | Allowed operation/parameter bounds | Explicit deny/data scope | Approval binding/expiry | Effect identity/idempotency | Partial/unknown outcome | Cancel/compensate/reconcile | Receipt/owner |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | | |

## 2. Authority and Delegation

- Workflow authority source:
- Principal and tenant/domain binding:
- Authority that may be delegated:
- Authority that must never be delegated or expanded:
- Approval evidence, snapshot, scope, state version, and expiry:
- Human override and emergency path:

## 3. Pre-Action Revalidation

- Identity and current-state checks:
- Eligibility and parameter checks:
- Approval and policy checks:
- Cancellation and supersession checks:
- Effect-existence check:
- Denied or indeterminate behavior:

## 4. Durable and Long-Running Work

- Workflow, action, attempt, effect, and receipt identities:
- States and authoritative store:
- Lease, heartbeat, checkpoint, takeover, and cancellation rules:
- Retry rule based on effect knowledge:
- Terminal ownership and reconciliation cadence:

## 5. Failure and Recovery

- Timeout and transport-failure behavior:
- Partial-success behavior:
- Unknown-outcome behavior:
- Compensation or correction path and limits:
- Irreversible effects and consequence ceiling:
- Required audit events and authoritative receipts:
- Exception authority, expiry, local checks, and reopening events:

# Evaluation Plan

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 8 **Evaluation Plan**

Complete `../common-artifact-header.md` first. Bind claims and risks to evidence for one exact candidate, population, and decision.

## 1. Decision Charter

- Candidate and immutable component identities:
- Intended population, environment, and consequence:
- Decision: ship / hold / narrow / reject / defer
- Product, quality, safety, execution, cost, and latency claims:
- Known risks and prohibited outcomes:
- Evidence owner and decision authority:
- Deadline, validity, and change triggers:

## 2. Coverage Matrix

| Claim/risk | Scenario/slice | Source | Expected behavior | Severity | Measure/rubric | Minimum evidence | Gap owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |

## 3. Evaluation Assets

| Asset ID/version | Provenance/permissions | Population/coverage | Freshness | Leakage controls | Adjudication | Known gaps |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## 4. Evaluators and Human Review

- Automated or model-based evaluator identity, validity, and calibration:
- Human rubric and decision criteria:
- Reviewer qualification and training:
- Independence and blinding:
- Disagreement, adjudication, fatigue, and capacity protocol:

## 5. Comparison and Online Evidence

- Baseline and candidate:
- Controlled differences:
- Practical and statistical uncertainty:
- Improvement or non-inferiority rule:
- Online sampling frame, denominator, slices, and delayed outcomes:
- Evidence-health dependency and missing-data state:
- Change attribution limits:

## 6. Results and Disposition

| Claim/risk | Population/slice | Result/uncertainty | Failure examples | Limitation or unsupported inference | Decision supported | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

- Disposition and rationale:
- Launch or hold thresholds:
- Conditions, residual risks, and acceptors:
- Regression cadence and evidence to rerun:
- Expiry, invalidation, and reopening events:

# AI Threat Model

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 9 **AI Threat Model**

Complete `../common-artifact-header.md` first. Record trust, privacy, access, misuse, dependency, affected-party, assurance, governance, and residual-risk decisions.

## 1. Objectives and Scope

- Source AI Fit and Risk Assessment Worksheet identity, version, and accepted decision IDs:
- Source Context Assembly Plan identity, version, and permission/source-trust boundary:
- Source Harness Control-Loop Diagram identity, version, and control/approval boundary:
- Source Tool Permission Matrix identity, version, and authority/effect boundary:
- Supporting Evaluation Plan identity, version, and assurance-evidence IDs:
- Protected outcomes and assets:
- Exact system, population, environment, and consequence:
- Data classes and prohibited disclosures/effects:
- Security, privacy, product, engineering, and governance owners:
- Explicit non-goals:

## 2. Flows and Trust Boundaries

| Actor/component | Data or action | Identity/authentication | Authorization change | Trust boundary | Sensitive-data handling | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

Include users, model, context sources, tools, stores, control plane, and external dependencies.

## 3. Threat Scenarios

| Scenario | Preconditions/path | Target | Consequence/affected party | Prevention | Detection | Containment/recovery | Residual uncertainty |
| --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |

Cover prompt injection, data leakage, unauthorized action, unsafe output, abuse, dependency or supply-chain change, and relevant domain-specific threats.

## 4. Access, Privacy, and Dependencies

- Principal, purpose, least authority, and enforcement point:
- Retention, deletion, derived data, residency, and disclosure:
- User notice, correction, appeal, and consent where applicable:
- Component/model/data/provider identity and provenance:
- Integrity, change notice, fallback, concentration, and exit risk:

## 5. Control Assurance

| Control | Requirement/owner | Implementation reference | Evidence | Limitation/failure signal | Last exercise | Change trigger |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

## 6. Governance and Residual Risk

- Security incident and notification handoff triggers:
- Governance decision-record identity, disposition, constraints, and expiry:
- AI Release Manifest handoff: governance decision ID, enforceable constraints, and material-change triggers:
- AI Operations Runbook handoff: security event classes, containment constraints, evidence rules, and restoration authority:
- Reviewers, rights, disposition, conditions, and dissent:
- Residual risk exact scope and rationale:
- Accepting authority and authority basis:
- Compensating control and monitoring:
- Effective date, expiry, and reopening event:

# AI Release Manifest

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 10 **AI Release Manifest**

Complete `../common-artifact-header.md` first. Bind one immutable composite candidate to topology, configuration, exposure, recovery, health decisions, and actual transition receipts.

## 1. Composite Candidate Identity

| Component | Immutable identity/version | Provenance/build receipt | Compatibility and owner |
| --- | --- | --- | --- |
| Application | | | |
| AI Fit and Risk Assessment Worksheet decision | | | |
| Production Prompt Specification | | | |
| Model configuration | | | |
| Context Assembly Plan and corpus/index/source policy | | | |
| Harness Control-Loop Diagram and workflow | | | |
| Tool Permission Matrix and effective policy | | | |
| Route/runtime/policy configuration | | | |
| Evaluation Plan decision record | | | |
| AI Threat Model governance decision | | | |

- AI Operations Runbook handoff: release-health contract, effective-state identities, receipts, and recovery proof:

## 2. Target and Topology

- Environment, regions, tenants, and eligible/excluded populations:
- Topology units, state, capacity, and failure domains:
- Dependencies, isolation, and data residency:
- Assignment unit, affinity, and propagation through durable work:
- Promotion/rollback unit and reserved recovery capacity:

## 3. Configuration and Routing

- Source of truth, schema, precedence, and safe defaults:
- Approved destinations and eligibility:
- Affinity, fallback, fail-open/closed, overload, and degradation limits:
- Propagation, acknowledgement, convergence, stale-client, and drift behavior:
- Secret bindings and material scope assumptions:

## 4. Promotion and Exposure Plan

| Stage/transition | Target | Eligible/excluded population | Assignment/affinity | Min/max exposure | Observation/outcome-delay window | Advance/hold/reverse conditions | Actor/authority | Reversal path |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | | |

## 5. Compatibility, Migration, and Recovery

| Changed component/state | Backward/forward compatibility | Mixed-version rule | Migration/point of no return | In-flight work | Created state/effects | Recovery action | Verification |
| --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |

- Recovery-time and data-loss expectations:
- Retained snapshots/assets and cleanup duties:
- Required capacity and dependency availability:
- Latest recovery-exercise reference, result, and limitation:

## 6. Release-Health Contract

| Claim/failure | Candidate/stage | Population/denominator/slice | Signal/evidence source | Baseline/threshold/uncertainty | Window/delay | Missing/indeterminate behavior | Action/authority | Terminal result |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | | |

## 7. Deployment Receipt and Closure

| Field | Actual result |
| --- | --- |
| Candidate and environment requested | |
| Effective component, route, configuration, and index identities by topology unit | |
| Transition actor, policy, start/end time, and result | |
| Population assignment and exposure achieved | |
| Configuration convergence and drift result | |
| Stage decisions and evidence references | |
| Deviations, emergency changes, owners, and expiry | |
| Recovery action and verified effective state | |
| Final steady-state or retirement decision | |
| Temporary machinery and derived-data cleanup | |
| Follow-up owners and due dates | |

# AI Operations Runbook

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 11 **AI Operations Runbook**

Complete `../common-artifact-header.md` first. This runbook must let an operator move from signal to evidence validation, command, containment, investigation, verified recovery, communication, and learning without inventing authority or semantics.

## 1. Service Charter and Effective State

- Critical workflows, outcomes, and prohibited outcomes:
- Populations, regions, tenants, and consequence classes:
- Effective release, topology, configuration, and route receipts:
- Service, domain, on-call, support, and escalation owners:
- Critical dependencies and authoritative records:
- Accepted degraded modes and scope ceilings:
- Tool Permission Matrix, Evaluation Plan, AI Threat Model, and AI Release Manifest identities, versions, and accepted decision references:
- Reference Architecture Catalog handoff: operational invariants, capacity limits, degraded modes, containment, and recovery proof:

## 2. Objectives and Evidence Health

| Objective | Layer/population | Indicator/window/boundary | Delay/minimum evidence | Evidence-health dependency | Owner/response |
| --- | --- | --- | --- | --- | --- |
| | Behavioral / execution / economic / evidence | | | | |

| Authoritative query/view | Decision served | Dimensions/drill-down | Freshness/health | Change overlays | Known blind spots |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

- Schema, producer, causal identity, sampling, and join-health checks:
- Missing or indeterminate evidence behavior:
- Protected payload, access, retention, and replay constraints:

## 3. Detection and Declaration

| Rule | Protected objective/population | Window/threshold/volume/completeness | Indeterminate behavior | Severity/owner/destination | Automated authority/expiry | Test/last exercise |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

- Declaration channel and provisional classification:
- Severity dimensions:
- Incident commander, operations lead, domain lead, communications lead, and scribe:
- Security, privacy, legal, action, release, and business handoff triggers:
- First scope queries and decision-log location:

## 4. Containment and Degraded Modes

| Failure condition | Scope | Action/procedure reference | Authority | Preconditions | Expected effect | Expiry/reversal | Verification query/receipt |
| --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |

Cover observation, increased sampling, feature/cohort restriction, review-only mode, admission stop, queue pause, state isolation, release transition, cancellation, and reconciliation as applicable.

## 5. Investigation Protocol

- Incident identity, scope hypotheses, sources, clock offsets, and gaps:
- Alerts, acknowledgements, automated actions, commands, approvals, and communications:
- Effective-state and dependency history:
- Causal graphs, action receipts, queue/state references:
- Versioned queries, snapshots, denominators, sampling, and evidence health:
- Protected evidence references, redaction, access, and retention holds:
- Hypotheses, disconfirming evidence, observations, decisions, and uncertainty:
- Reproduction type, result, and limitation:

## 6. Recovery, Verification, and Communication

| Dimension | Required recovery claim | Evidence/query | Observation window | Owner | Exit criterion |
| --- | --- | --- | --- | --- | --- |
| New traffic/infrastructure | | | | | |
| Queued/in-flight work | | | | | |
| State/caches/indexes | | | | | |
| External actions/effects | | | | | |
| Behavioral outcomes/slices | | | | | |
| User correction/remediation | | | | | |
| Telemetry/evidence health | | | | | |
| Delayed outcomes/uncertainty | | | | | |

- Residual degraded mode or uncertainty and accepting authority:
- Audiences, message owner, cadence, and constraints:
- Recovery and final-status receipts:

## 7. Learning and Closure

- Event, impact, population, duration, and uncertainty:
- Detection path, missed signals, and time to credible awareness:
- Response actions, authority delays, and effects:
- Contributing system and organizational conditions:
- Failed or absent prevention, detection, containment, recovery, and assurance controls:
- Feasible counterfactuals and residual risk:

| Action | Class | Owning chapter/system | Owner/due date | Verification and release/policy path | Closure authority | Recurrence signal |
| --- | --- | --- | --- | --- | --- | --- |
| | Immediate repair / prevention / detection / recovery / evidence / accepted risk | | | | | |

# Principal Design Review Checklist and Record

Toolkit schema: `PAISEH-TK-1.0`
Source artifact: Chapter 12 **Reference Architecture Catalog**, design-review record

Complete `../common-artifact-header.md` and `../packet-manifest.md` first. This checklist creates evidence-indexed findings; it does not grant approval.

## 1. Review Charter

- Exact decision and consequence ceiling:
- Reviewed packet ID and artifact versions:
- Decision owner and authority:
- Reviewers, expertise, rights, and conflicts:
- Walkthroughs required and performed:
- Decision date and validity:

## 2. Inspection Record

| Area | Exact artifact/evidence | Inspection question | Finding/limitation | Blocking stage | Owner/due date | Verification/closure authority |
| --- | --- | --- | --- | --- | --- | --- |
| Responsibility and fit | | Is responsibility useful, bounded, and preferable to a simpler option? | | | | |
| Affected parties/consequence | | Are authority, blast radius, reversibility, correction, and residual risk explicit? | | | | |
| System/pattern boundary | | Are interfaces, identities, invariants, seams, and degraded modes coherent? | | | | |
| Prompt/context | | Are instruction and evidence contracts compatible, authorized, failure-aware, and versioned? | | | | |
| Harness/tools | | Are transitions enforceable and actions bounded, approved, reconcilable, cancellable, and receipted? | | | | |
| Evaluation | | Do claims and risks have valid population-specific evidence and limits? | | | | |
| Security/governance | | Are trust, data, access, misuse, dependencies, assurance, and acceptors addressed? | | | | |
| Release/recovery | | Is one candidate tied to exposure, compatibility, in-flight work, health, and recovery? | | | | |
| Operations | | Can operators detect evidence failure, contain, investigate, verify recovery, and close learning? | | | | |
| Change/lifecycle | | Are dependencies, expiry, supersession, findings, receipts, and reopening discoverable? | | | | |

## 3. Findings, Dissent, and Disposition

- Blocking findings and closure references:
- Non-blocking findings and accepted limitations:
- Residual risks and authorized acceptors:
- Dissent and unresolved uncertainty:
- Disposition: approve / approve with conditions / return for redesign / reject / defer for missing evidence
- Rationale:
- Conditions, owners, due dates, and stage limits:
- Decision authority and receipt:
- Effective date, expiry, and material-change triggers: