Make the data boundary stronger than the generated query.

# Safe Database Query Assistant Scenario Pack

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

Use this pack when an AI-assisted workflow turns a question into a database query, executes it against protected or production-shaped data, and explains the result. It is intended for read-only analysis where access controls, query limits, and audit capture are enforced outside the model.

This pack records intent, authority, context, execution, findings, and results. It does not grant database access, make generated queries safe, authorize a mutation, or certify an answer as correct.

## Smallest Credible Starting Set

For a bounded, read-only question over an approved dataset, complete:

1. `query-intent-record.md`
2. `data-access-contract.md`
3. `schema-context-manifest.md`
4. `query-execution-policy.md`
5. `safety-checklist.md`
6. `result-receipt.md`

Attach any runbook whose entry condition is plausible. Use a separately governed workflow for every insert, update, delete, schema change, administrative command, or stored procedure with an unverified effect.

## Users, Owners, and Authority

| Role | Responsibility | Authority boundary |
| --- | --- | --- |
| Requester | States the question, purpose, population, and time window | May request analysis; cannot grant data access or approve a query |
| Query owner | Accepts the intent and owns the answer's use | May narrow or stop the question; cannot weaken access controls |
| Data owner | Defines permitted datasets, purposes, fields, and retention | Grants or denies data use through the authoritative access process |
| Query operator | Submits an approved candidate through the controlled executor | May execute only within the recorded policy and credential |
| Database operator | Owns database health, cancellation, and workload protection | May stop, quarantine, or reschedule work to protect the service |
| Reviewer | Inspects query shape, evidence, limitations, and safety findings | Produces findings or a recommendation, not automatic approval |
| Result verifier | Checks that the result supports the stated answer | Accepts or rejects evidence for the named analytical claim |
| Decision authority | Decides whether the answer may be used for the stated purpose | Records disposition under the owning team's policy |
| Mutation authority | Controls any separately proposed write path | Cannot be inferred from read access, tool access, or requester status |

One person may hold several roles when policy permits. Record each assignment and any separation-of-duties requirement.

## Required Inputs and Entry Criteria

- A specific question, business purpose, intended audience, population, dimensions, measures, and time window.
- A named query owner, data owner, query operator, database operator, reviewer, result verifier, and decision authority.
- An externally enforced read-only credential with least privilege for the approved source, tenant, rows, columns, and operations.
- An approved schema-context snapshot with provenance, freshness, semantics, and known limitations.
- A controlled execution path that enforces parameter binding, statement allowlists, result limits, timeouts, workload limits, and audit records.
- A defined plan or cost review threshold and an escalation path for database health.
- A known treatment for empty, partial, timed-out, suppressed, or irreproducible results.

Do not execute when the purpose, tenant boundary, credential mode, schema freshness, sensitive-data treatment, or effect of the candidate statement is unresolved.

## Working Sequence

| Stage | Required record | Result |
| --- | --- | --- |
| Bound intent | Query Intent Record | Inspectable question, semantics, exclusions, and acceptance claims |
| Authorize data | Data-Access Contract | Enforced source, tenant, row, column, purpose, and retention boundary |
| Admit schema | Schema-Context Manifest | Versioned structural and semantic context with freshness limits |
| Govern execution | Query-Execution Policy | Allowed statements, parameters, limits, cost gates, audit, and mutation separation |
| Inspect | Safety Checklist | Evidence-indexed findings; never automatic approval |
| Execute and explain | Controlled executor and Result Receipt | Query identity, result identity, answer, evidence, limitations, and disposition |

## Completed Walkthrough

Use `examples/read-only-production-analytics-question.md` to inspect all six working records completed for a weekly aggregate question. The walkthrough shows enforced read-only access, current schema semantics, typed parameters, plan evidence, reproducibility, and a decision-use limitation.

## Control Boundary

The model may propose text, but controls that protect data and service health must sit outside the model. At minimum, the execution path independently authenticates the caller, authorizes the dataset and tenant scope, parses or rejects statement types, binds parameters, applies limits and timeouts, records audit evidence, and blocks mutation-capable paths.

Read-only must be enforced by the database credential and execution environment, not by an instruction such as “only generate SELECT.” A mutation requires a new intent record, a separately authorized identity and path, explicit preview and approval, effect verification, and a reversal or compensation plan.

## Runbook Selector

| Condition | Runbook |
| --- | --- |
| Estimated or actual work exceeds the accepted scan, plan, latency, or cost envelope | `runbooks/expensive-query.md` |
| A query waits on or contributes to blocking, deadlock risk, or material contention | `runbooks/lock-contention.md` |
| Join cardinality, grain, filters, grouping, or aggregation may make the answer wrong | `runbooks/incorrect-join-or-aggregation.md` |
| Results, logs, prompts, exports, or explanations expose sensitive data | `runbooks/sensitive-data-exposure.md` |
| The schema snapshot no longer matches the authoritative structure or semantics | `runbooks/stale-schema-context.md` |
| The executor returns incomplete, truncated, sampled, or mixed-success data | `runbooks/partial-results.md` |
| Planning, execution, retrieval, or answer assembly exceeds a deadline | `runbooks/timeout.md` |
| An authorized reviewer cannot reproduce the query result or answer | `runbooks/irreproducible-answer.md` |

## Exit and Acceptance Criteria

Close the work only when:

- the executed statement and parameters match the accepted intent and policy;
- effective identity, source, tenant or row scope, schema version, and execution environment are recorded;
- read-only and least privilege were externally enforced;
- plan or cost evidence and runtime limits stayed within the accepted envelope;
- the answer distinguishes observed facts, calculations, interpretation, and uncertainty;
- suppression, truncation, sampling, missing data, and semantic assumptions are visible;
- checklist findings have owners and dispositions;
- the decision authority records whether and how the answer may be used; and
- the Result Receipt is retrievable without exposing disallowed data.

## Deeper Record Triggers

Attach the applicable core toolkit modules when the work:

- includes personal, confidential, regulated, or otherwise sensitive data;
- crosses tenants, trust boundaries, regions, or purpose restrictions;
- joins sources with different owners, retention rules, or semantic definitions;
- supports a high-consequence operational, financial, legal, or customer decision;
- creates an export, durable cache, downstream dataset, or other retained effect;
- requires a tool with broader access than the question needs;
- proposes any mutation or administrative command; or
- raises the affected population, autonomy, or consequence ceiling.

