Assurance levels

A level answers "what is now true?". Each one is a set of enumerable, checkable predicates, so a claim of "Level 2" decomposes into specific statements someone can audit one at a time — which is what makes it defensible to a security review in a way a percentage never is.

Levels are computed per bounded context and per capability, then rolled up. Enterprises adopt incrementally, and a mature payments context should not be dragged down by an experimental one beside it.

L0 — Declared

The model compiles clean of errors.

Means: the system is internally consistent. Nothing whatsoever about behaviour.

L1 — Specified

Specification completeness is clean, and there is no feature drift:

every mutating command has declared authorization and a declared error contract;
every entity in a tenant-scoped context declares an isolation axis or explicit global;
every author-declared string input carries at least one constraint;
every public route has an explicit policy and a quota;
nothing implements a feature no system planned.

Means: the model states enough about itself to be worth verifying.

This is the level most existing systems do not reach on a first run, and reaching it is pure authoring work — no test infrastructure required. If you are starting out, this is the level to aim at, and the report will tell you exactly which declarations are missing.

L2 — Verified

L1, plus:

every obligation is verified, or unverifiable with a recorded reason;
no unverified obligation outside an explicit, unexpired waiver;
the generated suite is green;
every business-process step has a passing scenario.

Means: everything the model declares about behaviour has been demonstrated — in a hermetic substrate.

L3 — Proven

L2, plus the same obligation set green against a real deployed stack: a real database with row-level security, a real broker, real external gateways.

isolation obligations verified at the persistence layer, not merely the application layer;
nothing that needs a real stack left unverified.

Means: the demonstration survives real infrastructure semantics.

L2 → L3 is the step people underestimate. A handler that refuses the wrong caller and a database that would have refused them anyway are different guarantees, and only one of them survives a bug in the handler. This is the level worth putting in front of a customer's security team.

L4 — Assured

L3, plus operational readiness and the evidential half of claim honesty:

event delivery wired, observability present, idempotency on retryable commands, quotas on public routes, migrations complete;
no falsified claim — nothing claiming a strong maturity that its obligations do not support.

Means: it is verified, it survives real infrastructure, it is wired to run, and it does not overstate itself.

Using levels

Read the binding constraint, not the number. The report names the single thing standing between you and the next level. Working that one item is almost always the highest-value change available, and it saves you triaging four dimensions by hand.

Set a floor, per context. A build can require a minimum level, and different contexts can carry different floors — which is the shape real adoption takes:

vishwakarma assure --min-level L2
vishwakarma assure --min-level payments.v1=L3 --min-level L1

Do not chase L4 everywhere. An experimental context at L1 beside a payments context at L3 is a healthy system that knows which is which. A project uniformly at L2 because somebody targeted an average has told you nothing about where the risk is.