Your contract already knows what your tests forgot.

A state machine nothing can enforce

A shipment is BOOKED, then DISPATCHED, then DELIVERED. Your team knows those words. Your contract declares the field as a plain string.

So nothing checks the vocabulary. A typo in a test passes review, a renamed state ships silently, and a scenario that waits for a state the service will never emit waits until it times out. SODL names the field, because a lifecycle it cannot validate is a lifecycle it will not pretend to have.

[PartialLifecycle]
  WARNING Shipment [PartialLifecycle] — state field `state` is
          `string`; vocabulary not contract-validatable

Lifecycles
  Total             : 6
  Contract-def      : 4  (enum)
  String-typed      : 2  (vocabulary unverifiable)
  Partial lifecycles: 2

Excerpt. Four of six lifecycles carry a contract-declared vocabulary; two do not.

Things you can create but never fetch back

An operation creates an invoice and hands you an invoice_id. Now find the operation that takes that id and returns that invoice. Sometimes there is not one. The entity exists, it has an identity, and there is no way to observe a particular instance of it.

That is not a bug you can write a test for. It is a hole in what the API makes knowable, and it puts a ceiling on what any tool, SODL included, can verify about that entity.

Resources
  Observable     : 12 / 14
  Potential reads: 2
  Blind spots    : 0

[Observation]
  INFO AccessToken [Observation] — userGetTokens (List)
       selected; no Get-by-identity available

[PotentialRead]
  INFO Invoice [PotentialRead] — additional read APIs (not
       the canonical observation): listInvoices, getInvoicesOfOrder

Three verdicts, not two. Observable, readable but not canonically, and blind. A tool that collapsed them would be guessing on your behalf.

Operations your contract still offers and your team stopped using

Deprecation lives in the document. It rarely lives anywhere else. The operation stays routable, some consumer keeps calling it, and nobody is verifying it because everyone internally moved on years ago.

SODL reads the flag, names the operations, and then counts them in the denominator like everything else. A deprecated operation nothing exercises is exactly the shape of an outage that surprises you.

[DeprecatedOperation]
  INFO createOrderLegacy [DeprecatedOperation] — operation
       "createOrderLegacy" is declared deprecated by the contract
  INFO listInvoicesV1 [DeprecatedOperation] — operation
       "listInvoicesV1" is declared deprecated by the contract

Line format is SODL’s own; the operation names are the worked example.

What nothing touches

This is the one your current suite structurally cannot answer, because it needs a denominator and a test runner only knows its own tests. SODL derived the whole surface, so it can subtract.

Note the last line. It is not a percentage. It is a list of names, which is the form you can act on.

What sodl coverage adds to this →

$ sodl analyze

=== Scenario coverage ===

176 of 341 operations exercised

3 of 14 entities untouched
  untouched: Refund, Adjustment, Dispute

The tail of the same analyze run. Coverage is disclosure, never a gate: no threshold, no score, no effect on any exit code, because a number that can block a release becomes a number people manage instead of a number people read.