The Testimony Record is edited by one person. That is a real limitation and this page exists because pretending otherwise is how a format gets forked.

Formats do not fragment over their content. They fragment over governance: somebody could not get a change in, or the terms moved under them, and the cheapest response was to start again. Markdown was forked because its author declined to standardise it. RSS split over a governance dispute. Neither fork was about the syntax.

So the route in is written down, before anyone needs it.

What gets accepted

• A defect. The validator refuses something the specification permits, or accepts something it forbids. These are fixed fastest and the person who reported it is named in the erratum.
• An internal inconsistency. Two clauses that cannot both be satisfied, or a requirement stated in one place and contradicted in another.
• A case the format cannot express that it plainly should. The strongest form of this is a real record from a real system that has to be distorted to fit.
• A requirement that cannot be checked. Anything the validator cannot decide is a defect in the specification, not in the validator. A conformance claim nobody can check is an adjective.

What does not

• A field for a use case with no implementation behind it. The format stays small on purpose and every addition is a thing every future reader must understand.
• Anything that requires particular software to satisfy. If a competitor could not implement it, it does not go in.
• Loosening a refusal because a system fails it. That the format refuses something is usually the point.

How to raise one

Open an issue on the repository, or write to the editor. Both are read by the same person, and neither is a form.

https://github.com/troybrandonc-bit/machine-testimony/issues
troy@machinetestimony.com

A report is strongest with a record that demonstrates it. The validator is one standard-library file with no network access, so the smallest useful bug report is a few lines of JSON and the level you expected.

What happens then

1. A defect that can be shown gets a fix and an erratum on the specification page, naming the person who found it. This has happened: the scope entry in version 0.2 exists because Phill Clapham reported that the validator refused TR-3 to any record containing no decisions, a requirement that appeared nowhere in the specification text.
2. A change to the format itself waits for the next version. Within a major version, entry types and required fields are only added, never removed or repurposed, so a reader written against 0.1 keeps working. Breaking changes get a new major version and both stay published.
3. A rejection comes with a reason. If the reason is wrong, say so; being argued out of a position in public is a better outcome for the format than being right quietly.

The honest limits

There is no committee, no vote, and no appeal to anybody other than the editor. A single editor is faster than a process and you can see exactly who to argue with, which is worth saying plainly rather than dressing up.

The counterweight is that nothing here is held back. The specification text is CC BY 4.0 and the validator is MIT, so anyone who disagrees strongly enough can take the format and go, with no permission needed and nothing to negotiate. That option existing is what makes the arrangement fair, and using it is not a hostile act.

The specification is also deposited as an IETF Internet-Draft, which is archived independently of this site and of its editor. It confers no formal standing and the datatracker says so on the page. What it means is that the document survives whether or not anything here does.