The dimensions

The report scores your model along several independent dimensions. They are kept separate on purpose: a single number would let a strong showing in one hide a hole in another, and the holes are the point.

D1 — Specification completeness

Scored before any test runs, because it is pure authoring. It asks whether each declaration that should carry an obligation actually does:

• a mutating command has declared authorization, and a declared error contract;
• an entity in a tenant-scoped context declares an isolation axis, or is explicitly global;
• an author-declared string field carries at least one constraint;
• a public route has an explicit policy and a quota;
• an aggregate root has at least one invariant, or an explicit acknowledgement that it has none;
• a capability states its business value; an operation carries documentation.

A low D1 is not a testing problem. It means the model has not yet said enough to be checkable — and fixing it is authoring work needing no test infrastructure at all, which makes it the cheapest score on the report to move.

D2 — Behavioural verification

The one people expect: of the derived obligations, how many did a run discharge? Computed only when you fold a results file in — without one, every obligation is unverified and D2 is not reported rather than reported as zero.

D3 — Business-process coverage

Does every step of every modelled business process have a passing scenario behind it?

This dimension is declared absent in the report's scope boundary rather than silently omitted, which is a distinction worth noticing: a dimension quietly missing reads as a dimension passed.

D4 — Isolation and authorization

The security dimension, and the one with the sharpest rule attached.

It is scored whether or not anything ran. The isolation and policy obligations exist as soon as the model declares them, so a dimension that vanished when untested would read as absence of risk — exactly backwards. An unverified security obligation is reported as critical:

⚠ CRITICAL (D4): a security obligation is not verified
  2 isolation or authorization obligations have no passing case. Each one
  is a statement the model makes about who may reach which rows, with
  nothing behind it.

Its score is capped and annotated "application-layer only" until the run is against a real deployed stack. In-memory repositories carry no row-level security, so a hermetic run can demonstrate that a handler refuses a caller — and cannot demonstrate that the database would have refused one that got past the handler. Those are different guarantees and the report will not conflate them.

D5 — Operational readiness

Whether the thing is wired to run. This catches the class of defect that compiles, passes every test, deploys, and then does nothing:

• the model emits events and subscribes to them, but no event transport is configured — critical, and the shape where a signup "succeeds" and no email is ever sent;
• retryable or externally-triggered commands with no idempotency;
• public routes with no quota;
• a cache populated on read with nothing invalidating it on write;
• fields that store files with no storage configured;
• sensitive fields reaching a wire surface;
• manifest values referencing environment variables with no default and no documentation.

D6 — Claim honesty

Reconciles what the model claims against the evidence behind it, and it is where maturity becomes consequential.

Its sharpest output is a falsified claim: a capability provided at a strong maturity whose underwriting obligations are unverified. That is not a coverage gap — it is the model telling a reader something untrue, and it is the line an enterprise security review actually wants tested.

The verdicts, and the deliberate asymmetry between them, are in Capabilities.

D6 also reports drift — an operation implementing a feature that no system it belongs to ever planned. A capability shipped without a home in the plan is one the architecture map does not know it has.

Reading a report

  your-app                                             L0  ▸ blocked
  ─────────────────────────────────────────────────────────────────
  Blocked from next    L1 — D1 reports 29 scored violations
  Binding constraint   D4 — a security obligation is not verified (2 occurrences)

  D1 Specification     ████░░░░░░░░░░░░░░░░  21%   29 findings
  D4 Isolation & authz ░░░░░░░░░░░░░░░░░░░░   0%   ⚠ 2 critical · 2 findings
  D5 Readiness         ███████████████░░░░░  75%   2 findings
  D6 Claim honesty     ████████████████████ 100%   0 findings

  Obligations          51 declared — 0 verified · 51 unverified · 0 unverifiable
                       10 require a real deployed stack

Read the binding constraint first. It names the one thing standing between you and the next level, so the report tells you what to do rather than leaving you to infer it from four progress bars.

Note that D6 reads 100% here while D4 reads 0%. That is not a contradiction: nothing has claimed a strong maturity, so nothing is overstated. Claiming little honestly scores well — which is the incentive the whole design is trying to create.

Read next: Assurance levels.