Typical additions are the AI Fit and Risk Assessment Worksheet, Context Assembly Plan, Tool Permission Matrix, AI Threat Model, Evaluation Plan, AI Operations Runbook, and Principal Design Review Checklist and Record.

## Material Change and Reopening Triggers

Reopen affected records when the question, purpose, audience, source, tenant, row or column scope, schema semantics, credential, query shape, parameters, limits, execution environment, result handling, retention, decision use, or consequence changes. Also reopen when later evidence reveals stale schema context, sensitive-data exposure, a partial result, an incorrect aggregation, or an answer that cannot be reproduced.

# Completed Walkthrough: Read-Only Production Analytics Question

Toolkit schema: `PAISEH-TK-1.0`

Scenario pack: `PAISEH-SC-SDQA-1.0`

Example status: synthetic, completed, and vendor-neutral

This walkthrough answers a bounded operational question using an externally enforced read-only identity. Object names and evidence references are illustrative. The example contains aggregates only and no production values, personal data, connection strings, or credentials.

## Common Artifact Header

| Field | Completed record |
| --- | --- |
| Artifact ID | `SDQA-EX-009`, completed scenario, `1.0` |
| Purpose | Determine the weekly completion rate for eligible onboarding workflows |
| Decision use | Decide whether the operations team should investigate a week-over-week drop |
| Scope | Production analytics replica; approved aggregate view; 2026-07-06 through 2026-07-19 UTC |
| Owners and authority | Query owner: Asha; data owner: Growth Analytics; verifier: Leo; decision authority: Operations lead |
| Evidence | `EV-10` through `EV-18`, retained in protected analytics audit record `AQ-551` |
| Known limitations | Late-arriving completion events can revise the latest day for 48 hours |
| State and expiry | Usable with conditions through 2026-07-21 12:00 UTC |
| Reopening triggers | Measure definition, time window, source snapshot, access scope, query, or intended decision changes |

## 1. Completed Query Intent Record

Question: “What percentage of eligible onboarding workflows completed within 24 hours last week, compared with the previous week?”

| Analytical element | Completed definition |
| --- | --- |
| Population and grain | One eligible workflow start; excluded test and staff accounts |
| Measure | Starts with a qualifying completion event within 24 hours divided by eligible starts |
| Dimensions | Week only; no tenant, user, region, or demographic breakdown |
| Time | Start event in two complete Monday–Sunday UTC windows |
| Join rule | One start to zero or one first qualifying completion; later completions ignored |
| Null and late data | Missing completion is incomplete; latest 48 hours excluded by using complete windows |
| Precision | One decimal percentage point; suppress denominator below 100 |
| Intended use | Investigation trigger, not performance attribution or customer-level action |

Acceptance claims: `QI-01` both windows use the same eligible population; `QI-02` completion is measured within 24 hours; `QI-03` the answer exposes denominators and late-data limitations.

Entry disposition: `ready`. The data owner approved the definitions and aggregate-only use in `INTENT-551`.

## 2. Completed Data-Access Contract

| Boundary | Enforced allowance | Enforcement and evidence |
| --- | --- | --- |
| Endpoint | analytics replica only | connection policy receipt `EV-10` |
| Objects | `analytics.onboarding_weekly_eligible` | object grant inspection `EV-11` |
| Rows | production aggregate rows; no tenant filter is available or needed because the view has no tenant key | view definition and grant `EV-11` |
| Columns | `week_start`, `eligible_starts`, `completed_24h` | column privilege inspection `EV-11` |
| Sensitive data | no direct or indirect identifier is exposed | schema classification `EV-12` |
| Statements | one parsed, parameterized `SELECT` | executor policy `EV-13` |
| Resource envelope | 10-second timeout, 10 MB scan, 10 result rows, one attempt | executor receipt `EV-16` |

The effective identity cannot write, administer, call procedures, impersonate another identity, or reach a primary database. Safe negative tests for write and disallowed-object access both returned policy denials in `EV-10`.

No mutation path was requested. Any mutation would require a new intent record, a distinct identity and execution path, exact human approval, effect verification, and reversal evidence.

## 3. Completed Schema-Context Manifest

Snapshot `SCHEMA-2026-07-20T08:00Z` admitted one governed view:

| Object | Grain and fields | Semantics | Provenance |
| --- | --- | --- | --- |
| `analytics.onboarding_weekly_eligible` | one row per UTC week; three allowed fields | `completed_24h` counts the first qualifying completion within 24 hours; both counts exclude staff and test accounts | catalog version `CAT-77`, metric definition `MET-14` |

No joins were permitted. User, tenant, event, and free-text fields were excluded from context. Compatibility inspection showed the view and three fields at the recorded version (`EV-12`). The workflow would return `schema context insufficient` if the metric version or object identity were absent.

## 4. Completed Query-Execution Policy

The controlled executor admitted only a single parameterized aggregate read over the allowlisted view. It rejected comments, multiple statements, unqualified sources, unapproved functions, writes, administrative forms, and interpolation.

Normalized statement:

```sql
SELECT week_start, eligible_starts, completed_24h
FROM analytics.onboarding_weekly_eligible
WHERE week_start IN (:current_week, :previous_week)
ORDER BY week_start
LIMIT 2
```

Bound parameters were typed dates. The plan estimate was 2 rows and less than 1 MB (`EV-15`), below the 10 MB threshold. The executor ran once, returned 2 rows without truncation, recorded zero retries, and bound the result identity to the schema, policy, statement, parameters, and effective identity (`EV-16`).

## 5. Completed Database Query Safety Checklist

| Evidence ID | Evidence | Result |
| --- | --- | --- |
| `EV-10` | effective identity and safe negative tests | read-only boundary verified |
| `EV-11` | object and column privilege snapshot | only the aggregate view is reachable |
| `EV-12` | schema and metric snapshot | current and compatible |
| `EV-13` | parser and executor policy version | candidate classified as allowed read |
| `EV-14` | normalized query and parameter receipt | typed binding; no interpolation |
| `EV-15` | plan estimate | within workload envelope |
| `EV-16` | execution and result receipt | complete two-row result |
| `EV-17` | independent metric recomputation | calculated rates match |
| `EV-18` | audit retrieval check | another authorized analyst reproduced the result |

All intent, access, schema, query-shape, workload, result, and reproduction checks passed. `F-10` records one accepted limitation: the metric cannot explain why completion changed and must not be reused as causal evidence.

