Make every knowledge claim carry its evidence boundary.

# Internal Knowledge and Retrieval Assistant Scenario Pack

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

Use this pack when an assistant answers internal questions from permission-aware sources whose authority, freshness, effective time, or agreement matters. It helps the team preserve the difference between a plausible answer and a supported answer.

This pack assembles scenario records. It does not replace the source-chapter methods in the Production Prompt Specification, Context Assembly Plan, Evaluation Plan, AI Threat Model, or AI Operations Runbook.

## When to Use This Pack

Use it for policy, product, engineering, support, or operational knowledge when an answer must cite internal evidence and respect the requester's effective access. Do not use it to disguise an external action, a regulated decision, or an unsupported recommendation as knowledge retrieval.

## Roles and Authority

| Role | Responsibility | Authority retained |
| --- | --- | --- |
| Requester | States the question, purpose, decision use, and time need | May clarify intent; cannot broaden source access |
| Knowledge owner | Owns source authority, lifecycle, and correction | Declares authoritative sources and resolves source policy |
| Context owner | Maintains the applicable Context Assembly Plan | Defines admissible retrieval and assembly behavior |
| Access-control owner | Enforces principal, tenant, record, and field scope | Grants or denies access outside the model |
| Answer verifier | Inspects claims, citations, coverage, conflict, and uncertainty | Produces evidence-indexed findings, not automatic approval |
| Decision authority | Decides whether the answer may support the named use | Accepts, narrows, defers, or rejects decision use |
| Operations owner | Owns failure handling, correction, and user notification | Contains affected answers and verifies restoration |

## Minimum Viable Pack

For bounded advisory work, complete:

1. Common Artifact Header.
2. Knowledge Request Record.
3. The applicable core Context Assembly Plan.
4. Knowledge Answer Review Checklist.
5. Knowledge Answer Receipt.

Add the Production Prompt Specification when maintained instructions control claim shape, citation behavior, refusal, or conflict handling. Add the Evaluation Plan for quality claims or release decisions, the AI Threat Model for untrusted or sensitive sources, and the AI Operations Runbook for production detection, correction, and recovery.

## Entry Criteria

- The requester, purpose, audience, decision use, and required effective time are known.
- Source authority and access enforcement exist outside the model.
- The applicable Context Assembly Plan identifies provenance, freshness, permission, coverage, and conflict states.
- The answer contract can represent missing, partial, stale, conflicting, unauthorized, and unavailable evidence.
- The verifier and decision authority are named when the answer can influence a material decision.

## Working Sequence

1. Bind the question and permitted use in the Knowledge Request Record.
2. Assemble evidence under the canonical Context Assembly Plan.
3. Produce claim-level citations and explicit completeness states.
4. Inspect evidence, conflicts, freshness, and decision-use limits with the checklist.
5. Let the named authority decide permitted use.
6. Preserve the result and its limitations in the Knowledge Answer Receipt.

The assistant must not infer permission from retrievability, choose institutional truth by rhetorical confidence, or hide missing support behind a fluent synthesis.

## Completed Walkthrough

Use `examples/conflicting-or-stale-knowledge-sources.md` to inspect a completed request, canonical Context Assembly Plan handoff, evidence-indexed review, bounded answer, and correction path when two current-looking policy sources disagree.

## Exit and Acceptance Criteria

- Every material claim maps to retrievable evidence or is marked unsupported.
- Citations identify exact source versions or effective-time references.
- Permission decisions apply to source retrieval, caches, derived passages, and the returned answer.
- Conflicts and stale evidence are visible; unresolved material conflict blocks an unqualified answer.
- The receipt names completeness, permitted decision use, limitations, expiry, and correction path.
- Findings have owners and only the recorded authority closes or accepts them.

## Failure Paths

- Use `runbooks/conflicting-or-stale-sources.md` when source disagreement or effective-time mismatch can change the answer.
- Use `runbooks/access-scope-or-citation-failure.md` when retrieval, caching, citation, or answer rendering may exceed permission or lose evidence lineage.

## Material Change and Reopening Triggers

Reopen affected records when the question, audience, decision use, requester principal, source authority, corpus or index identity, access policy, ranking or compression behavior, citation contract, freshness threshold, effective-time need, answer schema, supported population, or consequence changes. Reopen a receipt when a source is corrected, withdrawn, reclassified, or shown to conflict with a material claim.

