Skip to content
Robbins Analytics.

Cascadia / In Practice

AI assists the analysis.
Evidence earns trust.

As an AI analytics architect, Aaron Robbins applies Cascadia to analytics work. AI can help frame questions, develop solutions and explain findings. Business rules, reproducible checks and a human decision determine what can be used.

  • Follow the workflow: see where AI assists and where people define, verify and decide.
  • Inspect three solutions: see how they make meaning testable, runs inspectable and missing work visible.

01

Where AI enters the work.

A person brings the need. Existing work is checked before a new build. AI can help develop a solution within permitted context; people decide what enters and leaves the work.

Illustrative operating route

Check before building.

“Can this report show three more columns?” First confirm the business question, then inspect what already exists.

  • Use what existsAn existing report answers the question.
  • Resolve accessThe answer exists, but the requester cannot reach it.
  • Scope the workModify a certified view or define a new build only where needed.

Human entry: the requester confirms the question and useful result. An existing answer can close the request without a new build.

One question, four accountable stages
  1. 01 / Frame

    Confirm the question.

    The requester agrees on the decision, audience and acceptance conditions.

    Human gate: The requester confirms the need before work enters.

  2. 02 / Ground

    Use permitted sources.

    Supply certified definitions, relevant rules and known source limits.

    Context gate: Check the boundaries of what the system can use.

  3. 03 / Propose

    Develop a solution.

    AI can draft queries, code, tests, charts, copy, visualizations, summaries and explanations for review.

    Verification gate: Reproduce the result and test expected cases.

  4. 04 / Verify

    Check, then decide.

    The delivery lead records applicable checks; the requester accepts, revises or rejects the result.

    Human exit: Keep the decision, evidence and limits with the delivered version.

Return for correction: a rejected candidate goes back to the relevant definition, source or test. The intended retrospective closes the request and informs later work; see how learning is retained.

How the five capabilities support it

  • Sovereign GroundPermitted context and source traceability.
  • Foundation ReadinessBusiness definitions and expected answers.
  • Solutions FoundryCandidate queries, code and tests.
  • Experience FrameworkFindings a reader can inspect.
  • Trust AssuranceChecks, review and retained limits.
Illustrative application · synthetic data

When would a license reduction change the bill?

A requester needs to know when a reduction changes the bill. The agreed effective-date rule makes it effective at the next term boundary.

AI candidate

Subtract the reduced licenses from today’s billable quantity.

Rule and check

  • Rule: the current quantity stays billable through this term.
  • Check: a known case and separate calculation expose the early reduction.

Reviewed result: reject the candidate, correct the calculation and retain the failed case as a test.

This shows how AI assistance could be used with the synthetic scenario. The published Revenue Assurance module below demonstrates rule-based calculations; it is not presented as an AI agent.

The examples below show business rules, independent checks and operating records. AI-assisted work needs all three.

02

Make business meaning testable.

Trust begins with the rule the number is supposed to represent.

Synthetic subscription book

Cascadia Revenue Assurance

A customer requests a subscription reduction midway through a term. The order register reflects it immediately, but the bill does not change until the next term.Which quantity should be billed today?

The problem

  • Effective dates differ. Adds, reductions and cancellations follow different schedules.
  • A plausible number can answer the wrong question. Current quantity is not always billable quantity.

The delivered approach

  • Rules become executable logic. Python and DuckDB SQL independently apply the written timing rules.
  • Reconcile the results. State shared-rule and shared-input risks.
Add licensesEffective immediately
Reduce licensesEffective at the next term boundary
CancelBillable through the existing term
One rule, two calculation paths
Written business rulesShared rules and inputs
PythonState-machine calculation
DuckDB SQLSeparately written calculation
ReconcileCompare published results

The two implementations can reveal a calculation mismatch; agreement increases confidence in the implementation but cannot prove the shared rules or inputs are right.

Cascadia capabilities at work

  • Foundation Readiness

    Written entitlement rules define when a license change becomes billable.

  • Solutions Foundry

    Python and DuckDB SQL provide separate rule calculations.

  • Trust Assurance

    Known cases and reconciliation test the outputs; shared risks stay stated.

Reusable lesson

