Bind release authority to the exact composite candidate.

# AI Release and Change Review Scenario Pack

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ARCR-1.0`

Use this pack when a proposed change to code, prompts, model configuration, context sources or indexes, harness behavior, tool permissions, policy, routing, runtime configuration, or operating controls needs one reviewable impact and release decision.

This pack assembles evidence around the canonical Decision Packet Manifest, Evaluation Plan, AI Threat Model, AI Release Manifest, AI Operations Runbook, and Principal Design Review Checklist. It does not redefine evaluation, governance, deployment, or operating methods.

## When to Use This Pack

Use it before a material AI-system change enters an environment or exposure stage. Also use it when a supposedly minor change may invalidate evidence, alter compatibility, change effective behavior, or weaken recovery.

## Roles and Authority

| Role | Responsibility | Authority retained |
| --- | --- | --- |
| Change owner | Defines the proposed change, rationale, scope, and dependencies | Owns proposal accuracy, not approval |
| Component owners | Assess prompt, context, model, harness, tool, policy, runtime, and operations impact | Validate owned contracts and evidence |
| Evidence owner | Binds evaluation and assurance evidence to the exact candidate | Declares validity and limitations |
| Release owner | Completes the canonical AI Release Manifest | Owns topology, exposure, compatibility, and recovery plan |
| Review lead | Runs the Principal Design Review and records findings | Recommends disposition unless separately authorized |
| Decision authority | Approves, narrows, holds, reverses, or rejects the named stage | Cannot delegate accountability to a checklist |
| Operations owner | Verifies readiness, effective state, health, and recovery | Owns production handoff and receipts |

## Minimum Viable Pack

Complete:

1. Common Artifact Header.
2. Change Impact Record.
3. Decision Packet Manifest.
4. The affected canonical module records.
5. Release Evidence Validity Checklist.
6. AI Release Manifest.
7. Release Review Decision Record.

Use compact references for unaffected modules, but record why they remain valid. Increased autonomy, sensitive data, external action, durable state, trust-boundary crossing, migration, irreversibility, or higher consequence requires the corresponding risk, threat, permission, recovery, and operating records.

## Entry Criteria

- The composite candidate and every changed component have immutable identities.
- The baseline, target environment, eligible population, exposure stage, and decision are named.
- The change owner has completed an impact analysis across upstream assumptions and downstream consumers.
- Evidence owners have stated which results remain valid and which must be rerun.
- Compatibility, mixed-version behavior, migration, rollback, in-flight work, and observability are reviewable.
- Release, review, decision, and operations authorities are named.

## Working Sequence

1. Classify the change and dependencies in the Change Impact Record.
2. Assemble exact records and evidence in the Decision Packet Manifest.
3. Inspect candidate binding, validity, compatibility, recovery, and open findings with the checklist.
4. Complete the canonical AI Release Manifest for the named transition.
5. Record the authorized disposition in the Release Review Decision Record.
6. Preserve deployment and effective-state receipts after any transition.

## Exit and Acceptance Criteria

- No changed component or effective configuration is represented by a floating label.
- Each evidence item names its candidate, population, environment, validity, and limitation.
- Unchanged claims have an explicit compatibility argument, not an assumption.
- Open findings, exceptions, dissent, conditions, and expiry remain visible.
- The release manifest defines staged exposure, hold, reverse, and verified recovery.
- The decision record names exactly what may change, where, for whom, under which conditions.
- Effective-state receipts confirm what actually happened; approval alone does not prove deployment.

## Failure Paths

- Use `runbooks/expired-or-misaligned-release-evidence.md` when evidence is stale, belongs to another candidate or population, or no longer covers the accepted claim.
- Use `runbooks/effective-state-drift-or-failed-transition.md` when requested and actual versions, routes, configuration, exposure, or recovery state diverge.

## Material Change and Reopening Triggers

Reopen when any component identity, dependency, population, environment, topology, route, policy, permission, context source or index, prompt, model setting, harness transition, migration, evidence result, health threshold, recovery path, exposure ceiling, exception, or accepted risk changes. Reopen when effective state diverges from the manifest or delayed outcomes contradict the decision.

# AI Change Impact Record

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ARCR-1.0`

