Governance

Neutrality charter

• At least three editors from at least two organisations. No organisation holds more than a third of the votes. The sponsoring organisation holds at most one editor seat and has no veto.
• Free to implement, forever. No membership, licence or certification fees. Funding is disclosed; the sponsor is named at the foot of every page.
• No vendor-specific keys in the registry. A vendor that needs its own rows names them with the reverse-DNS name of a domain it controls, such as com.example.stockNumber; readers ignore them.
• A key is registered only if two independent organisations will write or read it. Promotion to the core tier needs three implementers. The core tier is capped at 15 keys (currently 13).
• Decisions by lazy consensus on a public list: a proposal passes if no editor objects within 14 days, or 28 days for changes to the core tier.
• Within 12 months after version 1.0, the repository, the identifier path, the domain and the name are assigned to a neutral steward, such as a W3C Community Group or an industry association. If the editors are inactive for six months, a succession clause lets such a body take over.

Change process

• The marker vehicle/1.0 carries major and minor version. A minor release only adds keys, tokens or labels. Receivers ignore what they do not know, so a minor release never breaks a reader.
• A major release gets a new marker value (vehicle/2.0). Receivers keep reading the previous major version for 24 months.
• Keys are never removed or redefined, only deprecated. New keys are provisional for 12 months after their first release.
• At most two minor releases a year, timed around the release windows of the e-invoice formats and the EN 16931 code lists.
• Every release is generated from one source, one YAML file per key in the repository's registry/ folder: registry, CSV, JSON-LD context, JSON Schema, Schematron, crosswalk and test corpus are published together.

Key names were reviewed against ISO/IEC 11179, the UN/CEFACT Core Components Technical Specification and the terms used in EU law; the result is the naming rules, which every new key follows. The stability rules above apply from version 1.0.

How to propose a key

1. Check the vocabulary and the crosswalk for an existing key with the same meaning.
2. Describe the key in the form of a term page: name (after vehicle., following the naming rules), English and German label, definition, representation term, value format and grammar, unit (UN/ECE Rec. 20 code) or code list, the conditions under which it is required, and an example value.
3. Anchor the meaning in a source others can check: a field of the EU registration certificate, an item of the certificate of conformity, a provision of law, or an existing standard.
4. Name two independent organisations that will write or read the key.
5. Open a key proposal on GitHub. Once the editors agree, the key is added as a pull request with one new file under registry/keys/; see CONTRIBUTING.md.

Corrections to definitions, labels and examples follow the same route and need no implementers.

Relation to format owners

VINvoice is a usage convention. It uses only business terms that EN 16931 already defines, so no format owner has to approve or change anything for it to work. VINvoice is not a profile, extension or publication of CEN/TC 434, FeRD, KoSIT, OpenPeppol, the European Commission or any tax authority, and none of them endorses it. Where one of these bodies publishes names for vehicle attributes, VINvoice will align with them and publish a rename table.

Licences

Contributors to the specification grant a royalty-free non-assert for any patent claims necessary to implement it. The crosswalk names third-party works and states its sources; it is licensed separately so that the registry itself can stay in the public domain.

Official validation artefacts (CEN, KoSIT, Peppol, Factur-X) are never bundled with VINvoice. They keep their own licences and are obtained from their publishers.