# Completed Walkthrough: Conflicting and Stale Knowledge Sources

Toolkit schema: `PAISEH-TK-1.0`

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

Example status: synthetic, completed, and vendor-neutral

This walkthrough shows an internal assistant refusing to collapse two conflicting policy sources into a confident answer. It uses the pack records and the canonical Context Assembly Plan; it does not redefine retrieval, ranking, or permission methods owned by Chapter 5.

## Common Artifact Header

| Field | Completed record |
| --- | --- |
| Artifact ID | `IKRA-EX-017`, completed scenario, `1.0` |
| Question | Which expense-approval threshold applies to regional team leads today? |
| Decision use | Advisory preparation for an expense request; not approval authority |
| Population and scope | Internal employees with access to the general finance-policy collection |
| Owners and authority | Requester: Jules; knowledge owner: Finance Policy; reviewer: Priya; policy authority: Finance Director |
| Source records | Context Assembly Plan `CAP-FIN-6`; request `KR-017`; review `KRC-017`; receipt `KAR-017` |
| Known gap | Two admitted authoritative-looking sources state different thresholds and effective dates |
| State | Closed with a bounded `unable to determine` answer and an owned correction |
| Reopening triggers | Policy owner resolves conflict, a newer authoritative source appears, or the question or access scope changes |

## 1. Completed Knowledge Request Record

| Field | Completed record |
| --- | --- |
| Request and question | `KR-017`: current approval threshold for a regional team lead |
| Intended decision | Decide whether to route an expense request to the next approval tier |
| Consequence if wrong | An unauthorized expense could proceed or valid work could be delayed |
| Answer owner and reviewer | Finance Knowledge team; Priya |
| Source authority required | Current Finance Policy Register or a source explicitly incorporated by it |
| Freshness and effective time | Must be effective on 2026-07-23; sources modified more than 90 days ago need current-authority confirmation |
| Conflict behavior | Do not select a threshold when authoritative sources conflict; cite both and route to Finance Policy |
| Citation contract | Every threshold and effective-date claim needs a retrievable source reference and section |
| Disclosure boundary | General finance policy only; no expense records, employee data, or restricted exceptions |

Entry disposition: `ready` because the question, authority requirement, access boundary, and conflict behavior were explicit. The assistant had no authority to approve an expense or resolve policy.

## 2. Canonical Context Assembly Handoff

Context Assembly Plan `CAP-FIN-6` admitted two accessible sources:

| Evidence ID | Source | Authority and freshness evidence | Conflict |
| --- | --- | --- | --- |
| `EV-61` | Finance Policy Register `FPR-12`, section 4.2 | register marks it effective 2026-01-01; modified 2026-01-03 | threshold stated as 5,000 accounting units |
| `EV-62` | Regional Operations Handbook `ROH-9`, section 7.1 | handbook owner marked revision effective 2026-04-15; not incorporated by `FPR-12` | threshold stated as 7,500 accounting units |
| `EV-63` | source-index receipt | both documents indexed and cited from current snapshots | does not resolve authority |

Ranking confidence could not settle a governance conflict. The context plan therefore returned both sources with `conflict unresolved`, blocked a single-value answer, and activated the conflicting-or-stale-sources runbook.

## 3. Completed Knowledge Answer Review Checklist

| Check | Evidence | Result | Finding |
| --- | --- | --- | --- |
| Request states the decision and consequence | `KR-017` | Pass | — |
| Every material claim has an admitted retrievable source | `EV-61`, `EV-62` | Pass | — |
| Source authority and effective time support one current answer | `EV-61`, `EV-62` | Fail | `F-61` |
| Conflicts are visible rather than silently ranked away | `CAP-FIN-6` | Pass | — |
| Access and disclosure stay within requester scope | `EV-63` | Pass | — |
| Answer distinguishes sourced facts, uncertainty, and next authority | draft answer `ANS-017-A` | Pass | — |

| Finding ID | Observation and consequence | Required action | State |
| --- | --- | --- | --- |
| `F-61` | Two current-looking sources specify different thresholds, and the register does not incorporate the newer handbook | Finance Policy must identify the controlling source and correct or supersede the other | Open; owner Finance Policy; due 2026-07-25 |