Complete `../../common-artifact-header.md` first. Use this record to determine which accepted assumptions, contracts, evidence, controls, and operating paths a proposed change may invalidate.

## 1. Change Identity

| Field | Record |
| --- | --- |
| Change and candidate ID | |
| Baseline composite identity | |
| Proposed composite identity | |
| Change owner and component owners | |
| Target environment, population, and exposure stage | |
| Requested decision and deadline | |

## 2. Changed Components

| Component | Baseline identity | Candidate identity | Semantic change | Owner | Direct consumers |
| --- | --- | --- | --- | --- | --- |
| Application | | | | | |
| Prompt | | | | | |
| Model configuration | | | | | |
| Context source, corpus, or index | | | | | |
| Harness or workflow | | | | | |
| Tool contract or permission | | | | | |
| Policy, route, or runtime configuration | | | | | |
| Evaluation, monitoring, or operating control | | | | | |

## 3. Impact Walk

| Accepted record, claim, or control | Why it may be affected | Evidence still valid? | Required action | Owner |
| --- | --- | --- | --- | --- |
| Product fit, risk, autonomy, or consequence | | Yes / no / indeterminate | | |
| Prompt and outcome contract | | | | |
| Context evidence and permission contract | | | | |
| Harness state and recovery contract | | | | |
| Tool authority and external-effect contract | | | | |
| Evaluation claim and threshold | | | | |
| Threat, privacy, and governance decision | | | | |
| Release compatibility and rollback | | | | |
| Operations objective, alert, and runbook | | | | |

`No impact` requires a recorded compatibility argument and owner. Silence is `indeterminate`.

## 4. Compatibility and State

- Backward and forward compatibility:
- Mixed-version behavior:
- In-flight work and durable state:
- Migration and point of no return:
- External effects and reconciliation:
- Cache, index, or configuration propagation:
- Restoration assets, capacity, and last exercise:

## 5. Evidence Plan

| Claim or risk | Existing evidence | Candidate/population match | Validity and limitation | Rerun or new evidence | Owner |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## 6. Classification and Entry Decision

- Change class and rationale:
- Material consequence or uncertainty:
- Required reviewers and decision authority:
- Required packet modules:
- Entry disposition: `ready for review`, `needs evidence`, `needs redesign`, `defer`, or `reject`
- Conditions, due dates, and expiry:
- Reopening triggers:

# Release Evidence Validity Checklist

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ARCR-1.0`

Complete `../../common-artifact-header.md` first. This checklist creates evidence-indexed findings. It does not approve a release, accept risk, grant an exception, or prove that a transition occurred.

## 1. Review Basis

| Field | Record |
| --- | --- |
| Change Impact Record version | |
| Decision Packet Manifest version | |
| Baseline and candidate composite identities | |
| Target environment, population, and exposure stage | |
| Evaluation, threat, release, and operations record versions | |
| Review lead and decision authority | |

## 2. Evidence Index

| Evidence ID | Claim/risk | Candidate | Population/environment | Result/uncertainty | Valid through | Limitation | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| EV- | | | | | | | |

## 3. Validity and Readiness Findings

| Check | Evidence ID | Result | Finding ID |
| --- | --- | --- | --- |
| Every component and configuration has an immutable effective identity | | Pass / fail / indeterminate / not applicable | |
| Evidence belongs to the exact candidate or has a supported compatibility argument | | | |
| Population, environment, slices, and consequence match the requested stage | | | |
| Evaluation assets, evaluators, and thresholds remain valid | | | |
| Security, privacy, governance, and permission decisions cover the candidate | | | |
| Mixed-version, migration, in-flight work, and durable state are dispositioned | | | |
| Staged exposure has advance, hold, reverse, and missing-evidence rules | | | |
| Recovery assets, capacity, authority, and verification are credible | | | |
| Operations signals can identify candidate, population, and effective state | | | |
| Open findings, exceptions, dissent, conditions, and expiry are visible | | | |
| Decision packet references are retrievable and internally consistent | | | |

## 4. Findings Register

| Finding ID | Evidence ID(s) | Observation and consequence | Severity | Required correction or decision | Owner / due date | State |
| --- | --- | --- | --- | --- | --- | --- |
| F- | | | | | | |

Allowed states are `open`, `corrected`, `verified`, `accepted risk`, `deferred`, and `not reproducible`. Only the named authority may accept risk, grant an exception, or close a finding.

## 5. Review Outcome

- Claims supported for the named stage:
- Claims not supported:
- Evidence gaps and expiry:
- Reviewer recommendation: `approve named stage`, `approve with conditions`, `hold`, `reverse`, `reject`, `defer`, or `no recommendation`
- Required deployment and effective-state receipts:
- Decision authority, disposition, rationale, conditions, and expiry:

## 6. Reopening Triggers

Reopen when the candidate, population, environment, stage, evidence, threshold, exception, topology, route, permission, migration, recovery path, health contract, or effective state changes.

# AI Release Review Decision Record

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ARCR-1.0`

