Validation log¶

Which objects are certified, and what their certification currently says.

Object Validation is the process page — the order of work, the sabotage rule, the report's five sections, the two gates. This page is its running record: one row per object that has been through it, with a link straight to that object's evidence.

How to read a row¶

Each row is derived from the object's own results.md, which is generated from the C implementation through its own binding — nothing here is transcribed by hand.

A findings count is not a defect count, and a high one is not a bad sign — BY DESIGN and FIXED are the common verdicts, so an object that was looked at hard has more of them.

Nor does an open finding mean the object failed. Every object in the table below holds all of its limits while carrying open findings, and the two say different things: a limit is a claim a caller may rely on, and a failing one is a regression; an open finding is a gap in what has been established, or a defect that is understood and documented but not yet fixed. Certification means the envelope is measured and holds — not that nothing is left to do. Only limits is bolded when it is short of its total, because that is the cell that would mean something is broken.

What the numbers are worth¶

The chain from code to table is gated at every link:

1. make validate regenerates each results.md by measuring the C;
2. make validate-check fails if a committed report is stale — so a report cannot drift from the code it describes;
3. this page's table is generated from those reports by scripts/gen_validation_log.py, and make docs-drift-check fails if it is stale — so the table cannot drift from the reports.

What that chain does not prove is that a limit is the right limit, or that it would fail if the behaviour regressed. Only the sabotage step in Object Validation establishes that, and no amount of regeneration substitutes for it — a report that regenerates faithfully from a vacuous assertion is faithfully vacuous.

Rows are sorted by module, then by object, so the table reads as a map of the library rather than as a history — arrival order is what the git log is for. Discovery is a glob of src/doppler/*/tests/validation/*/results.md, the same one make validate uses, so a newly certified object is listed the moment its folder exists. There is no list here to update.

Certified objects¶

34 objects certified — 23 of the 82 objects/*.toml jm fragments, plus 11 with no object manifest at all (ccsds_tm, conv, detection, ema, mpsk, resamp, rs, wfm_compose, wfm_frame, wfm_plan, wfmgen): a function primitive, or a core declared another way. Not every fragment is a DSP object with an envelope worth certifying, so read the denominator as a ceiling rather than a target — and note the two counts are different populations, not a percentage.

Not yet certified¶

Everything else. The campaign works through objects deliberately rather than in bulk, because the expensive part is not writing the report — it is enumerating a header's prose claims and proving each new C test by sabotage. An object's absence from the table above means no certification has been attempted, not that it is known to be sound.