Reviewer recommendation: `return bounded uncertainty with escalation`. The checklist produced a finding; it did not choose the policy or approve a decision.

## 4. Completed Knowledge Answer Receipt

Final answer:

> I cannot determine one current threshold from the authorized sources. The Finance Policy Register states 5,000 accounting units in section 4.2, while the Regional Operations Handbook states 7,500 in section 7.1. The register does not show that it incorporates the handbook revision. Route this expense to Finance Policy before relying on either threshold.

| Claim | Evidence | Support and limitation |
| --- | --- | --- |
| Register states 5,000 | `EV-61` | supported as document content; current controlling authority unresolved |
| Handbook states 7,500 | `EV-62` | supported as document content; incorporation unresolved |
| Sources conflict | `EV-61`, `EV-62` | supported |
| No single threshold can be established | `CAP-FIN-6`, `F-61` | supported within the admitted source set |

Disposition: `answered with bounded uncertainty`. Permitted use was limited to routing the request for policy clarification. The receipt prohibited using either number as approval authority.

Correction ticket `KNOW-332` bound `F-61`, both source snapshots, the policy owner, and the due date. Reopen the answer when the Finance Director resolves authority, either source is superseded, or a different requester scope or decision use applies.

## Failure-Runbook Result

The runbook stopped confident answer assembly, preserved both snapshots, recorded the effective-time and authority gap, and routed the conflict without widening source access. Closure required an honest bounded answer and an owned correction path—not a fabricated consensus.

# Knowledge Request Record

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

Complete `../../common-artifact-header.md` first. Use this record to bind one question to a requester, purpose, evidence need, and permitted decision use before retrieval begins.

## 1. Request Identity

| Field | Record |
| --- | --- |
| Request and session ID | |
| Requester principal, tenant, and role | |
| Request owner | |
| Intended audience | |
| Request time and required effective time | |
| Applicable policy and Context Assembly Plan | |

## 2. Question and Decision Use

- Exact question:
- Business or engineering purpose:
- Decision, action, or communication the answer may inform:
- Prohibited or unsupported uses:
- Consequence if the answer is wrong, incomplete, stale, or disclosed:
- Required answer-by time:

## 3. Evidence Contract

| Requirement ID | Fact or claim needed | Source-authority domain | Freshness/effective-time need | Minimum support | Absence or conflict behavior |
| --- | --- | --- | --- | --- | --- |
| KR- | | | | | |

- Required source classes:
- Explicitly excluded source classes:
- User assertions to treat as evidence inputs rather than instructions:
- Citation granularity and retrievability requirement:
- Minimum coverage and stopping rule:

## 4. Access and Disclosure Boundary

- Effective access-decision reference:
- Allowed repositories, collections, records, fields, and derived stores:
- Cross-tenant, cross-domain, or restricted boundaries:
- Sensitive-data classes and output redaction:
- Cache, transcript, export, and retention constraints:
- Denial behavior that does not reveal protected metadata:

## 5. Answer Contract

| State | Required representation |
| --- | --- |
| Supported | Claim, evidence references, effective time, and material qualifications |
| Partial | Supported portion, missing evidence, and prohibited inference |
| Stale | Last valid evidence time and consequence of age |
| Conflicting | Competing claims, source authority, and unresolved decision |
| Unauthorized | Bounded refusal without protected source disclosure |
| Unavailable | Dependency or source failure and safe retry or escalation path |

- Required output fields:
- Required uncertainty or confidence language:
- Clarification, abstention, refusal, and human-handoff triggers:

## 6. Entry Decision

- Entry state: `admit`, `clarify`, `narrow`, `defer`, or `reject`
- Rationale and evidence:
- Accepted scope and exclusions:
- Owner, authority, and timestamp:
- Expiry and reopening triggers:

# Knowledge Answer Review Checklist

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

Complete `../../common-artifact-header.md` first. This checklist creates evidence-indexed findings. It does not approve an answer, grant source access, resolve source policy, or authorize the decision that may consume the answer.

## 1. Review Basis

| Field | Record |
| --- | --- |
| Knowledge Request Record version | |
| Context Assembly Plan and package identity | |
| Prompt and answer-contract version | |
| Corpus, index, source-policy, and access-policy identities | |
| Answer candidate and generation time | |
| Verifier and decision authority | |

