Validation should not be an afterthought added by policy teams after deployment.
Oliphant, 2026, §5.1
Neither should interpretation. This walkthrough is a translation, not an audit, and the questions here arise from the limits of the written form: a document may leave open what an executable substrate must decide. Nothing was silently repaired, and, just as important, nothing was silently decided. The point of this chapter is that code is not objective; its objectivity is downstream of judgment calls. Where the text corpus did not specify everything an executable specification requires, the missing judgments were not mixed into the source material. Each gap was flagged and characterized, a named adjudicator (mzargham) ruled, and the implementations were derived from those rulings.
That chain is itself data. open-questions/adjudications.ttl records,
in RDF, every gap (its problem, where it sits in the pinned source, how
and when it surfaced, its status), every ruling (the adjudicator’s
words verbatim, attributed and dated), and every implementation that
resulted. The table is a query over that record:
import sys; sys.path[:0] = [".", ".."] # the repo root, from either cwd
import exhibits
exhibits.show_adjudication_record()1The questions, characterized¶
The summary compresses; the record does not. For each gap: where it sits in the pinned source, what the substrate forced, the readings that were considered, and the reading in use:
exhibits.show_gap_characterizations()2The rulings, verbatim¶
Every ruling and note, in the order they were made — the adjudicator’s words exactly (original spelling preserved; these are quotations, not copy), and, where an external reviewer examined this repository, the findings paraphrased and attributed — each followed by what changed in the substrate as a result:
exhibits.show_rulings_log()log entries rendered: 28 — 19 rulings, 9 notes
3From code back to judgment¶
Traceability runs the full chain: from any implemented artifact, back to the ruling it derives from, to the named adjudicator and date, to the open question that ruling resolved, to the gap’s locator in the pinned source. Each anchor below is verified by the test suite to resolve into its file:
exhibits.show_judgment_trace()traceable implementations: 52 (each: implementation -> ruling -> named adjudicator -> gap -> pinned source)
4The record is held to its own discipline¶
The same treatment the Track gets applies to the judgment layer: shapes require every gap to be characterized and resolved, every ruling to be attributed and dated, every implementation to name its ruling and carry a resolvable anchor. A ruling without a named adjudicator is refused, because judgment enters the record only when someone owns it:
exhibits.check_adjudication_record()the record (12 gaps, 19 rulings, 52 implementations) conforms: True
unattributed-ruling counterexample conforms: False
A ruling must name its adjudicator (prov:wasAttributedTo): judgment is attributed, never anonymous.
One entry shows the range an adjudication can take: GAP-04 is adjudicated like the rest — the decisions needed to render the rule implementable were made — but the ruling’s content was to define the metric as a class: fix the type signature, deliberately specify the binding only at that level, and exhibit three type-satisfying examples (the previous chapter runs them; one deferral, one resolution, and three refinements are on record, the last two after the second external review split the class and fixed the matrix’s shape). The gap closed all the same; the ruling simply took a different approach, not a different kind of response. Correctly constructed is not the same as fit for purpose, and the concrete choice belongs to a policy designer, not to a translation.
The record is the only artifact: this chapter’s tables, the
characterizations, and the rulings all render from
open-questions/adjudications.ttl. The hand-written prose of the
judgment layer lives in that one file, as annotation, and nowhere
else.
5The checks¶
One script runs everything shown in these chapters plus the full test suite: the pinned toolchain, strict validation, the satisfy sweep, the counterexamples that must fail, byte-identical regeneration of the converted artifacts, the site build, and every test (including the one that re-executes these chapters and compares the outputs). The latest outcomes:
exhibits.show_checks_outcomes()pass toolchain: pinned sysml, checksum-verified
pass model: validate -strict
pass model: satisfy RunConfigurations
pass counterexample: unattended run must fail satisfy
pass generated/ regenerates byte-identically
pass site: myst build --html
pass tests: full suite
result: PASS
- Oliphant, T. (2026). The Distributed AI Economy: Intelligence Hubs, Frames, Cogs, Ops, and the Accountability Plane [Techreport]. OpenTeams.