Meaning before calculation. A second derivation can expose disagreement; agreement still needs a clear statement of shared rules and inputs.

What this example establishes

This is a portfolio demonstration using seeded synthetic data. The case study describes the two paths and their limitations. It is not a client revenue recovery result.

Read the case study ↗Open the module ↗

03

Plan for the next run.

Delivery includes what happens when data changes and a check fails.

Public federal court records

Cascadia Matter Ledger

A verified court-data model can be right at launch but drift as records arrive. Each later run must show what changed and what failed.How can the next run remain inspectable?

The problem

  • A valid snapshot is only a start. Later increments can drift.
  • Failures need a visible route. A silent run cannot support review.

The delivered approach

  • Freeze and verify the baseline; bound each scheduled increment.
  • Reassert, reconcile and publish check outcomes, including failures.
A stopped refresh should leave a visible trail

In a documented first run, the pipeline walked 36 court dockets, then hit a source rate limit. Its progress marker had moved, but no rows had been saved.

The correction: save each docket’s rows before moving the marker, and keep unfinished dockets available to resume.

Make each run inspectable
  1. Frozen baselineHash-verified source
  2. Bounded incrementScheduled run
  3. Reassert and reconcileReassert invariants; reconcile against baseline
  4. Publish outcomesInclude failures

Cascadia capabilities at work

  • Sovereign Ground

    Frozen, hash-verified court data anchors later increments.

  • Solutions Foundry

    The refresh saves rows before advancing its progress marker.

  • Trust Assurance

    Runs reassert invariants, reconcile results and report failures.

Reusable lesson

Operation is part of delivery. Preserve the baseline, define each run’s conditions and make failures inspectable.

What this example establishes

The example is based on FJC and CourtListener public records. The linked case study documents its operating pattern. Current scheduler uptime and future runs have not been independently audited for this About page.

Read the case study ↗Open the module ↗

04

Keep missing work visible.

Completeness depends on knowing what should exist, as well as what arrived.

Frozen synthetic demonstration

Cascadia Claim Integrity

A completed ride starts a chain of claim and reporting work. A missing downstream record can leave that work unfinished without an obvious failure.How can every expected step remain visible?

The problem

  • A ride record is not a claim. Construction needs supported facts.
  • Work continues after submission. Downstream obligations stay visible.

The delivered approach

  • Follow supported facts. Build the claim and check encounter readiness.
  • Keep expected work visible when a downstream record never arrives.
Track the work beyond the record
  1. Supported facts
  2. Claim construction
  3. Encounter readiness
  4. Outcome evidence

Expected work remains visible even when a downstream record never arrives.

One ride, three different next steps

Recorded synthetic example: a ride record exists, but the billing-party reference is missing. The claim later gains that reference; the recipient then rejects it without a reason code.

The result: obtain missing support, retain the corrected claim version, then request the rejection reason. The three steps need different follow-up.

Cascadia capabilities at work

  • Experience Framework

    The claim journey distinguishes missing support, a corrected version and a recipient rejection.

  • Trust Assurance

    Readiness and missing downstream obligations remain visible for review.

Reusable lesson

Missing work stays in view. Model expected obligations as well as received records so an absent item cannot disappear from review.

What this example establishes

The published module and case study provide the synthetic demonstration and its assurance scope. Its reviews and tests are bounded evidence, with stated limitations. They do not establish client deployment or universal compliance.

Read the case study ↗Open the module ↗

05

What carries into the next application?

Three solutions, one repeatable discipline: test business meaning, inspect each run, and keep missing work visible.

  1. Define the meaning.

    Agree on the business rule and a known case that would expose a wrong answer.

  2. Keep evidence with the decision.

    Retain sources, checks, accepted limits and the accountable reviewer.

  3. Carry forward what was learned.

    Assign operation and recovery; evaluate feedback before updating the method.

Portfolio evidence has a boundary. These public or synthetic demonstrations show inspectable practices and outputs. They do not establish customer outcomes, implementation savings or a company-wide deployment.

The solution standard

A solution is useful when someone can accept it, explain it and revisit it.

Start with a confirmed question. Check the answer against its rules and evidence. Keep the decision and what was learned.

Apply it to a company →See how it learns →
How It Learns →