Claim Integrity / Playbook

CASCADIA / CLAIM INTEGRITY

Can the evidence
support the decision?

A successful sync is not enough. This playbook shows how to assess incoming evidence, contain uncertainty, and establish a defensible path back to reliable decisions.

Fictional playbook. No operational data. Examples describe decisions and evidence to request; they do not represent executed checks or real incidents.

01TrustCan this evidence support this use? 02DiagnosisWhere did the evidence change? 03ContainmentWhat could depend on the gap? 04RecoveryWhat proves the repair is sound? 05ReleaseCan this change be accepted?
HOW TO USE

Start with the decision that is uncertain, then follow the relevant scenario and template. This guide explains a process; it does not operate a claims platform.

01 / EVIDENCE

Name what the evidence can support.

SUPPORTED

Current evidence meets the agreed requirements for the stated use and scope.

UNSUPPORTED

Available evidence demonstrates a breach of those requirements.

UNKNOWN

Required evidence is missing, inconclusive or no longer current.

RESTRICTED USE

A separately authorized, limited use with a named owner, caveat and expiry. Permission does not turn unknown evidence into supported evidence.

Freshness asks whether evidence is current enough. Completeness asks whether expected evidence is accounted for. Recent arrivals can hide an earlier gap; a genuinely quiet source can remain trustworthy when its lack of change is independently established. Thresholds belong to the organization's agreed contract, not this example. [R1] [R5]

02 / DECISION GUIDES

Five decisions.
One defensible path.

Open a guide for the evidence, decision rule, accountable owner and exit condition. Each guide points to a fictional walkthrough and a blank working template.

01TrustCan this evidence support this business use now?
Question
Can this evidence support this business use now?
Trigger
A readiness decision, reporting task or review needs evidence whose coverage or currency is uncertain.
Evidence to request
The dataset/use agreement; the health-plan or partition scope; a bounded source observation; arrival and coverage information; relevant missing or invalid facts; and the time that evidence was evaluated.
Decision rule
Call the evidence supported only within its demonstrated scope and lifetime. Treat a proven breach as unsupported and a missing observation as unknown. Do not infer completeness from a recent timestamp or connector status.
Action
Permit supported work; place targeted holds on unsupported or unknown dependencies. Record any restricted use separately with its caveat and expiry.
Accountable owner
Owner of the business use; engineering supplies the evaluation evidence.
Exit condition
A scoped decision is recorded with its evidence, owner and next review or expiry.

Read next: Scenario 1 and the Trust contract template. [R1] [R5]

02DiagnosisAt which boundary did evidence first become missing or altered?
Question
At which boundary did the evidence first become missing or altered?
Trigger
An unexpected missing fact or an unsupported/unknown input.
Evidence to request
A key-specific source observation, extraction manifest, staging acceptance/rejection details and downstream consumption evidence, all referring to a comparable source interval or version.
Decision rule
Locate the first demonstrated divergence. If the source never contained the fact, record a source/business gap. If an extract contained it but staging did not, inspect landing/rejection. If staging preserved it but the output did not, inspect downstream use. When a boundary cannot be observed, state that diagnosis remains indeterminate.
Action
Assign the next investigation to the relevant owner. Keep provisional containment in place while diagnosis continues. Matching counts cannot rule out a changed field value.
Accountable owner
Data-platform lead; the source owner confirms a specific source omission.
Exit condition
The inspected scope, known cause or bounded uncertainty, and next responsible owner are recorded.

Read next: Scenario 1 and the Incident decision record.

03ContainmentWhich decisions could depend on missing evidence?
Question
Which decisions could depend on the missing evidence, and what can safely continue?
Trigger
Trust breaks; root-cause confirmation is not required first.
Evidence to request
Dependency scope, prior decisions, claim/target uses, reporting obligations and deadlines, affected measures, and registered consumers. Include conclusions based on absence, such as “no authorization found”.
Decision rule
Separate potential exposure known during the incident from the smaller impact that may be confirmed after recovery. A claim can be exposed for one target while another use remains supportable. Already-submitted or published outcomes require later review even when future actions are held.
Action
Hold unsupported actions, continue independently supported work, notify affected consumers and register past actions at risk. Keep obligation clocks running; escalate deadline risk internally rather than claiming the deadline paused.
Accountable owner
Incident lead, supported by operations, reporting and metric owners.
Exit condition
Exposed decisions have a response, owner and deadline; unaffected uses have a recorded basis for continuation.

Read next: Scenario 1 and the Incident or Communication template. [R2]