Complete `../../common-artifact-header.md` first. Create this record after review. It binds the authority's disposition to one exact candidate, target, exposure stage, evidence set, and validity window.

## 1. Decision Identity

| Field | Record |
| --- | --- |
| Change, packet, and review IDs | |
| Baseline and candidate composite identities | |
| AI Release Manifest version | |
| Target environment, population, and exposure stage | |
| Review lead, release owner, operations owner, and decision authority | |
| Decision time, effective window, and expiry | |

## 2. Review Findings

| Finding ID | Severity | Final state | Correction, condition, exception, or accepted risk | Authority | Evidence |
| --- | --- | --- | --- | --- | --- |
| F- | | | | | |

- Dissent and unresolved uncertainty:
- Evidence excluded from the decision and why:
- Claims explicitly not supported:

## 3. Authorized Disposition

- Disposition: `approve named stage`, `approve with conditions`, `hold`, `reverse`, `reject`, `defer`, or `supersede`
- Exact candidate, target, and maximum exposure:
- Eligible and excluded populations:
- Preconditions:
- Required observation and delayed-outcome window:
- Advance, hold, reverse, and expiry conditions:
- Authority for each transition:
- Prohibited broadening:

## 4. Transition and Effective-State Receipts

| Transition | Requested state | Actual effective state | Receipt / evidence | Decision and authority |
| --- | --- | --- | --- | --- |
| | | | | |

Approval does not prove deployment. Record configuration convergence, population assignment, mixed versions, in-flight work, rollback, and residual state in the canonical AI Release Manifest receipt.

## 5. Operations Handoff and Closure

- Release-health contract and dashboards:
- Missing or indeterminate evidence behavior:
- Containment, rollback, and recovery references:
- On-call and escalation acknowledgement:
- Follow-up owners and due dates:
- Final steady-state, reversal, or retirement receipt:
- Supersedes / superseded by:
- Reopening triggers:

# Runbook: Expired or Misaligned Release Evidence

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ARCR-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when evidence is expired, belongs to another candidate, population, environment, stage, or evaluator, or no longer covers the claim used in a release decision.

## Entry Conditions and Authority

- Candidate, packet, evidence, claim, population, environment, and stage identities:
- Mismatch, expiry, invalidation event, and affected decision:
- Evidence owner, review lead, release owner, operations owner, and decision authority:
- Authority to hold, narrow, reverse, rerun evidence, withdraw approval, or accept residual risk:

## Immediate Action