Reviewer recommendation: `execute`. Result-verifier recommendation: `usable with conditions`. Both were advisory until the operations lead recorded the permitted use.

## 6. Completed Database Query Result Receipt

| Field | Completed result |
| --- | --- |
| Execution identity | `AQ-551-EXEC-1`; one attempt; no timeout or cancellation |
| Exact query | protected audit reference `STMT-551`; normalized form shown above |
| Parameters | two typed UTC week-start dates; values retained in the authorized audit record |
| Plan and result | below review threshold; 2 rows returned; no sampling, truncation, or suppression |
| Answer | Completion was 76.8% for the later week and 79.4% for the prior week, a decrease of 2.6 percentage points |
| Denominators | 12,480 eligible starts in the later week and 12,105 in the prior week |
| Interpretation | The decrease is large enough to open an investigation under the operations threshold; this result does not establish a cause |
| Finding | `F-10`, accepted limitation: aggregate comparison is non-causal |
| Final disposition | Usable only to decide whether to investigate; expires at the stated validity time |

The verifier reproduced the calculation from `EV-16` and confirmed identical rounding (`EV-17`, `EV-18`). No sensitive value entered the answer or model-facing context. Reopen if late data revises either count, the metric version changes, or a team requests a finer breakdown or different decision use.

## Why Deeper Controls Were Triggered

Although the output is advisory and aggregate, the source is production-shaped data. That trust-boundary crossing requires externally enforced least privilege, schema provenance, controlled execution, workload limits, audit evidence, and an immutable result receipt. The prompt alone cannot supply those controls.

# Query Intent Record

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

Complete `../../common-artifact-header.md` first. Use this record to make the analytical question precise before generating or executing a query.

## 1. Question and Use

| Field | Record |
| --- | --- |
| Question in the requester's words | |
| Operational or business purpose | |
| Intended audience and decision use | |
| Query owner and requester | |
| Data owner | |
| Result verifier and decision authority | |
| Required-by time and validity window | |
| Consequence if the answer is wrong, late, or unavailable | |

## 2. Analytical Contract

| Element | Required definition | Authoritative source / owner |
| --- | --- | --- |
| Population and unit of analysis | | |
| Measures and calculation rules | | |
| Dimensions and allowed breakdowns | | |
| Time window, event time, and timezone | | |
| Inclusion and exclusion rules | | |
| Join grain and expected cardinality | | |
| Null, duplicate, late-arriving, and deleted-data treatment | | |
| Required precision, rounding, and suppression | | |

- Plain-language answer shape:
- Comparisons or claims that are explicitly out of scope:
- Assumptions the workflow may make:
- Ambiguities that require requester or data-owner resolution:

## 3. Data and Safety Boundary

| Category | Allowed | Excluded | Reason / authority |
| --- | --- | --- | --- |
| Sources, schemas, and environments | | | |
| Tenants, accounts, regions, or row populations | | | |
| Tables, views, fields, and derived attributes | | | |
| Sensitive or identifying data | | | |
| Query operations | Read only | Mutation and administration unless separately authorized | |
| Result detail, export, sharing, and retention | | | |

## 4. Acceptance Claims

| Claim ID | Required claim | Acceptance criterion | Evidence required | Evidence owner |
| --- | --- | --- | --- | --- |
| QI- | | | | |

Required negative or boundary checks:

Known source limitations:

Accepted uncertainty:

## 5. Entry Decision

| Check | Evidence / record | Result | Owner |
| --- | --- | --- | --- |
| Purpose and decision use are legitimate and specific | | Ready / blocked | |
| Analytical terms have authoritative definitions | | Ready / blocked | |
| Tenant, row, column, and sensitive-data boundaries are explicit | | Ready / blocked | |
| Required access can be granted with least privilege and read-only enforcement | | Ready / blocked | |
| Result evidence can support the intended claim | | Ready / blocked | |
| Required deeper toolkit records are attached | | Ready / blocked / not triggered | |

Entry disposition: `ready`, `revise`, `blocked`, or `cancelled`

Rationale, authority, date, expiry, and receipt:

## 6. Reopening Triggers

Reopen this record when the question, purpose, audience, population, measure, dimension, time semantics, join grain, source, access boundary, result detail, retention, intended decision, or consequence changes.

# Data-Access Contract

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

Complete `../../common-artifact-header.md` first. Record the access that the authoritative identity and data platform enforce. Do not use this document as a substitute for access configuration.

## 1. Identity and Authority

| Field | Record |
| --- | --- |
| Requester and query owner | |
| Executing human or service identity | |
| Credential or role identifier | |
| Identity issuer and authentication method | |
| Data owner and access approver | |
| Query operator and database operator | |
| Grant reference, start, expiry, and review date | |
| Purpose and approved environment | |

## 2. Enforced Access Boundary

| Resource boundary | Exact allowance | Enforcement point | Verification evidence | Owner |
| --- | --- | --- | --- | --- |
| Service, cluster, database, or endpoint | | | | |
| Schema, table, and view allowlist | | | | |
| Tenant, account, region, or row policy | | | | |
| Column and derived-field allowlist | | | | |
| Sensitive-data masking or suppression | | | | |
| Statement and function allowlist | | | | |
| Network, client, and execution path | | | | |
| Time, concurrency, and resource envelope | | | | |

Explicitly denied resources and operations:

## 3. Read-Only and Least-Privilege Proof

| Control | Required evidence | Result / evidence ID |
| --- | --- | --- |
| Credential cannot insert, update, delete, merge, truncate, or alter | Effective privilege inspection plus a safe negative test | |
| Credential cannot execute unapproved procedures or administrative commands | Effective privilege and function allowlist inspection | |
| Tenant or row boundary is enforced outside query text | Policy, filtered view, or equivalent enforcement evidence | |
| Disallowed columns remain inaccessible or masked | Effective column privilege or masking evidence | |
| Query cannot switch to a broader identity or source | Connection and impersonation controls | |
| Grant expires or is reviewed on schedule | Expiry and revocation evidence | |

An instruction to produce only read queries is not evidence of read-only enforcement.

## 4. Sensitive Data and Result Handling

- Data classification and handling owner:
- Fields prohibited from model context, logs, prompts, receipts, exports, or explanations:
- Minimum aggregation, suppression, or de-identification rule:
- Authorized result recipients and sharing channel:
- Retention, deletion, and cache policy:
- Audit events and protected audit location:
- Required response if sensitive data is encountered:

## 5. Separately Authorized Mutation Path