04RecoveryWhat proves recovered evidence is incorporated correctly?
Question
What establishes that recovered evidence is incorporated correctly and consequences are addressed?
Trigger
Missing or corrected evidence becomes available, or a repair is proposed.
Evidence to request
Preserved prior state; bounded source-to-output comparison; versions and actual arrival/knowledge times; a replay/effect review; independent expected outcomes; and dispositions for decisions already acted on.
Decision rule
Accept only the scope that can be proven. Preserve what was known at earlier decision times. A correction can be effective in the past without pretending it arrived earlier. Agreement between an incremental repair and a full rebuild is a consistency check, not independent proof that both are correct.
Action
Retain legitimate versions, prevent duplicate effects, revisit prior actions, obtain domain sign-off, and release holds per supported conclusion. An uncertain acknowledgement requires reconciliation and a safe recipient contract, not a blind resend.
Accountable owner
Data-platform lead; operations and finance attest their respective consequences.
Exit condition
Proven scope and remaining uncertainty are explicit. Incident closure additionally requires past-action, consumer and obligation follow-up.

Read next: Scenario 2 and the Recovery review template. [R3]

05ReleaseIs there enough evidence to accept this pipeline change?
Question
Is there enough evidence to accept this specific pipeline change?
Trigger
A new or changed implementation, including AI-generated code, is proposed.
Evidence to request
Intended behavior; identified candidate/version; independent expected results; relevant regression and ordering checks; known limitations; reviewer; and rollback/observation plan.
Decision rule
Require explained differences and independently assessed behavior. Generated tests alone are insufficient. Keep the authoring side separate from independent approval. Software-security guidance is useful context but does not establish claim-data correctness.
Action
Accept, reject or return for clarification with reasons. Record the intended operating boundaries and a rollback path; do not infer release readiness from this fictional walkthrough.
Accountable owner
Engineering lead, with mandatory independent approval outside the authoring side.
Exit condition
A candidate-specific decision, evidence limits, owner and next action are recorded.

Read next: Scenario 3 and the Release decision template. [R4]

03 / FICTIONAL WALKTHROUGHS

Decisions under
uncertainty.

These narratives show how the guides connect. Every scenario is fictional; no claim records, checks, backfills or external actions are executed.

Fictional walkthrough
SCENARIO / 01

The connector is green;
authorization evidence is stale.

One fictional plan requires authorization support for an audit target. The encounter target has a different requirement. A connector reports success while authorization changes for that plan fail to arrive. Other inputs continue updating. This is an illustrative policy, not a statement about a real plan.

  1. Recognize the uncertainty. A source-side observation indicates changes inside a stated interval. Staging cannot account for them. The connector's green status does not settle supportability.
  2. Contain before diagnosing. Operations holds exposed audit decisions, including conclusions based on “no authorization found”. The independently supported encounter use continues. Reporting deadlines remain visible.
  3. Locate the gap. The team compares the same source interval through extraction and staging. The missing changes are already absent in the extract, so extraction is the first demonstrated break. A source record that never existed would require a different follow-up.
  4. Register prior consequences. An audit package already sent needs review; a readiness summary needs possible restatement; a prior escalation may need withdrawal. Record owners rather than silently replacing history.
  5. Review recovery. Request source-to-output reconciliation, version/arrival evidence, independent expected outcomes and duplicate-effect precautions. Do not declare recovery merely because a backfill finishes.
  6. Close deliberately. Operations revisits prior actions, reporting follows obligations, and the incident lead closes only after the remaining uncertainty and communications are dispositioned.
DECISION LESSON

Exposure is what could depend on the gap at detection time. Realized impact is what later evidence confirms changed. Hindsight cannot justify a smaller initial hold.

Evidence neededBounded source observation, extract/landing comparison, exposed-decision register, preserved prior state and recovery review.

LimitNo record set, reconciliation or backfill was executed in this example.

Related: Trust, Diagnosis, Containment, Recovery; Incident decision record.

SCENARIO / 02

The acknowledgement
is missing.

A recovery redelivers a legitimate correction. Separately, an action may have reached its recipient, but the sender did not retain acknowledgement. These are different identity problems.

  1. Keep the correction's entity and immutable version separate from its delivery attempt. Repeated delivery of the same version is different from a valid new correction.
  2. Preserve the correction's actual arrival time and earlier business-effective date. Keep the original decision view available.
  3. For the uncertain action, identify the original action and inspect the recipient's acceptance evidence under its documented idempotency contract.
  4. If acceptance is confirmed, record that result rather than sending a duplicate. If the probe is unavailable or ambiguous, keep the action unresolved. A lookup by itself cannot remove race conditions or guarantee safe retries.
  5. Operations or finance reviews the proposed disposition. A recorded replacement decision is separate from authorization to execute it.
