Skip to main content

Case study

Case study in progress

Held closed by a scope gate. This is not a page nobody has written yet. It is a page that is not permitted to exist yet, and the difference is the point.

  • Core Power BI report pages are completeBlocked
  • SQL and Power BI totals reconcileBlocked
  • Executive findings are draftedBlocked
  • A written Gate 2 readiness review records an OPEN verdictBlocked

Deterministic synthetic data.Granite Auto Group is fictional.Real-engine validation pending.How this is governed

Why this page is locked

A case study is an argument from evidence, and the evidence does not exist yet: no report page authored, no Microsoft engine has evaluated the measures it would cite, no finding drawn. Publishing one now would mean writing conclusions before doing the analysis.

Unlock conditions

  • Condition not met: Core Power BI report pages are complete. powerbi/ARPI_Performance_Intelligence/ARPI_Performance_Intelligence.Report/ is a PBIR shell: a .platform file and a definition.pbir pointing at the semantic model. It contains no page, no visual and no bookmark. Delivered by P2.2.
  • Condition not met: SQL and Power BI totals reconcile. The SQL side exists as powerbi/validation/sql_baseline.json. The Power BI side requires a refreshed model, and no engine has refreshed it. Delivered by P2.2-10.
  • Condition not met: Executive findings are drafted. docs/findings/ is empty. Delivered by P2.3.
  • Condition not met: A written Gate 2 readiness review records an OPEN verdict, in the same form the Gate 1 review used.
  • Condition not met: The case-study content and its report screenshots exist in the repository. A build flag alone cannot unlock this page - the generator checks for the files.

What you can read instead

The three parts of a case study that do not depend on findings.

Where the work actually is

The analytical system is most of the way built. The argument on top of it is not started.

Complete

Complete
  • A seeded, deterministic generator suite and 114 in-memory data-quality checks.
  • A PostgreSQL warehouse: 8 conformed dimensions, 5 facts at declared grain, 178 ordered build scripts.
  • 28 documented reporting views, and a read-only role provably confined to them.
  • 29 governed KPIs, each computable from SQL and verified against an independent derivation.
  • 58 reconciliations recorded per run, every critical rule observed failing against a corrupted fixture.
  • A semantic model as TMDL: 42 relationships, 49 measures, statically validated on every push.
  • This website: a design system, seven informational routes, and a build-time manifest that fails if a displayed number has no source.

Remaining

Sequenced
  1. 01

    Real-engine validation of the semantic model

    A Microsoft engine loads, refreshes and queries the model, and its results are reconciled against the committed SQL baseline. Either accepted path closes this.

  2. 02

    The MVP report pages

    Seven pages over a model that an engine has actually loaded, so that a refresh failure is unambiguous about which layer caused it.

  3. 03

    Findings, then the Gate 2 review

    Not started, and blocked behind the report layer. The review records a written verdict against the three conditions above.

  4. 04

    This page, populated

    The case study is authored only after the verdict opens, and the gate in this build then unlocks it.

No date is given for any of these. Step one depends on provisioning outside this repository, and a predicted date would be a guess presented as a commitment.

Why the gate exists

A control that never blocks anything was never a control

It would have been trivial to write one now. A reader would probably not check. That is precisely why the gate is worth keeping: its value is entirely in the case where honouring it is inconvenient.

ADR-0009 let this website ship while the case study stayed closed, and draws the line explicitly: the two lists below are that line.

docs/architecture-decisions/ADR-0009-portfolio-ui-foundation-before-gate-2.mdthe decision and its boundariesView docs/architecture-decisions/ADR-0009-portfolio-ui-foundation-before-gate-2.md (the decision and its boundaries) on GitHub (opens in a new tab)

Permitted before Gate 2

  • This design system and application shell
  • Informational routes and architecture storytelling
  • Data-model and KPI-catalogue exploration
  • Governance and privacy content
  • An honest project-status display
  • A locked case-study shell

Still prohibited

  • Published analytical findings
  • Management recommendations
  • Report screenshots presented as complete
  • A functioning duplicate dashboard
  • Any KPI value, real or placeholder
  • Any claim that a pending validation has passed

What the case study will be built on

The system the argument will rest on, drawn from what already exists

Rendered from the same source-controlled evidence as the rest of this site. No mock-up, no chart, no value: the structure a case study would eventually reason over.

The layer stack

Six built layers, and the two above them that are not.

rawas importedstagingtyped, deduplicatedwarehousedeclared grainreportingthe only read surfacesemantic modelnever evaluatedreport pagesnot builtfindingsnot drawncase studygatedARCHITECTURE.mdlayer responsibilitiesView ARCHITECTURE.md (layer responsibilities) on GitHub (opens in a new tab)

The domain surface

Six domains a case study could reason over. Four of the deferred subjects - F&I penetration, retention, service-to-sales and target attainment - are not here, because their facts do not exist.

  • Sales
  • Gross
  • Inventory
  • Lead funnel
  • Marketing
  • Data quality

What the argument would cite

Definitions, not values. Every one of these exists today; none has produced a number from an engine.

Governed KPIs
29
DAX measures written
49
Reporting views
28
Report pages built
0

The last figure is the one that keeps this page locked.

No report page exists to screenshot, so there is no screenshot here. A composite or a mock-up would be decoration presented as evidence.