This read-only contract grants no mutation authority.

| Mutation requirement | Separate control |
| --- | --- |
| New intent and consequence review | |
| Distinct write-capable identity and execution path | |
| Human approval bound to exact statement, parameters, target, and expiry | |
| Preview, affected-row limit, transaction boundary, and idempotency | |
| Effect verification and immutable receipt | |
| Reversal, compensation, or recovery plan | |

Mutation path owner and authoritative record:

## 6. Revocation and Reopening

- Immediate revocation triggers:
- Revocation operator and procedure:
- Verification that sessions, tokens, caches, and exports are contained:
- Material changes requiring a new access decision:

Reopen this contract when identity, purpose, source, tenant, row policy, columns, sensitive-data classification, statement capability, execution path, environment, retention, or consequence changes.

# Schema-Context Manifest

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

Complete `../../common-artifact-header.md` first. Record only the structural and semantic context the workflow is allowed to use when producing the candidate query.

## 1. Context Snapshot

| Field | Record |
| --- | --- |
| Manifest version and snapshot time | |
| Authoritative catalog, migration, or documentation source | |
| Database environment and schema version | |
| Context assembler and semantic owner | |
| Freshness requirement and expiry | |
| Access contract and Query Intent Record versions | |
| Retrieval or delivery mechanism | |

## 2. Admitted Objects

| Object ID | Qualified object or semantic definition | Type | Grain / key | Allowed fields | Tenant or row boundary | Provenance | Freshness | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| SC- | | Table / view / field / metric / relationship | | | | | | |

Record aliases, enumerations, units, timezone rules, soft-delete behavior, slowly changing dimensions, and other semantics that alter interpretation.

## 3. Relationship and Cardinality Contract

| Relationship ID | Left grain and key | Right grain and key | Expected cardinality | Required filter / temporal rule | Fan-out or omission risk | Evidence |
| --- | --- | --- | --- | --- | --- | --- |
| REL- | | | | | | |

Approved join paths:

Forbidden or unsafe join paths:

## 4. Excluded and Sensitive Context

| Context | Treatment | Enforcement / verification |
| --- | --- | --- |
| Tables, fields, or tenants not required by the intent | Exclude | |
| Personal, confidential, regulated, or secret-bearing fields | Exclude, mask, or minimize | |
| Free-text or untrusted content that may carry instructions | Treat as data, not instructions | |
| Deprecated, experimental, or shadow objects | Exclude unless explicitly approved | |
| Values that belong in bound parameters | Do not embed in reusable schema context | |

## 5. Drift and Missing-Context Behavior

- Authoritative schema-change signal:
- Compatibility check before execution:
- Behavior when an object, field, relationship, or semantic definition is missing:
- Behavior when the snapshot is stale or version identity is unavailable:
- Owner and response time for semantic clarification:
- Cached-context invalidation rule:

The workflow must stop or return `schema context insufficient` when it cannot establish the required object, grain, relationship, or semantic definition. It must not invent names or infer sensitive fields.

## 6. Verification and Reopening

| Check | Evidence ID | Result | Owner |
| --- | --- | --- | --- |
| Every admitted object exists in the target environment | | Pass / fail / indeterminate | |
| Keys, grain, relationships, and semantics match authoritative sources | | | |
| Tenant, row, column, and sensitive-data boundaries match the Access Contract | | | |
| Snapshot is within its freshness and compatibility window | | | |
| Excluded context is absent from the model-facing payload | | | |

Reopen when the schema version, object definition, relationship, metric, data classification, tenant policy, access contract, context source, or freshness requirement changes.

# Query-Execution Policy

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

Complete `../../common-artifact-header.md` first. Define the controls that the query executor enforces independently of model output.

## 1. Execution Boundary

| Field | Record |
| --- | --- |
| Controlled executor and owner | |
| Approved database endpoint and environment | |
| Effective read-only identity | |
| Query Intent, Access Contract, and Schema Manifest versions | |
| Query operator and database operator | |
| Audit location and retention | |
| Policy version, effective time, and expiry | |

## 2. Candidate Admission

| Control | Enforced rule | Enforcement point | Rejection evidence |
| --- | --- | --- | --- |
| Statement class | Parsed allowlist of read-only forms | | |
| Source objects | Qualified table and view allowlist | | |
| Functions and subqueries | Explicitly allowed set | | |
| Tenant and row boundary | Platform-enforced policy plus required predicates where applicable | | |
| Parameters | Typed binding; no value interpolation | | |
| Result shape | Column allowlist, aggregation, suppression, and maximum rows / bytes | | |
| Multi-statement and comments | Reject or normalize under policy | | |
| Administrative or mutation capability | Block and route to the separate mutation path | | |

Do not rely on keyword matching alone when parsing, aliases, functions, procedures, or chained statements can change effect.

## 3. Workload and Cost Envelope

| Limit | Default | Hard maximum | Review threshold | Authority to override |
| --- | --- | --- | --- | --- |
| Planning time | | | | |
| Execution timeout | | | | |
| Rows or bytes scanned | | | | |
| Rows or bytes returned | | | | |
| Estimated plan cost | | | | |
| Memory, spill, or temporary storage | | | | |
| Concurrency and queue time | | | | |
| Retry count and total budget | | | | |

- Required plan or cost evidence before execution:
- Conditions requiring a database-operator checkpoint:
- Cancellation mechanism and owner:
- Behavior when estimates are unavailable:

## 4. Execution, Retry, and Result Rules

1. Bind the accepted parameters and record their safe, redacted identity.
2. Reconfirm effective identity, source, schema compatibility, and read-only mode.
3. Obtain the required plan or cost review before database execution.
4. Execute once within the accepted envelope and capture statement, parameter, plan, timing, row-count, truncation, and cancellation receipts.
5. Treat timeout, partial response, unknown completion, or lost connection as indeterminate until reconciled.
6. Retry only when the failure class, query effect, and remaining budget make retry safe; record every attempt separately.
7. Pass only allowed result fields and aggregates into answer assembly.

## 5. Audit Record

Capture:

- request, intent, policy, access, and schema-context versions;
- requester, operator, effective identity, source, tenant or row scope, and environment;
- normalized query identity and retrievable exact statement;
- parameter names, types, and redacted values or hashes;
- plan or estimate identity and reviewer disposition;
- start, finish, timeout, cancellation, and retry events;
- rows or bytes scanned and returned, result-limit behavior, and result identity;
- policy rejections, sensitive-data controls, findings, and runbook activations; and
- answer and Result Receipt references.