## 2. Evidence Index

| Evidence ID | Source identity/version | Authority domain | Effective time/freshness | Permission scope | Claim supported | Limitation |
| --- | --- | --- | --- | --- | --- | --- |
| EV- | | | | | | |

## 3. Findings

| Check | Evidence ID | Result | Finding ID |
| --- | --- | --- | --- |
| Request purpose and permitted decision use remain unchanged | | Pass / fail / indeterminate / not applicable | |
| Each material claim has retrievable supporting evidence | | | |
| Citations point to the exact evidence actually used | | | |
| Source authority and effective time match the claim | | | |
| Permission applies to the source, derived passage, cache, and answer | | | |
| Coverage meets the recorded minimum or is labeled partial | | | |
| Material source conflicts are exposed rather than silently merged | | | |
| Unsupported inference, source absence, and uncertainty are explicit | | | |
| Answer wording does not broaden policy, authority, or guarantees | | | |
| Refusal and handoff behavior protects restricted metadata | | | |

## 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 or close a material finding.

## 5. Review Outcome

- Claims verified:
- Claims not verified:
- Completeness: `complete`, `partial`, `stale`, `conflicting`, `unauthorized`, or `unavailable`
- Reviewer recommendation: `permit named use`, `narrow use`, `correct`, `defer`, `reject`, or `no recommendation`
- Residual uncertainty:
- Decision authority, disposition, conditions, and expiry:

## 6. Reopening Triggers

Reopen when the request, candidate answer, context package, source version, source authority, access decision, index, ranking or compression behavior, citation target, freshness rule, conflict rule, population, or intended decision use changes.

# Knowledge Answer Receipt

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

Complete `../../common-artifact-header.md` first. Preserve this receipt after review and the named decision-use disposition. It records what the answer can support, not merely what the assistant returned.

## 1. Answer Identity

| Field | Actual result |
| --- | --- |
| Request and answer IDs | |
| Knowledge Request Record version | |
| Context package, corpus, index, and source-policy identities | |
| Prompt, model configuration, and harness identities | |
| Access-decision reference | |
| Requester, verifier, and decision authority | |
| Generated, reviewed, and expiry times | |

## 2. Claim and Evidence Ledger

| Claim ID | Claim | Evidence ID(s) | Effective time | Support state | Qualification or unsupported inference |
| --- | --- | --- | --- | --- | --- |
| CL- | | EV- | | Supported / partial / stale / conflicting / unsupported | |

## 3. Completeness and Conflict

- Overall completeness state:
- Required evidence not found:
- Sources unavailable or excluded:
- Material conflicts and authority assessment:
- Retrieval, ranking, compression, or citation limitations:
- Restricted details omitted from the answer:

## 4. Findings and Disposition

| Finding ID | Final state | Correction, condition, or accepted risk | Authority and evidence | Reopening trigger |
| --- | --- | --- | --- | --- |
| F- | | | | |

- Permitted decision use:
- Prohibited or unsupported use:
- Final disposition: `permitted`, `narrowed`, `corrected`, `deferred`, `rejected`, or `superseded`
- Decision rationale and authority:
- Conditions, expiry, and required revalidation:

## 5. Correction and Closure

- User-visible citations and qualification delivered:
- Correction, withdrawal, or notification path:
- Authoritative record location:
- Follow-up owner and due date:
- Supersedes / superseded by:
- Closure authority and timestamp:

# Runbook: Conflicting or Stale Knowledge Sources

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

Complete `../../../common-artifact-header.md` first. Use this runbook when authoritative or advisory sources disagree, a source exceeds its freshness rule, effective times do not align, or a correction invalidates an answer.

## Entry Conditions and Authority

- Request, answer, context package, source, corpus, and index identities:
- Conflicting claims or stale evidence and affected decision use:
- Knowledge owner, context owner, verifier, decision authority, and operations owner:
- Authority to withdraw answers, pause a source, rebuild an index, correct content, notify users, or accept residual uncertainty:

The assistant may surface conflict. It cannot declare a winning institutional policy or waive freshness requirements unless the recorded source policy grants that decision.

## Immediate Action

