trust-levels: the all-zero measurement convention is stated with two different scopes

[chernistry]

Spec section affected

docs/trust-levels.md (Level 0 section) and the runtime.measurement description in schema/trace-claim.json.

Problem

runtime.measurement is required on every record, its pattern demands a sha256:/sha384: digest, and its description reads "Hardware measurement of the workload (e.g. TDX MRTD, SEV measurement, TPM PCR composite)" — a thing a software-only producer does not have. The value such a producer should write is given in docs/trust-levels.md, twice, with two different scopes:

1. The Level 0 minimum-fields block writes "measurement": "sha256:0000...0000" for a record whose platform is software-only, with no qualifier.
2. The sentence directly under that block says the all-zero digest "is conventional for software-only development records".

A production software-only producer — a runtime emitting records for its own executions, origin.kind: self, no hardware root of trust — is covered by the first text and not by the second. Since the field is required, every such producer must write something, and today the correct value is assumed from the block rather than stated by the prose. This is the same narrowing #232 reports on the platform description, one field over: the loose text and the narrow text sit six lines apart and a reader has no way to know which is normative.

Proposed change

In docs/trust-levels.md, replace the sentence under the Level 0 block with:

The all-zero measurement is the defined value whenever runtime.platform is software-only, whether the record is a development record or a production record from a producer with no hardware root of trust.

Optionally, extend the measurement description in the schema with "; all-zero when platform is software-only", so the text closest to a validator states the convention rather than implying its absence.

Backward compatibility

• Non-breaking (new optional field, informative addition)
• Breaking (removes or changes required field, changes wire format, changes algorithm set)

Existing records already use the all-zero value; this states the scope of an existing convention rather than changing it.

Motivation

A producer implementing v0.2 for a production software-only runtime (#231) has to pick a measurement value today and can only do so by treating the "development records" qualifier as the loose half. That guess should be the spec's sentence, not the implementer's.

Related issues or PRs

#231 (producer thread where this surfaced), #232 / #234 (same loose/narrow pair on platform), #172 (prior instance of the shape).

[imran-siddique]

Tracking the pattern this belongs to in #247: the normative spec, the JSON Schema, the reference model and the docs state the rules and nothing says which wins. This issue is one of five instances found in three days. The ruling above stands on its own; #247 is about stopping the next one.

[chernistry]

Following the #247 note — I want to check this one is not treated as answered by it. Unlike #244 and #232, no ruling was issued here, and the tracking comment's "the ruling above stands on its own" has no earlier ruling to refer to on this issue. The open question is unchanged and narrow: a production software-only producer (origin.kind: self, no hardware root of trust) must write some runtime.measurement, and today the all-zero value is only reachable by reading the Level 0 block and treating the "development records" sentence as the loose half. If the intended scope is every software-only record rather than development records only, one sentence in docs/trust-levels.md settles it and I am happy to carry the PR. If #247 is meant to absorb this instead, that works too — I would just like it recorded which.