## 6. Separate Mutation Path

Reject every candidate with a possible write, schema, administrative, session-changing, or unverified procedure effect. A separately authorized mutation path must bind approval to the exact target, statement, parameters, preview, affected-row ceiling, transaction behavior, expiry, verification, and reversal plan. This policy cannot promote a read-only request into that path.

## 7. Reopening Triggers

Reopen when statement forms, sources, functions, parameters, limits, cost model, identity, tenant policy, executor, retry behavior, audit capture, result handling, or mutation controls change.

# Database Query Safety Checklist

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

Complete `../../common-artifact-header.md` first. This checklist produces evidence-indexed findings. It does not grant access, approve a query, certify an answer, authorize a mutation, or replace the data owner's and database operator's controls.

## 1. Review Basis

| Field | Record |
| --- | --- |
| Intent, Access Contract, Schema Manifest, and Execution Policy versions | |
| Candidate query identity and parameters | |
| Source, environment, effective identity, and tenant or row scope | |
| Requester, operator, reviewer, result verifier, and database operator | |
| Data owner and decision authority | |
| Required handling, workload, and audit policies | |

## 2. Evidence Index

| Evidence ID | Claim or check | Authoritative source / command | Snapshot / environment | Result | Limitation | Reproduction reference | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| EV- | | | | | | | |

Record retrievable plans, privilege inspections, schema versions, normalized statements, parameter receipts, query receipts, result identities, reconciliation records, and review locations. `The query ran` is not sufficient evidence.

## 3. Intent, Access, and Context Findings

| Check | Evidence ID | Result | Finding ID |
| --- | --- | --- | --- |
| Population, measures, dimensions, time semantics, exclusions, and intended use are explicit | | Pass / fail / indeterminate / not applicable | |
| Effective access is least privilege and externally enforced read only | | | |
| Tenant or row boundaries do not depend on model compliance | | | |
| Tables, views, columns, functions, and operations are allowlisted | | | |
| Sensitive fields are excluded, masked, minimized, or suppressed as required | | | |
| Schema objects, grain, keys, relationships, and semantics are current and authoritative | | | |
| Values are typed and bound as parameters rather than interpolated | | | |

## 4. Query Shape and Workload Findings

| Check | Evidence ID | Result | Finding ID |
| --- | --- | --- | --- |
| Statement parser classifies the candidate as allowed and read only | | | |
| Join keys, cardinality, filters, grouping, and aggregation preserve the intended grain | | | |
| Nulls, duplicates, deletions, late data, timezone, and boundary dates are handled | | | |
| Plan or cost evidence is within the accepted scan, latency, memory, and concurrency envelope | | | |
| Result rows, bytes, detail, and export behavior stay within policy | | | |
| Timeout, cancellation, retry, and unknown-outcome behavior are safe | | | |
| Audit records bind identity, query, parameters, source, plan, result, and answer | | | |

## 5. Result and Answer Findings

| Check | Evidence ID | Result | Finding ID |
| --- | --- | --- | --- |
| Result is complete, or partiality, truncation, sampling, and suppression are explicit | | | |
| Answer separates facts, calculations, interpretation, and uncertainty | | | |
| Every material claim maps to retrievable result evidence | | | |
| Empty and missing data are not presented as zero or absence without support | | | |
| Units, rounding, population, and time window remain visible | | | |
| An authorized reviewer can reproduce the result from the recorded snapshot and parameters | | | |
| Intended use stays within the accepted purpose and consequence | | | |

## 6. Findings Register

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

Allowed states: `open`, `accepted limitation`, `corrected`, `verified`, `deferred`, or `not reproducible`. Only the named authority may accept a limitation or close a finding.

## 7. Review Outcome

- Claims verified:
- Claims not verified:
- Residual uncertainty:
- Open or accepted findings:
- Reviewer recommendation: `execute`, `return`, `narrow`, `escalate`, or `do not execute`
- Result-verifier recommendation: `usable`, `usable with conditions`, `not usable`, or `indeterminate`
- Conditions and expiry:
- Decision authority, final disposition, date, and receipt:

Recommendations are advisory unless the reviewer or verifier is separately recorded as the applicable decision authority.

## 8. Reopening Triggers

Reopen when intent, source, identity, tenant or row scope, schema context, query, parameters, plan, limits, result completeness, sensitive-data handling, decision use, or consequence changes, or when later evidence contradicts a finding.

# Database Query Result Receipt

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

Complete `../../common-artifact-header.md` first. Preserve this receipt as an immutable account of the executed query, returned evidence, answer, limitations, and decision use. Keep sensitive values in their authorized system and reference them from this record.

## 1. Request and Execution Identity

| Field | Actual value |
| --- | --- |
| Query Intent, Access Contract, Schema Manifest, Execution Policy, and Checklist versions | |
| Request, session, and execution IDs | |
| Requester, query owner, operator, reviewer, and result verifier | |
| Effective identity, source, environment, and tenant or row scope | |
| Schema snapshot and semantic-definition versions | |
| Start, finish, expiry, and answer-validity times | |

## 2. Executed Candidate

| Field | Actual value / evidence reference |
| --- | --- |
| Normalized query identity and exact statement location | |
| Parameter names, types, and redacted identities | |
| Plan or cost estimate and review disposition | |
| Attempt count, timeout, and cancellation state | |
| Rows or bytes scanned and returned | |
| Result limit, truncation, sampling, or suppression | |
| Query-engine result identity or snapshot reference | |

## 3. Answer and Evidence

- Plain-language answer:
- Observed facts:
- Calculations or transformations:
- Interpretation:
- Population, measures, dimensions, and time semantics:
- Units, rounding, and suppression:

| Claim ID | Result evidence ID | Support | Limitation or uncertainty | Verifier |
| --- | --- | --- | --- | --- |
| QI- | EV- | Supported / unsupported / indeterminate | | |

Do not present an empty, partial, truncated, sampled, timed-out, or unreconciled result as a complete answer.

## 4. Safety Findings and Disposition

| Finding ID | Evidence ID(s) | Final state | Correction / accepted limitation | Authority | Reopening trigger |
| --- | --- | --- | --- | --- | --- |
| F- | | | | | |

- Sensitive-data handling result:
- Read-only and tenant-boundary verification:
- Schema-freshness result:
- Reproduction status:
- Runbooks activated:
- Residual uncertainty:

