Cascadia Portfolio · Build by Build

Build by Build

Nine Cascadia modules, built one after another over four months, and the tests each one could carry when it shipped. Every filled cell links to the file on GitHub that it names. An empty cell says the build did not carry that surface, and nothing is owed on it.

The test-surface matrix

Two ways to check a number at build one. Fourteen had appeared by build nine.

Nine portfolio modules (independent projects, not client work) by fourteen test surfaces, read from disk on 2026-09-16. Rows in first-commit order, grouped by era. A square marks a surface the build carries and links to the file; a diamond marks the first build to carry it, so there are fourteen diamonds in the table, one per surface. Count them to check the title.

The table is wider than this screen and scrolls sideways. All fourteen columns are there.

A table of 9 builds, one per row, oldest at the top, by 14 test surfaces, one per column, in four bands: Data, Numbers, Presentation, Operation. A square marks a surface the build carries; a diamond marks the first build to carry it; an empty cell means the build does not carry it. Surfaces carried per build: 2 at build 1, 2 at build 2, 3 at build 3, 6 at build 4, 6 at build 5, 10 at build 6, 9 at build 7, 8 at build 8, 10 at build 9. First appearances: 2 at build 1, 1 at build 3, 5 at build 4, 3 at build 6, 2 at build 7, 1 at build 9. Surfaces seen so far, build by build: 2 by build 1, 2 by build 2, 3 by build 3, 8 by build 4, 8 by build 5, 11 by build 6, 13 by build 7, 13 by build 8, 14 by build 9. Rows between the builds mark the design standard's versions by date: 7 dated versions from v2.2 on 2026-08-05 to v2.8 on 2026-08-29; v1.0, v2.0, v2.1 are undated. The marks thicken down the table, and the diamonds step to the right as the rows descend: the first two columns fill from the top, the middle columns from the fourth row, and the last two columns from the seventh.

EraBuildDataNumbersPresentationOperation
1One-com­mand re­build2Frozen source3Source regis­ter4Row-count valid­ation5Valid­ation report6Tests as code7Inde­pen­dent re-deri­va­tion8Golden fixture9Nega­tive controls10Chart review11Reading panel12Metric regis­ter13Sched­uled run with health14Recon­cili­ation pub­lished
Design standard VIZ-PRINCIPLES v1.0, v2.0 and v2.1: undated, before the standard had a repository.
Enterprise-shaped
Enter­prise-shapedCascadia Medical DevicesSQL Server, Fabric, Power BI · Jun 2026
Cascadia PharmacySQL Server, Power BI · Jun 2026
Cascadia StaffingSQL Server, Power BI · Jul 2026
Frozen and validated
Frozen and vali­datedCascadia FinancePython, SQLite, ECharts, SEC XBRL · Jul 2026
Build four, the first Python build: five surfaces appear at once.
Reviewed and registered
Re­viewed and regis­teredCascadia Deal DeskPython, SQLite, ECharts · Aug 2026
Design standard VIZ-PRINCIPLES v2.2 2026-08-05
Cascadia Control TowerPython, DuckDB, dbt, ECharts · Aug 2026
Design standard VIZ-PRINCIPLES v2.3 2026-08-10 v2.4 2026-08-10 v2.5 2026-08-10 v2.6 2026-08-24 v2.7 2026-08-25
Operated
Oper­atedCascadia Matter LedgerPython, DuckDB, ECharts, scheduled pull · Aug 2026
Design standard VIZ-PRINCIPLES v2.8 2026-08-29
Cascadia Fee ExaminerPython, CSV/JSON, ECharts · Sep 2026
Re-derived
Re-derivedCascadia Revenue AssurancePython, CSV, ECharts, DuckDB gate · Sep 2026
Build nine: the golden fixture (column eight) is the last of fourteen to appear.

D Data: 1 One-com­mand re­build 2 Frozen source 3 Source regis­ter
N Numbers: 4 Row-count valid­ation 5 Valid­ation report 6 Tests as code 7 Inde­pen­dent re-deri­va­tion 8 Golden fixture 9 Nega­tive controls
P Presentation: 10 Chart review 11 Reading panel 12 Metric regis­ter
O Operation: 13 Sched­uled run with health 14 Recon­cili­ation pub­lished the build carries the surface; the cell links to the file   the first build to carry it   a design-standard version, placed by date

Source: nine Cascadia module repositories on GitHub, and cascadia-standards · read 2026-09-16, frozen at d967ff5, standard v2.8 at 0c9d487 · cells link to files; empty cells are facts, not debts; three standard versions undated

Five eras

Enterprise-shaped

Cascadia Medical Devices, Cascadia Pharmacy, Cascadia Staffing

What could be tested
A one-command rebuild and a row-count check against stated expectations, in all three: Cascadia Medical Devices, Cascadia Pharmacy and Cascadia Staffing. Staffing added a second path: the KPIs the Power BI report shows, re-derived in SQL against the model.
What had to be trusted
The source itself, since nothing was frozen or registered; every chart, since none was reviewed or read blind; and every published figure that was not one of Staffing's re-derived KPIs.
What the next era brought under test
A frozen source with a stated as-of date, a validation report committed beside the data, a chart review against a written standard, a reading panel, and a proof that the checks can fail.

Frozen and validated

Cascadia Finance

