Robbins Analytics.

CASCADIA CLAIM INTEGRITY / EVIDENCE DECISIONS

Claim Integrity grew.
Can its evidence keep up?

More health plans, contract rules and reporting obligations now depend on a growing set of upstream sources. A successful sync cannot establish whether the evidence supports the next claim decision.

  • Before a decision: Confirm the evidence supports the intended use.
  • After a gap: Contain exposure, verify recovery and record approval.

The platform expanded.
The handoff became the weak point.

Downstream transformations are established and certified. The uncertainty starts earlier: getting source evidence into staging.

  1. 01 / FALSE CONFIDENCE

    Green sync. Stale tables.

    Connectors can report success while required source changes remain missing for days.

  2. 02 / UNCLEAR CAUSE

    Missing fact—or missing handoff?

    The team cannot readily separate a source gap from an extraction delay or ingestion loss.

  3. 03 / CHANGE PRESSURE

    A redesign still needs proof.

    AI-assisted pipeline changes need defensible evidence. Engineering remains accountable for production behavior.

THE PROBLEM TO SOLVE

How can Claim Integrity determine which decisions its incoming evidence supports—and prove that recovery or a pipeline change restores reliable results?

The business case for this playbook

  • Protect claim decisionsMake readiness depend on evidence, not just a green run.
  • Manage reporting exposureIdentify holds, owners and obligations while gaps are resolved.
  • Restore confidence deliberatelyRequire recovery evidence and independent release approval.
THE PLAYBOOK RESPONSE

Five decisions turn the evidence gap into owned actions.

01

Trust

Know what can be used.
02

Diagnosis

Find the first break.
03

Containment

Limit the consequence.
04

Recovery

Prove the repair holds.
05

Release

Approve with evidence.

01 / EVIDENCE STATES

Match the evidence.
Then choose the action.

A state describes what is known. An exception describes what is permitted.

The same labeled colors mark evidence states here and in the decision paths below: green supports use, amber signals a failed requirement, blue asks for more evidence, and violet marks an approved exception.

Supported

The agreed evidence is current and sufficient.

Unsupported

Evidence shows a requirement is not met.

Unknown

Evidence is missing, expired or inconclusive.

Restricted use

A scoped, approved exception. It does not change the evidence.

FreshnessCurrent enough for this use?
CompletenessEverything expected accounted for?

Recent does not mean complete.
A quiet source needs evidence too. [R1] [R5]

02 / THE DECISION PATHS

See the next
defensible step.

Follow the flow. Check the evidence. Know who owns the decision.

01 / TRUST

Can this evidence support this use?

  1. 01

    Define the use

    Name the plan, purpose and time window.

  2. 02

    Check the evidence

    Compare freshness, coverage and required facts.

  3. 03

    Choose the boundary

    State what is supported, missing or unknown.

SupportedContinue within scopeThe agreed evidence supports this use. Keep the next review explicit.

UnsupportedHold dependent actionsA required check failed. Record the failed criterion and what must change.

UnknownResolve the evidence gapEvidence is missing, expired or inconclusive. Keep dependent actions on hold.

Restricted useAuthorize a narrow exceptionName the approver, permitted use and expiry. The exception does not change the evidence state.

ACCOUNTABLEBusiness-use owner

DONE WHENA scoped decision, evidence and next review are recorded.

Evidence to request
  • An agreed dataset/use contract and scope.
  • A bounded source observation, not just a sync status.
  • Arrival, coverage and validity checks with an expiry.

See this in a scenario ↗Use the template ↗

02 / DIAGNOSIS

Where did the evidence go missing?

  1. 01

    Trace one fact

    Start with a source observation for the same key or version.

  2. 02

    Compare each handoff

    Source → extract → staging → downstream use.

  3. 03

    Locate the first gap

    Name the earliest proven absence or alteration.

Unsupported handoffBreak locatedEvidence shows this handoff failed its requirement. Assign the relevant owner and next investigation.

Unknown boundaryKeep diagnosis indeterminateThe boundary is unobservable. Retain containment while the evidence gap is investigated.

ACCOUNTABLEData-platform lead

DONE WHENThe cause or bounded uncertainty has an owner and next action.

Evidence to request
  • A key-specific source observation.
  • Extract and landing receipts for the same interval.
  • Rejected, altered or unconsumed facts and their reasons.

See this in a scenario ↗Use the template ↗

03 / CONTAINMENT