## 5. Decision Use and Closure

- Result-verifier recommendation: `usable`, `usable with conditions`, `not usable`, or `indeterminate`
- Decision authority and final disposition:
- Permitted audience and decision use:
- Conditions, expiry, and required caveat:
- Prohibited reuse or downstream action:
- Follow-up owner and due date:
- Evidence-retention and deletion result:
- Supersedes / superseded by:

## 6. Reopening Triggers

Reopen when the question, source data, schema or semantic version, query, parameters, access scope, result completeness, calculation, intended audience, decision use, or consequence changes, or when a reviewer cannot reproduce the result.

# Runbook: Expensive Query

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

Complete `../../../common-artifact-header.md` first. Use this runbook when a plan estimate, admission control, or live execution exceeds the accepted scan, cost, latency, memory, spill, or concurrency envelope.

## Entry Conditions and Authority

- Triggering estimate, limit, query identity, and evidence:
- Current execution state:
- Query owner, query operator, and database operator:
- Authority to reject, cancel, reschedule, or approve a revised envelope:
- Separate authority required for a broader dataset, replica, export, or budget:

## Immediate Action

1. Prevent execution, or cancel the live query through the controlled database path.
2. Preserve the candidate, bound parameters, plan, estimates, runtime evidence, and cancellation receipt.
3. Confirm that no automatic retry can resubmit the same expensive work.
4. Notify the database operator when workload health or shared capacity may be affected.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Confirm | Compare estimate and actual work with the recorded policy envelope | Named exceeded limit and trustworthy measurement | Cost evidence is missing or database health is degrading |
| Localize | Identify unbounded scans, fan-out joins, nonselective filters, sorts, or repeated work | Bounded causal explanation | Diagnosis requires broader data access |
| Reduce | Narrow time, population, columns, grain, or approved source; use an authorized aggregate when available | Revised intent or plan with preserved semantics | Reduction changes the question or hides required data |
| Review | Obtain a fresh plan or cost review | Evidence within limits and reviewer disposition | An override or new budget is required |
| Execute | Run once under the accepted limits | Execution and result receipt | Limits are exceeded or cancellation fails |

## Verification and Stopping Conditions

Recovery requires a current plan within the accepted envelope, unchanged analytical meaning or an explicitly revised Query Intent Record, successful cancellation or completion of prior attempts, and no concealed partial result.

Stop and escalate when workload health remains at risk, the database operator cannot verify cancellation, the only viable query requires a broader consequence or budget, or the estimate cannot be trusted.

## Reversal

- Cancellation or workload-isolation procedure:
- Temporary exports, tables, caches, or queued work to remove:
- Reversion of any temporary limit or routing change:
- Evidence that shared workload health returned to its prior state:

## Evidence and Closure

Record estimates, plans, limits, attempts, cancellation, revised query identity, workload health, result status, and authority receipts.

Close only when the database operator confirms containment, the result verifier accepts the revised evidence or marks the answer unavailable, and the Result Receipt exposes any change in scope or meaning. Reopen if actual work exceeds the reviewed plan.

# Runbook: Lock Contention

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

Complete `../../../common-artifact-header.md` first. Use this runbook when a query waits on locks, contributes to blocking, increases deadlock risk, or materially delays an operational workload.

## Entry Conditions and Authority

- Triggering wait, blocker, query, session, and evidence:
- Affected workload and consequence:
- Query operator, database operator, and incident owner when applicable:
- Authority to cancel this query or session:
- Separate authority required to cancel another session, change isolation, or alter database configuration:

## Immediate Action

1. Stop retries and prevent new submissions for the same intent.
2. Capture session, transaction, wait, blocker, start-time, and query identities without copying sensitive result data.
3. Ask the database operator to cancel the assistant query when it is contributing to risk.
4. Do not terminate another owner's workload or change isolation through this pack.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Classify | Determine whether this query is waiting, blocking, or part of a cycle | Database-native wait evidence | Session state is unknown or evidence requires elevated access |
| Contain | Cancel or quarantine the authorized assistant session | Cancellation and session-state receipt | Cancellation fails or production impact grows |
| Explain | Identify transaction scope, access path, long scan, or workload interaction | Bounded cause tied to observed waits | Another workload must be changed |
| Revise | Narrow the query or route it to an already authorized safe source or window | Fresh plan and unchanged or revised intent | Semantics, freshness, or purpose changes |
| Reverify | Execute only with database-operator clearance | No material wait plus valid result evidence | Contention returns |

## Verification and Stopping Conditions

Recovery requires terminal status for the affected assistant session, cleared or accepted waits, stable workload health, and a fresh result obtained without hidden partiality.

Stop and escalate to the owning incident path when blocking affects service objectives, the causal session cannot be identified, cancellation has an unknown outcome, or resolution requires terminating another workload or changing database configuration.

## Reversal

- Cancel or close the assistant session:
- Undo temporary routing, scheduling, or workload-policy changes:
- Remove invalid partial results from answer assembly:
- Evidence that wait state and workload health returned to an accepted condition:

## Evidence and Closure

Record wait graphs or equivalent evidence, session identities, actions, authority, cancellation outcome, workload health, revised plan, and result disposition.

Close only when the database operator confirms containment and the Result Receipt marks the original attempt failed or indeterminate. Reopen if the same query shape recreates contention.

# Runbook: Incorrect Join or Aggregation

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

Complete `../../../common-artifact-header.md` first. Use this runbook when join cardinality, grain, filters, grouping, duplicates, null handling, or aggregation may make a result materially wrong.

## Entry Conditions and Authority

- Triggering discrepancy, claim, query, and result identities:
- Potentially affected answers and decisions:
- Query owner, semantic owner, reviewer, and result verifier:
- Authority to withdraw an answer and correct the query:
- Separate authority required to notify downstream users or reverse a decision:

## Immediate Action

1. Mark affected claims and receipts `indeterminate`; stop reuse of the answer.
2. Preserve the exact query, parameters, schema snapshot, result identity, and evidence that exposed the discrepancy.
3. Notify the query owner and any known recipient who may act on the result.
4. Do not repair the number by changing filters or aggregation until the intended grain and semantics are re-established.