What could be tested
Cascadia Finance froze its SEC filings under a dated freeze, reconciled quarters to filed years and committed the report, fed every check corrupted data and published that all of them rejected it, and had its charts reviewed and read by a panel. The era's name understates it: the negative controls and the reading panel arrived here, not later.
What had to be trusted
The row counts of the load, which no check compares against the source; the hashes of the raw files, which no register carries; the measure definitions, which no register states; and the published measures, which no second path re-derives.
What the next era brought under test
Tests as code, a metric register generated from the model that computes the numbers, a source register with a hash per file, and a row-count check against the source.

Reviewed and registered

Cascadia Deal Desk, Cascadia Control Tower

What could be tested
Cascadia Deal Desk kept everything Finance could test except the proof of failability, and added a count of conformed rows against raw. Cascadia Control Tower added dbt tests, a metric register generated from the model file and checked for drift on every build, a source register with a hash per file, and a published proof that its realism audits and structural checks trip on wrong numbers.
What had to be trusted
That the numbers stay right after the build ends, since nothing runs on a schedule and no reconciliation is published; and the published measures themselves, since neither module re-derives them down a second path.
What the next era brought under test
A scheduled run that publishes its own health and run history, a reconciliation committed with its failures, and every published cell re-derived down a separately written path.

Operated

Cascadia Matter Ledger, Cascadia Fee Examiner

What could be tested
Cascadia Matter Ledger and Cascadia Fee Examiner run a pipeline that re-asserts its invariants on a schedule and publish its health, its run history and a reconciliation that records the runs that stopped or failed. Both re-derive every published cell down a separately written path and carry a source register with hashes. Matter Ledger's one test file tests the page's touch readout in a browser.
What had to be trusted
The build order, which neither states; the load's row counts, which neither compares to the source; the checks' own failability, which neither proves in a committed report; and the engine's first output, since no golden fixture existed before the code.
What the next era brought under test
A golden fixture specified by hand and committed failing before any engine existed, and a second derivation path written from the rules document rather than from the first path's code.

Re-derived

Cascadia Revenue Assurance

What could be tested
Cascadia Revenue Assurance derives every published cell down two paths written from one rules document and compares them cell by cell; a hand-specified golden fixture, committed failing before either engine, passes on both. It keeps the freeze, the metric register, the chart review, the panel and the reconciliation, and adds tests as code.
What had to be trusted
The source register, since a synthetic snapshot carries no hashes; the validation report and the proof of failability, since its gates print their result and do not commit it; and operation over time, since nothing runs on a schedule.
What the next era brought under test
Nothing is under test for a tenth build yet. No row exists for it, and no retrospective has been written for this one.

The walk

The first three builds were shaped like enterprise work: a SQL Server star schema, a Power BI report, and one script that rebuilt the whole thing and printed a row-count table at the end. What could be checked was the load. What was published was trusted. Cascadia Staffing put one crack in that: the KPIs the report showed were re-derived in SQL and compared.

Cascadia Finance moved the work to Python and a static page, and with it came what a static page makes possible: a frozen source with a date on it, a validation report committed beside the data, a proof that the checks reject corrupted input, a chart review against a written standard, and a panel of readers who did not know the finding. five surfaces appeared in one build.

Cascadia Deal Desk and Cascadia Control Tower kept those and registered what they published: a metric register generated from the model, tests in the warehouse layer, and a source register with a hash per file.

Cascadia Matter Ledger and Cascadia Fee Examiner ran on a schedule and published what running looks like: health, history, a reconciliation that records its own failures, and every published cell re-derived a second way.

Cascadia Revenue Assurance wrote the rules first, the golden fixture second and two engines third, and published nothing until all of them agreed.

Nine modules, oldest first.

  1. Cascadia Medical DevicesA simulated MES and NASA engine-degradation data in SQL Server, Fabric and Power BI: OEE and predictive maintenance, rebuilt by one script with a row-count table at the end.
  2. Cascadia PharmacyCMS Part D and CDC VaxView in SQL Server and Power BI: messy public data cleaned into a star schema, with row counts validated on load.
  3. Cascadia StaffingCMS nurse-staffing data in SQL Server and Power BI: marketplace labor KPIs, each re-derived in SQL against the model.
  4. Cascadia FinanceFormFactor's SEC filings, frozen and reconciled quarter to year, with a proof that every check rejects corrupted data and charts a panel read blind.
  5. Cascadia Deal DeskA seeded quote book matched against an agreement register: pricing exceptions priced in dollars, validated, reviewed and panelled.
  6. Cascadia Control TowerA seeded fulfillment network anchored to public data: dbt tests, a generated metric register, and realism audits proven to fail.
  7. Cascadia Matter LedgerFederal civil dockets, frozen and then extended by a scheduled pull that publishes its health, its history and its reconciliation.
  8. Cascadia Fee ExaminerBankruptcy fee applications resolved across sources with no shared key: a source register with hashes and every cell re-derived a second way.
  9. Cascadia Revenue AssuranceA synthetic subscription book: two derivation paths from one rules document, a golden fixture written first, and invoices reconciled to the month.

From here the walk is a conversation. Pick a module; its row is where it starts.

About this page

An independent portfolio project by Aaron Robbins. This page is generated from two data files, data/builds.json and data/standard.json, in the repository linked below; the inventory script that writes them reads the nine module repositories and never writes in one. No score, level, weight or percentage exists in the data. A cell is a path or it is empty. Older modules are not retrofitted; an empty cell is a fact about what a build carried, never a debt.

Source, the inventory script, the surface definitions and the two data files: github.com/RobbinsAnalytics/cascadia-build-by-build. How a cell is filled or left empty is a written rule per column, in governance/surfaces.md. Inventory read 2026-09-16; data frozen at commit d967ff5.