DECISION LESSON

Correct final tables do not prove that an external action happened only once.

Evidence neededVersion chain, knowledge times, stable action identity, recipient contract and acceptance evidence, and authorized disposition.

LimitThis narrative describes a review; it does not send, reconcile or simulate a payment or submission. [R3]

Related: Recovery; Recovery review and Communication templates.

SCENARIO / 03

The faster
AI-assisted change.

An AI-assisted rewrite proposes choosing whichever conflicting revision arrives last. Its own tests pass. The intended business rule instead requires incompatible parallel versions to remain an explicit conflict.

  1. State the required conflict behavior before reviewing the candidate.
  2. Ask for an independently specified conflicting-version example, input-order variations and comparison with intended outputs.
  3. Reject the proposed behavior when it silently chooses a winner. A second check should confirm that connector success cannot suppress the missing-evidence warning.
  4. A corrected proposal would retain conflicts and preserve existing checks. Acceptance still requires candidate-specific evidence and independent approval.
  5. Record limitations and a rollback plan. Do not represent the fictional corrected proposal as a tested release.
DECISION LESSON

Faster implementation and self-authored tests do not replace a behavior specification and independent review.

Evidence neededChange specification, candidate identifier, independent expectations, check results, reviewer and rollback plan.

LimitNo candidate code, benchmark or test execution is supplied by this playbook.

Related: Release; Release decision template.

04 / WORKING TEMPLATES

Blank by design.
Ready to reuse.

These templates are prompts for a real team's records. They are intentionally blank and do not submit or store information here.

T / 01Trust contract
  • Dataset and business use: [complete]
  • Plan/partition and source interval: [complete]
  • Evidence required and independent source: [complete]
  • Currency/completeness criteria and expiry: [complete]
  • Supported/unsupported/unknown decision and basis: [complete]
  • Restricted-use authorization, caveat and expiry, if any: [complete]
  • Accountable owner and next review: [complete]
T / 02Incident decision record
  • Incident reference and detection time: [complete]
  • Observation boundary and current uncertainty: [complete]
  • Exposed decisions, including absence-based conclusions: [complete]
  • Supported work continuing and justification: [complete]
  • Prior actions at risk and proposed dispositions: [complete]
  • Holds, owners and unchanged deadlines: [complete]
  • Diagnosis, evidence gaps and next action: [complete]
  • Communication owner and next update: [complete]
T / 03Recovery review
  • Recovery scope and retained prior state: [complete]
  • Source versions, payload comparison and unresolved scope: [complete]
  • Effective times versus actual knowledge times: [complete]
  • Independent expected results and rebuild consistency: [complete]
  • Duplicate-effect and uncertain-acknowledgement review: [complete]
  • Past-action dispositions and domain sign-off: [complete]
  • Hold releases, remaining obligations and closure decision: [complete]
T / 04Release decision
  • Candidate/version and intended behavior: [complete]
  • Independent expectations and relevant checks: [complete]
  • Explained differences and unresolved limitations: [complete]
  • Authoring side and independent approver: [complete]
  • Observation/rollback plan: [complete]
  • Accept/reject/clarify decision and reason: [complete]
  • Accountable engineering owner and next action: [complete]
T / 05Communication note
  • Audience and incident reference: [complete]
  • What is known, uncertain and affected: [complete]
  • What continues and what is held: [complete]
  • Deadlines and required recipient action: [complete]
  • Owner and next update: [complete]
  • Recovery/disposition status without overstating proof: [complete]
TAKE THE GUIDE WITH YOU

Complete playbook, scenarios, templates and source notes.

Download playbook (.md)

All scenario narratives are shown. Interactive scenario selection and print controls are available when JavaScript is enabled.

05 / SOURCES & LIMITS

Grounded in practice.
Limited in claim.

Research reviewed October 21, 2026. Sources inform general engineering practice. The Claim Integrity-specific decisions and fictional policies are original adaptations, not verified production facts or regulatory requirements.

  1. R1
    Google SRE, Monitoring Distributed SystemsGeneral guidance on monitoring and signals
  2. R2
    Google SRE Workbook, Incident ResponseGeneral incident response practice
  3. R3
  4. R4
    NIST SP 800-218, SSDF 1.1Secure software development guidance
  5. R5
    dbt documentation, Source freshnessSource freshness concepts

General guidance only. Actual contracts, deadlines and authority must be set by the organization. This site contains no operational data, computes no claim outcome and makes no production or compliance assurance claim.