## Diagnosis and Correction

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Reproduce | Re-run against the recorded snapshot when authorized | Same discrepancy or documented non-reproduction | Source data changed and no snapshot exists |
| Establish grain | Name the unit of analysis before and after every join and aggregation | Semantic-owner confirmation | No authoritative definition exists |
| Test cardinality | Measure unmatched keys, duplicates, fan-out, nulls, and boundary filters | Evidence for each relationship assumption | Inspection requires disallowed data |
| Correct | Make the smallest query or intent change that restores the accepted semantics | New candidate tied to a revised claim | The question or population changes materially |
| Reverify | Compare independent totals, invariants, and representative slices | Reproducible support for each claim | Cross-checks disagree |

## Verification and Stopping Conditions

Recovery requires authoritative grain and measure definitions, explicit cardinality evidence, stable totals or explained differences, and an independently reproducible corrected result.

Stop and escalate when semantics remain disputed, a trustworthy snapshot is unavailable, downstream decisions cannot be identified, or correction changes the accepted purpose or consequence.

## Reversal

- Withdraw or supersede the incorrect Result Receipt:
- Remove invalid exports, caches, or derived artifacts through their authoritative path:
- Notify affected recipients and decision owners:
- Decision reversal or correction owner:

## Evidence and Closure

Record original and corrected query identities, result comparison, relationship tests, semantic decisions, affected recipients, corrections, and superseding receipt.

Close only when the result verifier accepts the corrected evidence, the decision authority disposes of affected uses, and the incorrect receipt remains traceable as superseded. Reopen if source drift or a new population changes cardinality.

# Runbook: Sensitive-Data Exposure

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

Complete `../../../common-artifact-header.md` first. Use this runbook when sensitive data appears outside its authorized boundary in a query, parameter, result, prompt, model context, log, cache, export, answer, or receipt.

## Entry Conditions and Authority

- Triggering artifact, data class, and exposure channel:
- Known or potential recipients and systems:
- Data owner, security or privacy incident owner, and query owner:
- Authority to stop execution, revoke access, quarantine artifacts, and notify responders:
- Actions reserved for the authoritative incident process:

## Immediate Action

1. Stop the query workflow and prevent further display, logging, export, retry, or answer delivery.
2. Preserve minimal metadata and protected evidence through the approved incident path; do not paste exposed values into this runbook.
3. Revoke or suspend the affected credential and session when authorized.
4. Notify the data owner and invoke the applicable security or privacy incident process.

## Containment and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Bound | Identify data classes, fields, records, recipients, stores, and time window | Exposure inventory without unnecessary replication | Scope is unknown or regulated response may apply |
| Contain | Quarantine results, prompts, logs, caches, exports, and receipts | Access and deletion or quarantine receipts | A downstream system is outside operator authority |
| Correct | Restore masking, column denial, row policy, minimization, and result handling | Enforced-control evidence | Correction depends only on prompt instructions |
| Rotate | Revoke or rotate credentials and links when exposure permits further access | Identity-system receipts | Privilege state is uncertain |
| Reverify | Run approved negative tests with non-sensitive fixtures | Disallowed fields cannot reach any output channel | Production data would be required for the test |

## Verification and Stopping Conditions

Recovery requires incident-owner approval, effective containment, externally enforced access and masking controls, verified downstream handling, and an explicit decision on whether query service may resume.

Stop ordinary toolkit work when legal, regulatory, contractual, employee, customer, or security notification may be required. The authoritative incident process owns those decisions.

## Reversal

- Credential and session revocation:
- Quarantine, deletion, or access-restriction actions:
- Cache, model-context, log, export, and receipt treatment:
- Restoration of safe access and evidence that broader privilege is absent:

## Evidence and Closure

Reference the incident record, affected artifact identities, containment receipts, control correction, negative tests, notification disposition, and recovery authority. Keep sensitive values out of this file.

Close only under incident-owner authority when containment and required follow-up are verified. Reopen on any new recipient, store, field, record, or uncontrolled copy.

# Runbook: Stale Schema Context

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

Complete `../../../common-artifact-header.md` first. Use this runbook when model-facing schema context no longer matches authoritative structure, relationships, data classification, or business semantics.

## Entry Conditions and Authority

- Triggering schema, migration, catalog, semantic, or query evidence:
- Manifest and target-environment versions:
- Schema-context owner, semantic owner, and query owner:
- Authority to invalidate context, cancel queries, and refresh the manifest:
- Separate authority required to accept compatibility or semantic uncertainty:

## Immediate Action

1. Stop new generation and execution that depends on the affected context.
2. Mark associated queries, answers, and Result Receipts `indeterminate`.
3. Invalidate or quarantine the stale snapshot and preserve its identity for traceability.
4. Fetch authoritative metadata only through the approved context path.

## Diagnosis and Correction

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Compare | Diff objects, fields, types, keys, relationships, policies, and semantics | Exact drift inventory | Authoritative sources disagree |
| Bound impact | Find generated or executed queries that used the stale manifest | Query and receipt inventory | Audit coverage is incomplete |
| Refresh | Build a least-privilege snapshot from authoritative sources | New manifest with provenance and expiry | Refresh would admit sensitive or unapproved context |
| Validate | Check existence, grain, keys, semantics, and access alignment | Owner-reviewed compatibility evidence | Semantic meaning remains unresolved |
| Reissue | Regenerate and reverify affected queries and answers | Superseding query and result identities | Results differ without explanation |

## Verification and Stopping Conditions

Recovery requires an authoritative, current manifest; confirmed access alignment; successful compatibility checks; and disposition of every affected answer.

Stop and escalate when no semantic owner can resolve drift, old results influenced high-consequence decisions, or audit evidence cannot identify affected work.

## Reversal

- Remove the stale snapshot from active retrieval and caches:
- Restore the last compatible manifest only when its validity is proven:
- Withdraw or supersede affected answers and exports:
- Evidence that generation cannot select the stale version:

## Evidence and Closure

Record drift, affected queries, invalidation, replacement provenance, compatibility checks, result differences, notifications, and superseding receipts.

Close only when the schema-context and semantic owners approve the new manifest and each affected result has a recorded disposition. Reopen on further drift or unresolved semantic change.

# Runbook: Partial Results

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

Complete `../../../common-artifact-header.md` first. Use this runbook when a response is truncated, sampled, paginated incompletely, suppressed, interrupted, mixed-success, or assembled from sources with unequal completion.

## Entry Conditions and Authority

- Triggering limit, status, missing partition, or reconciliation evidence:
- Query, attempt, and result identities:
- Query owner, operator, result verifier, and decision authority:
- Authority to retry, narrow the question, or return an explicitly partial answer:
- Separate authority required for a broader limit, export, or retained dataset:

## Immediate Action

1. Prevent the workflow from labeling the result complete.
2. Preserve returned rows, completion markers, limits, attempt status, and missing-scope evidence in the authorized result store.
3. Mark affected claims `indeterminate` unless the Query Intent Record explicitly permits a partial or sampled answer.
4. Stop automatic pagination or retry when it could exceed the workload or data-access envelope.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Classify | Identify truncation, suppression, sampling, page loss, partition failure, or interrupted execution | Named partiality mode | Completion state is unknown |
| Measure | Quantify returned and missing scope at the accepted grain | Coverage and denominator evidence | Missing scope cannot be bounded |
| Reconcile | Check all pages, partitions, sources, and attempts for overlap and gaps | Complete attempt inventory | Duplicate or mixed snapshots cannot be resolved |
| Decide | Retry safely, narrow intent, or return a labeled partial answer | Authority and revised acceptance criterion | The intended decision requires completeness |
| Reverify | Re-run coverage and claim checks | Complete result or explicit partial-result evidence | Limits recur |

## Verification and Stopping Conditions

A complete answer requires verified coverage of the accepted population and terminal success for every required component. A partial answer requires explicit authorization, quantified coverage, visible caveats, and a decision use that tolerates the gap.

Stop when missing scope is unknown, snapshots differ materially, retries may duplicate or exceed limits, or suppression rules prevent the requested detail.

## Reversal

- Withdraw any answer that omitted the partial-result label:
- Remove or supersede incomplete exports and caches:
- Cancel queued pagination or retries:
- Evidence that downstream users received the corrected status:

## Evidence and Closure

Record completion markers, coverage, limits, attempts, reconciliation, accepted use, caveats, and the final result identity.

Close only when the result verifier records `complete`, `usable as explicitly partial`, or `not usable`, and the Result Receipt matches that disposition. Reopen when a missing page, partition, or source arrives.

# Runbook: Query Timeout

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

Complete `../../../common-artifact-header.md` first. Use this runbook when planning, queueing, execution, result transfer, or answer assembly exceeds its deadline.

## Entry Conditions and Authority

- Timed-out stage, deadline, query, attempt, and session identities:
- Known execution and cancellation state:
- Query operator, database operator, and query owner:
- Authority to cancel, inspect status, retry, or narrow intent:
- Separate authority required to increase a timeout or workload budget:

## Immediate Action

1. Mark the attempt and affected answer `indeterminate`.
2. Stop automatic retry until the database operator reconciles execution state.
3. Request cancellation through the controlled executor when the query may still be running.
4. Preserve timing, session, query, parameter, plan, and cancellation evidence.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Reconcile | Determine queued, running, cancelled, completed, or unknown state | Authoritative terminal or current session state | State remains unknown |
| Localize | Separate queue, lock, plan, scan, transfer, and answer-assembly delay | Stage-specific timing | Database health is affected |
| Bound | Confirm retry budget and read-only effect | Safe retry decision | Query or procedure effect is uncertain |
| Correct | Narrow query, repair plan, or use an already approved source or window | Fresh plan within existing intent | Timeout increase or semantic change is required |
| Reverify | Execute once and capture terminal evidence | Timely, complete result | Deadline is exceeded again |

## Verification and Stopping Conditions

Recovery requires a terminal status for every prior attempt, current plan evidence, a complete result within policy, and no duplicate or mixed-snapshot answer.

Stop and escalate when cancellation fails, state is unknown, contention or service degradation is present, or success requires a broader timeout, cost, source, or purpose.

## Reversal

- Cancel active and queued attempts:
- Remove partial results from answer assembly:
- Undo temporary routing or limit changes:
- Evidence that no prior attempt remains active:

## Evidence and Closure

Record stage timings, attempts, session states, cancellation, correction, final result identity, and authority receipts.

Close only when the database operator confirms terminal states and the Result Receipt marks each timed-out attempt and the final disposition. Reopen on another timeout or delayed completion from an earlier attempt.

# Runbook: Irreproducible Answer

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

Complete `../../../common-artifact-header.md` first. Use this runbook when an authorized reviewer cannot reproduce the recorded result or the plain-language answer from the preserved query evidence.

## Entry Conditions and Authority

- Original and reproduction query, result, and answer identities:
- Observed difference and affected claims:
- Original operator, reproducing reviewer, semantic owner, and result verifier:
- Authority to access the same snapshot and withdraw or supersede the answer:
- Separate authority required to restore data, widen access, or disclose sensitive evidence:

## Immediate Action

1. Mark affected claims and decision use `indeterminate`.
2. Preserve both attempts, including exact query references, parameters, identities, schema versions, timestamps, environment, and result metadata.
3. Stop downstream reuse until the difference has a bounded explanation.
4. Confirm that reproduction uses authorized access; do not broaden privileges merely to match the original.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Align | Compare query text, parameters, identity, tenant scope, source, snapshot, timezone, and limits | Exact difference inventory | Original evidence is missing |
| Isolate | Separate source-data drift from schema, execution, nondeterminism, or answer-transformation differences | Bounded hypothesis and disconfirming checks | No stable snapshot or ordering exists |
| Recompute | Run against the same authorized snapshot or an agreed replacement | Reproducible result identity | Access or retention policy forbids reconstruction |
| Rebuild answer | Map facts and calculations to the reproduced result | Claim-level evidence | Interpretation still differs |
| Supersede | Issue a corrected receipt or record why no reliable answer is available | Decision-authority disposition | Prior downstream action remains unresolved |

## Verification and Stopping Conditions

Recovery requires enough preserved identity to explain the difference, repeatable results under the accepted snapshot and scope, and a claim-to-evidence mapping another authorized reviewer can follow.

Stop and escalate when the original snapshot is unavailable, result ordering or sampling was uncontrolled, source mutation prevents reconstruction, audit evidence is incomplete, or a high-consequence decision used the answer.

## Reversal

- Withdraw or supersede the irreproducible Result Receipt:
- Remove invalid cached answers, exports, or derived artifacts:
- Notify known recipients and decision owners:
- Restore reproducible snapshot or evidence handling when authorized:

## Evidence and Closure

Record comparison, causal explanation, reproduction procedure, result identities, affected recipients, corrected claims, and superseding receipt.

Close only when the result verifier confirms reproduction or the decision authority records the answer unusable. Reopen when another authorized reproduction yields a material difference.