1. Mark affected claims and release decisions `indeterminate`.
2. Stop advancement and preserve the packet, evidence versions, decision, and any transition receipts.
3. Bound candidates, stages, populations, and effective deployments that relied on the evidence.
4. Assign owners for evidence replacement and release disposition.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Bind | Compare exact candidate, components, population, environment, stage, and claim | Mismatch matrix | Candidate identity is incomplete |
| Validate | Check dataset, evaluator, threshold, freshness, leakage, and limitation | Validity decision | Evidence owner disputes validity |
| Bound | Identify decisions and effective exposures that relied on the claim | Impact inventory | Production population is unknown |
| Replace | Rerun or add only the evidence required for the named claim | New versioned result | Candidate changes during evaluation |
| Disposition | Hold, narrow, reverse, or reapprove under authority | New decision record | Risk exceeds authority |

## Verification and Stopping Conditions

Verify candidate binding, controlled differences, population and slice coverage, evaluator validity, threshold interpretation, evidence health, expiry, and every affected stage decision.

Stop and escalate when evidence cannot be reproduced, unsupported exposure remains active, a protected outcome may be affected, or the authority needed to reverse or accept risk is unavailable.

## Reversal

- Hold advancement or restore the last release state supported by valid evidence.
- Withdraw or supersede decisions that relied on invalid claims.
- Reopen dependent threat, permission, operations, or design decisions.
- Do not relabel missing evidence as a pass or carry approval to a different candidate.

## Evidence and Closure

Record the invalidation event, mismatches, affected decisions and populations, containment, replacement evidence, new disposition, transition receipts, and remaining uncertainty.

Close when every affected claim has valid evidence or an authorized bounded disposition, and effective exposure matches the decision. Reopen on another invalidation or delayed adverse outcome.

# Runbook: Effective-State Drift or Failed Transition

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-ARCR-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when actual component versions, routes, policy, context index, configuration, population assignment, exposure, or recovery state diverges from the AI Release Manifest.

## Entry Conditions and Authority

- Manifest, candidate, transition, environment, topology, and receipt identities:
- Requested state, observed effective state, drift, and affected population:
- Release owner, operations owner, component owners, incident route, and decision authority:
- Authority to hold, stop admission, revert, reconcile, isolate, notify, or accept a degraded state:

## Immediate Action

1. Stop further advancement and mark the transition incomplete or failed.
2. Preserve control-plane events, topology observations, assignments, versions, acknowledgements, queues, and user-impact evidence.
3. Contain at the smallest safe topology or population boundary.
4. Invoke the canonical AI Operations Runbook when user or protected outcomes may be affected.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Observe | Query authoritative effective state by topology and population | Version and assignment map | Telemetry cannot identify state |
| Compare | Diff requested and effective components, routes, policy, index, and configuration | Drift inventory | Multiple sources claim authority |
| Bound | Identify mixed versions, in-flight work, durable state, effects, and users | Impact inventory | Consequence is unbounded |
| Correct | Complete, hold, isolate, or reverse under manifest authority | Transition receipt | Point of no return is crossed |
| Reconcile | Resolve queued work, caches, indexes, external effects, and observers | Steady-state proof | Residual state lacks an owner |

## Verification and Stopping Conditions

Verify configuration convergence, component identity, assignment, exposure, in-flight work, durable state, external effects, health signals, evidence health, delayed outcomes, and recovery capacity.

Stop and escalate when authoritative state is unavailable, rollback would violate compatibility, data or external effects cannot be reconciled, or the observed consequence exceeds the decision authority.

## Reversal

- Execute the canonical manifest recovery path for the recorded transition.
- Restore compatible component and configuration sets, not isolated versions.
- Reconcile in-flight work, caches, indexes, durable state, and external effects.
- Preserve both failed-transition and recovery receipts; rollback is a new transition.

## Evidence and Closure

Record requested and actual identities, drift, affected population, decisions, containment, correction or reversal, convergence, residual state, delayed-outcome checks, and closure authority.

Close when one authorized steady state is verified across topology and population, affected work is reconciled, operations accepts the handoff, and follow-up owners are assigned. Reopen on renewed drift or a late effect.