Governance

One person: the maintainer. There is no steering committee, no technical board, no voting, and no legal entity. This is a benevolent-dictator model, and naming it is more honest than implying a process. The dictator part is real: one person can accept a pull request or change a repository setting, and nobody can overrule them. Publishing a release is similar but not identical: the maintainer alone still decides whether a crate releases at all — scoping and naming a release is his, unconditionally — but as of 2026-09-02 he may direct an AI coding agent to judge whether a release he has already scoped meets this project's own stated readiness criteria and, if so, run cargo publish for it. The benevolent part is not a promise — it is a set of constraints anyone can check: a decision about behaviour is written down before it is implemented, a declined idea is recorded with its reasoning, a rule without a test fails the build, nothing merges automatically, and the project says what it does not have rather than omitting it.

Each crate’s spec/ directory is canonical: when the spec and the code disagree, the spec is right and the code is a bug. Every behavioural guarantee carries a stable rule ID, and a coverage table — itself checked by cargo test — maps each rule to the test that enforces it. The practical effect is that arguments here are about text, not about authority: “R13 says an unrecognised sequence stays literal, and this code does not” is a complete argument the maintainer cannot wave away. That is a deliberate transfer of power away from the person holding the merge button, and it is the main thing this project offers in place of a committee.

A change lands the same way for everyone, maintainer included: the spec section changes first, then a test expresses the rule, then the code, then the documentation, then the checks pass, then the maintainer reviews and merges. Nothing merges automatically, and no tool merges anything, ever.

Most declines fall into three groups:

• It crosses a layer boundary. er7 is the ER7 encoding; validation, typed segment models, code tables, and transports belong to the layer above, which is a different project.
• It would add a dependency. The counts are zero, one, and two, each justified by name in the family policy. Healthcare integration code gets audited, and these crates are meant to sit at the bottom of somebody else’s stack.
• It would make a claim the project cannot support. No conformance certification, no comparative performance claim without a fair benchmark, no compliance statement. Overclaiming in healthcare software is treated as a defect.

A decline is written down with its reasoning, in the spec, where you can argue with it. A decision being recorded does not make it right; it makes it arguable.

The route to maintainership is open and deliberately unglamorous: contribute, show sustained judgement about the specification — not just the code — and ask. Nobody is expected to wait to be noticed.

Forking is legitimate continuity, not a hostile act, and the project is arranged to make it cheap: five licences at your option, near-zero dependencies, a specification with numbered rules bound to tests, no CLA and no copyright assignment. If the maintainer becomes unavailable, a fork is the intended answer.

The canonical document is GOVERNANCE.md at the repository root; this page is a summary of it. Conduct is governed by CODE_OF_CONDUCT.md, which applies across the workspace.