What depends on the gap?

  1. 01

    Map potential exposure

    Include decisions based on absent records.

  2. 02

    Separate the actions

    Distinguish future work from outcomes already sent.

  3. 03

    Protect what matters

    Hold exposed actions; keep independent work moving.

Unknown dependencyTreat potential exposure as exposedIf the gap could affect a conclusion, hold, revisit or restate with a named owner until its basis is established.

Supported useContinue independently supported workContinue only with an explicit evidence basis for that use.

ACCOUNTABLEIncident lead

DONE WHENEvery exposed conclusion has a response, owner and deadline.

Evidence to request
  • Dependency scope, targets, measures and consumers.
  • Past submissions, publications and escalations at risk.
  • Obligations and deadlines, which never pause.

See this in a scenario ↗Use the template ↗

04 / RECOVERY

What establishes reliable results again?

  1. 01

    Preserve the past

    Retain prior state and actual knowledge times.

  2. 02

    Check the repair

    Compare recovered facts and independent expectations.

  3. 03

    Revisit the effects

    Reconcile retries, prior actions and remaining holds.

Supported scopeRelease only the proven scopeObtain sign-off and release holds within the reconciled boundary.

Unknown scopeKeep the unresolved scope unrecoveredMissing or inconclusive recovery evidence prevents full closure.

ACCOUNTABLEData-platform lead

DONE WHENProven scope and past-action dispositions are explicit.

Evidence to request
  • Bounded source-to-output reconciliation and version history.
  • Independent expectations; rebuild agreement is a consistency check.
  • Stable action identity, recipient contract and domain sign-off.

See this in a scenario ↗Use the template ↗

05 / RELEASE

Should this specific change proceed?

  1. 01

    State the behavior

    Describe intended differences before judging the code.

  2. 02

    Challenge the candidate

    Use independent expectations and relevant regressions.

  3. 03

    Record the decision

    Explain acceptance, rejection or remaining uncertainty.

Supported candidateAuthorize with independent approvalEngineering authorizes only when candidate-specific evidence is sufficient.

Unsupported candidateReturn a failed requirementA demonstrated behavior fails an agreed criterion. Correct it and keep a rollback path.

Unknown resultRequest the missing checkAn untested or inconclusive requirement remains unresolved; it is not evidence of a pass.

ACCOUNTABLEEngineering lead + independent approver

DONE WHENA candidate-specific decision and next action are recorded.

Evidence to request
  • An identified candidate and change specification.
  • Independent expected results and ordering/check-retention evidence.
  • Reviewer, limitations and observation/rollback plan.

See this in a scenario ↗Use the template ↗

03 / DECISIONS UNDER UNCERTAINTY

A situation.
A path forward.

Walk through the consequence, not just the technical symptom.

CHOOSE A WALKTHROUGH
SCENARIO / 01

A green connector. A missing handoff.

SITUATION

Authorization changes stop arriving for one plan’s audit target.

RISK

“No authorization found” may be an evidence gap, not a source fact.

FIRST MOVE

Contain the exposed audit decisions. Keep supported encounter work moving.

Follow the stages. Stacked arrows mean sequence; side-by-side lanes can run in parallel. Complete each stage before continuing.

  1. 01

    Establish the boundary

    Then continue

    1. STEP 01

      Notice the mismatch

      A bounded source observation shows changes the staging layer cannot account for.

    2. STEP 02

      Contain before diagnosis

      Hold exposed audit decisions, including absence-based conclusions. Reporting deadlines keep running.

  2. 02

    Investigate + review

    Parallel lanes · complete both

    1. STEP 03

      Find the first gap

      The changes are already missing from the extract. Extraction is the first demonstrated break.

    2. STEP 04

      Register past consequences

      Review the audit package already sent, the readiness summary and any prior escalation. Assign owners.

  3. 03

    Recover + close

    Then continue

    1. STEP 05

      Review the recovery

      Request reconciliation, actual arrival times, independent expectations and duplicate-effect precautions.

    2. STEP 06

      Close deliberately

      Revisit prior actions and obligations; close only after uncertainty and communication are dispositioned.

Continue with Trust ↗Diagnosis ↗Containment ↗Recovery ↗Working template ↗

SCENARIO / 02

The action may have landed. The acknowledgement did not.

SITUATION

Recovery redelivers a correction while a separate action lacks acknowledgement.

RISK

A correct final record does not prove an external action happened once.

FIRST MOVE

Separate version identity, delivery attempts and the external action.

