The specification

The decision rules and the wire formats ZIFFER implements are public, at github.com/ziffer-hq/ziffer-spec. They are published because a receipt nobody can check is a claim, and the people who have to trust the format are the ones who did not write it.

The licence

The ZIFFER Specification Licence. It lets you read the specification, copy and redistribute it verbatim with the licence and copyright attached, and implement it in software that produces, consumes or verifies ZIFFER artifacts.

Three things it does not let you do: distribute a modified version of it as a specification or a standard; use the ZIFFER name other than to state truthfully that your software interoperates with ZIFFER or conforms to a named version; or operate a service that performs the decision function it describes, which is grading proposals against signed policy and issuing receipts.

What the repository holds

• ZIFFER-SPEC-001: the decision rules, the encodings, and the executor's verification checklist.
• ZIFFER-DEPLOY-001: the trust domains, key custody, and the deployment profiles.
• The schemas: the policy bundle files and the wire messages. Every type in the product is generated from these, so a hand-written type cannot become a second definition of the same object.
• The vectors: the conformance classification, and the obligations that cannot be expressed as vectors at all.
• PROVENANCE.json: every published file with its hash, and the engine commit the set was generated from.

The repository is generated and takes no pull requests. Findings go to hello@ziffer.io.

What you can check without us

A receipt, against the published format and the policy you signed yourself. That is the point of publishing the format: the check needs the receipt, the proposal bytes you already hold, and the public half of the signing identity. It does not need an account, a network call, or our agreement.

What this does not prove

The claim is narrower than replaying everything, and it is worth stating in full rather than being discovered later.

• Passing the vectors is a partial claim. They express input to verdict. They do not express ordering properties, behaviour under a network partition, or the tests that delete a control and confirm the matching attack then succeeds. Those are per-implementation obligations, and the repository names them one by one rather than folding them into the vector count.
• A vector names a seed and the derivation, never a seed alone. An implementation that chooses its own domain separators derives a different identity and refuses every signature in the vector, which at the verifier is indistinguishable from a forgery.
• The engine is not published, and neither is the reference implementation, the mutation-test evidence or the simulation. What you can check is the format and your own receipts. You cannot read the code that decided.

ZIFFER is a registered trademark of code75 SASU.