1. Mark affected claims `conflicting`, `stale`, or `unsupported`.
2. Stop unqualified reuse and identify dependent answers, caches, summaries, and decisions.
3. Preserve exact source versions, effective times, retrieval traces, context packages, and answer receipts.
4. Route source-authority decisions to the knowledge owner and decision-use decisions to the named authority.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Align | Compare claim scope, authority domain, effective time, audience, and version | Comparable source ledger | Sources govern different domains |
| Reconcile | Apply the recorded precedence rule without inventing one | Supported winner or explicit unresolved conflict | No valid precedence exists |
| Bound | Find affected claims, answers, users, and downstream decisions | Impact inventory | Material decisions used the answer |
| Correct | Update source, policy, index, answer, or qualification under owner authority | New versioned evidence | Correction would broaden policy |
| Notify | Withdraw or supersede affected answers and decisions | Delivery and acknowledgement record | Required audience cannot be reached |

## Verification and Stopping Conditions

Verify source authority, effective time, index propagation, cache invalidation, citation targets, corrected answer coverage, and dependent decision disposition.

Stop and escalate when the authoritative source remains disputed, a decision used unsupported claims, the affected population is unknown, or the system cannot prevent the stale answer from recurring.

## Reversal

- Restore the last valid source or index only when it remains authoritative for the required effective time.
- Disable or demote an invalid source through the controlled source policy.
- Withdraw, supersede, or qualify affected answers; do not overwrite their receipts.
- Reopen downstream decisions whose evidence is no longer valid.

## Evidence and Closure

Record source versions, conflict analysis, authority decision, impact inventory, corrective versions, propagation evidence, notifications, remaining uncertainty, and owners.

Close when source status is explicit, affected answers are corrected or withdrawn, dependent decisions are dispositioned, and recurrence controls are verified. Reopen on a late source correction, propagation failure, or repeated conflict.

# Runbook: Access Scope or Citation Failure

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

Complete `../../../common-artifact-header.md` first. Use this runbook when retrieval, a derived passage, cache, citation, transcript, or answer may exceed the requester's effective access or cannot be traced to the evidence actually used.

## Entry Conditions and Authority

- Requester principal, access decision, request, answer, and context-package identities:
- Suspect source, passage, cache, citation, output, or disclosure:
- Access-control owner, knowledge owner, security/privacy route, operations owner, and decision authority:
- Authority to block output, revoke access, invalidate caches, contain records, notify affected parties, or restore service:

## Immediate Action

1. Stop delivery and reuse of affected answers without deleting evidence.
2. Preserve access decisions, retrieval events, transformations, citations, caches, transcripts, and delivery records under protected handling.
3. Contain the affected principal, source class, cache, or route at the smallest enforceable boundary.
4. Invoke the authoritative security or privacy incident path when exposure is possible.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Reconstruct | Join principal, policy, source, passage, transformation, citation, and answer | End-to-end lineage | Any hop is missing |
| Classify | Determine unauthorized retrieval, derivation, caching, citation mismatch, or rendering leak | Failure class and scope | Protected metadata may have been disclosed |
| Bound | Identify affected users, sources, answers, exports, and downstream systems | Impact inventory | Population cannot be bounded |
| Correct | Repair policy enforcement, lineage, cache scope, or citation binding | Controlled candidate and tests | Fix relies on prompt compliance alone |
| Restore | Re-enable only verified scopes and answer paths | Access and citation verification | Residual exposure or lineage gap remains |

## Verification and Stopping Conditions

Verify denial behavior, source and field filters, derived-store and cache isolation, citation-to-passage identity, answer redaction, retained artifacts, and affected-user remediation.

Stop and escalate when access cannot be externally enforced, lineage cannot be reconstructed, restricted metadata appears in a refusal or citation, or required notification is unresolved.

## Reversal

- Revoke or narrow affected access and invalidate derived caches or exports under retention rules.
- Restore the last verified access policy, corpus, index, or renderer.
- Withdraw affected answers and reopen decisions that relied on them.
- Do not erase protected incident evidence or claim that cache deletion reverses disclosure.

## Evidence and Closure

Record the access decision, lineage, affected population, containment, policy or code change, verification results, notifications, residual consequence, and closure authority.

Close when unauthorized paths are blocked, citations are traceable, affected records and users are dispositioned, and recurrence tests pass. Reopen on a late export, cache replica, access-policy drift, or repeated citation mismatch.