Follow the stages. Stacked arrows mean sequence; side-by-side lanes can run in parallel. Complete each stage before continuing.

  1. 01

    Preserve the facts

    Parallel lanes · complete both

    1. STEP 01

      Keep the right identity

      The same version arriving again is a duplicate delivery. A valid new correction must be retained.

    2. STEP 02

      Preserve knowledge time

      Keep the correction’s actual arrival time and its earlier business-effective date.

  2. 02

    Check before repeating

    Then continue

    1. STEP 03

      Check the recipient contract

      Reconcile the original action’s identity and the recipient’s acceptance evidence.

    2. STEP 04

      Avoid the blind retry

      If accepted, record that fact. If lookup is ambiguous or unavailable, keep the outcome unresolved. A lookup alone cannot remove races.

  3. 03

    Authorize the outcome

    Complete this step

    1. STEP 05

      Authorize the disposition

      Operations or finance reviews the result. A replacement decision is separate from permission to send it.

Continue with Recovery ↗Containment ↗Working template ↗

SCENARIO / 03

A faster rewrite. A weaker decision rule.

SITUATION

An AI-assisted rewrite selects whichever conflicting revision arrives last.

RISK

Its own tests pass, but the contract requires incompatible revisions to remain a conflict.

FIRST MOVE

Write the expected behavior before reviewing the candidate.

Follow the stages. Stacked arrows mean sequence; side-by-side lanes can run in parallel. Complete each stage before continuing.

  1. 01

    Define the result

    Complete this step

    1. STEP 01

      Name the required result

      Incompatible parallel versions remain an explicit conflict, not an arbitrary winner.

  2. 02

    Challenge the rule

    Then continue

    1. STEP 02

      Challenge independently

      Request a conflicting-version example, input-order variations and comparison with expected results.

    2. STEP 03

      Reject the weaker rule

      Silent winner selection fails the stated behavior. Also confirm a green connector cannot suppress missing-evidence detection.

  3. 03

    Review + retain the boundary

    Then continue

    1. STEP 04

      Review the correction

      A revised proposal must preserve conflict handling and existing checks, with independent approval.

    2. STEP 05

      Keep the boundary visible

      Record limitations and rollback. This walkthrough is not an executed release or benchmark.

Continue with Release ↗Trust ↗Working template ↗

04 / THE WORKING KIT

Start with a question.
Leave with a record.

Each line explains what to consider, with a concrete example to get started.

Examples are starting points, not required policies. These worksheets do not collect or store information.

TEMPLATE 01 · 7 PROMPTSTrust contract

Swipe across the table to compare questions and examples.

Trust contract — questions and starting examples
FieldConsiderExample
01Dataset + useWhich decision needs this evidence?Authorization references · audit readiness
02Scope + intervalWhich plan, partition and source window are covered?Audit use for one plan; agreed change window
03EvidenceWhat independent observation could challenge the sync status?
Why it matters

A successful sync reports transport activity. Independent evidence is needed to establish whether the intended source changes arrived.

Source observation plus accepted/rejected changes
04Criteria + expiryWhat makes evidence current and complete enough?
Why it matters

Agree the threshold and expiry before reviewing the result. Otherwise a convenient observation can quietly become the acceptance rule.

Coverage reconciled; refresh before the next decision
05Decision + basisWhat is supported, unsupported or still unknown?Unknown: source coverage has not been established
06Restricted useWho can authorize an exception, for what use and until when?Internal exploration only; no external submission
07Owner + reviewWho is accountable and when is the next check?Business-use owner; review before hold release
TEMPLATE 02 · 8 PROMPTSIncident decision record

Swipe across the table to compare questions and examples.

Incident decision record — questions and starting examples
FieldConsiderExample
01Reference + detectionWhat identifies the incident and when did uncertainty begin?Authorization handoff gap; detected during readiness review
02Boundary + uncertaintyWhat interval was inspected and what remains unproven?Source changes observed; extraction coverage unresolved
03Potential exposureWhich conclusions rely on this scope being complete?
Why it matters

Start with everything that could depend on the gap, including decisions based on absence. Narrow the boundary only when evidence supports doing so.

Audit readiness, including “no authorization” outcomes
04Work continuingWhat remains independently supportable, and why?Encounter use continues under its own requirements
05Prior actionsWhat has already been sent, published or escalated?Review an earlier audit package and readiness summary
06Holds + deadlinesWho owns each action and which due times still apply?
Why it matters

