The Field That Is Always Empty

A governance event contains a field named obligationsEvaluated. Every run emits an empty list. The schema accepts it, the dashboard displays it, and no one can tell whether the run evaluated no applicable obligations or whether the code that records them has never been connected.

The empty list is not inherently wrong. The problem is that several materially different states have the same representation. A consumer sees a value but cannot determine what work, if any, produced it.

This is an illustrative engineering pattern, not an incident claim about a particular product. It is worth checking wherever a field is used to support a review or a coverage claim.

Define what the field is evidence of

Start with the question the field is meant to answer. Does it identify the obligations selected for a run, those actually evaluated, or those that passed? These are different sets. A generic name can hide the distinction before implementation has even begun.

Suppose the field identifies obligations actually evaluated. An empty list can be legitimate when a completed applicability check finds none relevant. It cannot, by itself, show that applicability was checked. It also cannot distinguish an evaluation that failed to start from instrumentation that does not exist.

A reviewer needs the result and its scope: what input was assessed, which rules applied, whether the run completed, and where the evidence can be found.

Represent the states separately

A simplified event might originally contain only this result:

{
  "runId": "example-run-17",
  "obligationsEvaluated": []
}

An illustrative revision makes the incomplete state explicit:

{
  "runId": "example-run-17",
  "evaluationStatus": "not_evaluated",
  "reason": "required_input_missing",
  "policyVersion": "example-policy-3",
  "obligationsEvaluated": [],
  "evidenceReferences": []
}

The exact field names belong to the system's contract. The important distinction is semantic. A completed run with no applicable obligations should say that applicability was assessed and refer to the assessment. An uninstrumented field should identify that limitation. A failed run should carry its failure state rather than looking like a completed evaluation with no findings.

Do not require a non-empty list simply to make the dashboard appear active. That would replace missing information with invented information.

Validate the relationship, not only the type

An array type permits an empty array unless additional constraints rule it out. JSON Schema supports size constraints such as minItems, so “the schema cannot detect this” is too broad. The schema must encode the intended rule, and some rules also need application-level checks against what the run actually did. See the JSON Schema array reference.

For example, a run that reports completed evaluation of identified obligations should include those identifiers. A run that reports no applicable obligations needs evidence of its applicability assessment. A missing policy input should not result in a completed status. These relationships can be tested with deliberately constructed cases.

Include a case with genuinely no applicable obligations. Otherwise the tests may teach the implementation to produce content whenever an empty result would be correct.

Make the dashboard preserve those distinctions

A dashboard should show “not evaluated” differently from “completed, none applicable.” Aggregating them into the same zero obscures the coverage a reviewer is trying to understand.

Track incomplete or uninstrumented events separately and assign ownership for resolving them. If a field is being introduced in stages, tell consumers when its meaning changes. A downstream team that has treated empty as normal needs to know how to interpret the first populated result.

A field that never varies is a reason to investigate, not proof of a defect. The workload may genuinely produce the same outcome. Check whether the expected triggering condition occurred and whether the pipeline represented it correctly.

Ask a small set of evidence questions

Pick a field used in an approval or governance report. Ask what it means, what makes it change, and how its value is derived. Then inspect a completed case, an inapplicable case, and a failed or incomplete case. Can the consumer distinguish them without reading an implementation comment?

Follow one reported value back to the run that produced it. Check that the evidence reference resolves and supports the stated result. This is a more useful test than asking whether the dashboard looks populated.

The same principle applies to a decision record. A rationale, constraint, or review field is valuable because a person can inspect what it represents and follow its basis. Filling the field is the start of that discipline. Preserving its meaning is what makes it evidence.