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. This has also happened. The optional outcome member on a decision, in -02, exists because a reader on somebody else's issue tracker pointed out that an expired evidence deadline and a failed action are different facts, and the format could express neither: executed was a required boolean, so a system whose acknowledgement never came back had to assert something it did not know. That is the third category above, a case the format could not express that it plainly should, and it was raised by somebody who had not read the specification.
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.

If the editor goes quiet

The failure a one-person format actually has is not a rejected change. A rejection comes with a reason and can be argued with. The failure is silence: an issue nobody answers, for long enough that starting again looks cheaper than waiting. That is how most forks begin, and none of the text above prevents it.

So the commitment is a time rather than a promise to agree. An issue gets a substantive answer within fourteen days, or an answer saying when it will get one. Not an acknowledgement: a position, or a date. If that has not happened, the delay is the editor's failure and not the reporter's, and saying so publicly on the issue is the correct response rather than a rude one.

After ninety days with no answer of any kind, treat this format as unmaintained and act accordingly, including by continuing it yourself. Nobody should have to guess at that threshold or ask permission to conclude it.

No successor is named, and that is deliberate

A single editor could write down an heir, and it would be worth very little: an unfunded promise by one person about another, unenforceable by anyone relying on it. What is worth something is that continuing this work needs nothing that only the editor holds.

Every part of it is already somewhere else. The specification text is an Internet-Draft on the IETF datatracker, archived under a process this project does not control. The census and the working paper are deposited with DOIs at Zenodo, which serves them whether or not this site resolves. The validator is one standard-library file, the corpus is 54 records with the verdict each should get, and both are in a public repository under licences that permit continuation without asking.

So the honest statement is not that somebody will take over. It is that anybody can, and needs no cooperation from the editor to do it. A format whose survival depends on one person answering their email is already broken, whatever its governance page claims.

Who else has shaped this

The editor decides, and has been wrong in public more than once. These people found it, and the specification is different because of them. Naming them is not a courtesy: a reader deciding whether to rely on this should be able to see that its defects are found by people who do not work for it.

• Phill Clapham reported that the validator refused TR-3 to any record containing no decisions, a requirement that appeared nowhere in the specification. The scope entry exists because of it.
• impartshadow proposed the outcome member, then found within hours that the first implementation of it refused the honest case it existed to express, and proposed both may_duplicate and the placement of an approval deadline on the request rather than on the approval.
• babyblueviper1 established that the record's own clock was an attested claim the specification did not disclose, that the two checks touching it prove only well-formedness and monotonicity, and that an RFC 3161 token already carried a bound on it that no implementation was reading.

None of them is under any obligation, and a review from any of them carries exactly the weight their argument does. That is the same weight anybody else's carries, which is the point.