A hold stops an exposed action; it does not pause an external obligation. Record the deadline owner and escalation while the hold is active.

Operations owns the hold; reporting retains the deadline
07Diagnosis + next stepWhat is the first proven divergence or missing observation?Inspect the extract against the same source interval
08CommunicationWho needs an update, from whom, and at what checkpoint?Incident lead updates affected consumers after diagnosis
TEMPLATE 03 · 7 PROMPTSRecovery review

Swipe across the table to compare questions and examples.

Recovery review — questions and starting examples
FieldConsiderExample
01Scope + prior stateWhat is being recovered, and what historical view was retained?Affected authorization interval; preserve prior readiness
02Versions + comparisonWhich source versions match, differ or remain unresolved?Account for source changes and rejected versions
03Effective + knowledge timeWas an old fact learned late rather than known earlier?
Why it matters

Keep when a fact was effective separate from when it actually became known. A backfill must not make past decisions appear better informed than they were.

Keep the historical effective date and actual arrival
04Expected resultsWhat independent expectation challenges the repair?Compare agreed outcomes; rebuild equality is supplementary
05Duplicate effectsCould a retry repeat an action already accepted?
Why it matters

Repeating a request can repeat its effect. Check the recipient’s identity and acceptance rules before treating a retry as safe.

Reconcile stable action ID under the recipient contract
06Past actions + sign-offWhat must be confirmed, replaced, restated or withdrawn?Operations reviews the prior package; finance attests effects
07Release + closureWhich holds can end, and what prevents full closure?Release proven scope only; retain unresolved obligations
TEMPLATE 04 · 7 PROMPTSRelease decision

Swipe across the table to compare questions and examples.

Release decision — questions and starting examples
FieldConsiderExample
01Candidate + intentWhich version changes which behavior?Staging rewrite; preserve explicit conflict handling
02Independent checksWhat results would reveal the candidate is wrong?
Why it matters

Define the expected behavior separately from the candidate implementation. Otherwise a check may simply repeat the same mistaken assumption.

Conflicting revisions, order variations and detection retention
03Differences + limitsAre all changes intended and every gap visible?Explain each changed result; disclose untested behavior
04Author + approverIs the approver outside the authoring and integration side?
Why it matters

Name an independent approver so implementation confidence is challenged before permission to release is granted.

Engineering owns release; an independent reviewer approves
05Observe + roll backHow will an unexpected result be noticed and reversed?Named observation points and a retained baseline
06Decision + reasonAccept, reject or clarify: what evidence supports the choice?Reject: input order changes the selected revision
07Owner + next actionWho is accountable for the decision and follow-up?Engineering lead requests a corrected candidate
TEMPLATE 05 · 6 PROMPTSCommunication note

Swipe across the table to compare questions and examples.

Communication note — questions and starting examples
FieldConsiderExample
01Audience + referenceWho needs this message and which incident does it concern?Operations, reporting and affected metric consumers
02Known + uncertainWhat is established, missing and potentially affected?
Why it matters

Give uncertainty its own explicit statement. Silence can otherwise be mistaken for confirmation that a result is safe to use.

Source changes exist; audit readiness is not yet supported
03Continue + holdWhat can proceed and what must wait?Supported encounter work continues; exposed audit use held
04Deadlines + actionWhich clock still runs, and what should the recipient do?
Why it matters

Pair every deadline with a concrete action and accountable owner. An update without an action can leave the obligation unattended.

Reporting keeps the due time; avoid unsupported resubmission
05Owner + next updateWho will communicate again and after which event?Incident lead updates after the source/extract comparison
06Recovery statusDoes the wording distinguish proven scope from uncertainty?One scope reconciled; remaining scope stays under review
Take the working kit with you.All five guides, three scenarios and guided templates.
Download playbook

All scenarios are shown. Enable JavaScript for scenario selection and the print button.

05 / SOURCES & PERSPECTIVE

Grounded in practice.
Clear about its limits.

Primary referencesEngineering guidance, not a certification.

Applied to this problemClaim-specific decisions are adaptations.

Reviewed October 21, 2026Actual policies and authority belong to your team.

  1. R1
  2. R2
    Google SRE WorkbookIncident response ↗
  3. R3
    Amazon Builders’ LibrarySafe retries and idempotent APIs ↗
  4. R4
  5. R5
    dbt documentationSource freshness ↗
  • No operational data or claim outcomes are computed.
  • No production or compliance assurance is claimed.
  • Use local contracts, deadlines and accountable owners.