Every suite, every verdict, and everyone who checked it themselves.
Each suite below ships an independent checker that imports no
Vaara code and recomputes its verdicts from the bytes of its own case files.
This page is generated from the runner's report, so it says what the checkers
did rather than what a document claims they do.
46suites
43passed
0failed
3skipped
75cases
generated 2026-08-21T13:35:08Z
Run it yourself
Nothing here needs Vaara installed. The checkers use the standard library
plus cryptography and rfc8785.
Point --vectors-dir at a directory laid out the same way and it
grades those bytes instead. The runner collects; the checkers decide.
What a pass does not establish
These vectors are Vaara's and there is no ratification process behind them.
The maintainer adds the cases and decides what a verdict means, and nobody else
has a vote. That is a real limit on any neutrality claim and it is stated here
rather than argued around.
What the corpus does give is narrower and checkable: every case
recomputes from committed bytes with no Vaara import, so anyone can disagree
with an expected result and show their work. Recompute is checkable by
strangers. Authorship is not.
Independent reproductions
Parties other than the maintainer who ran the checkers and reported the
outcome in public. Claims are quoted as each party scoped them. Everyone here
asked to be listed, knowing the entry is permanent.
To add your own run, open
a row request. Row numbers are permanent and each listed party gets its
own badge, carrying that number, the date and the commit. A badge says the
party ran the checkers at that commit on that date. It never says currently
passing, and it is not a certification.
Checking a badge without trusting this page
Each badge carries the digest of its own row inside the SVG, and the row
it commits to is served as JCS-canonical bytes (RFC 8785) next to it. The
file holds those bytes and nothing else, so verifying a badge is one command
and needs no parser, no canonicaliser and no Vaara installed.
curl -s https://vaara.io/badge/<slug>.json | sha256sum
curl -s https://vaara.io/badge/<slug>.svg | grep digest
python scripts/vcr_chain.py # nothing removed from the table
The two agree or the badge is not describing that row. This
is the same property the corpus runs on, applied to the badge itself: a
claim that recomputes from bytes, checkable by someone who trusts neither
the party nor Vaara.
Terms for a listed party, version 2026-08-21
Stated before there is anything to sell, so that anyone
deciding whether to be listed can read the commercial position at the moment
they decide rather than learn it afterwards.
A row is permanent. This records something that
happened. A run took place on a date at a commit, and that stays true, so
the entry stays. Asking will not remove it. Rows are chained, so removing
or reordering one changes every digest after it, and each published head is
recorded in a public transparency log the maintainer does not operate, so a
rewritten chain reaches a head that matches no witnessed entry. Both halves
are checkable by you rather than promised by us.
What the chain gives, and what it does not. Rewriting
or reordering a published row changes every digest after it, and anyone
recomputing the chain sees the break. Removing rows from the end is
a different thing: what remains is a perfectly valid shorter chain, and a
reader holding only this file cannot tell. So removal is detectable relative
to a retained head. vcr_chain.py says on every run whether the
tail is pinned instead of leaving it to be assumed, and reports
tailPinned in its JSON so nothing downstream reads
verified as verified to be complete. Each published head is
also recorded in a public transparency log the maintainer does not operate,
which pins the tail for a reader who retained nothing of their own. The
residual is narrow and real: a row added after the last witnessing carries
only the chain until the next head is published.
Nothing is edited after the fact. A correction is a new row referring
to the earlier one, never a rewrite of it.
What an outside suggestion can change. Wording here
changes when it is shown to be false, and anyone may show that, including a
party that competes with Vaara. A case, an expected verdict or a checker
changes only on evidence that the current one is wrong, never on request and
never to make a party pass. Every such change is a commit anyone can diff.
A row and its badge are free, and stay free. There is no paid tier of
being listed and no version of a row that counts for more.
Vaara may sell services built on these same vectors, including a
countersigned result. Being listed here is never a condition of buying
anything, and buying something is never a condition of being listed.
No listed party's name, affiliation or badge is used to sell anything.
Rows are a record, not a customer list and not a reference.
Each row records the version of these terms it agreed to. Terms may
change for rows added later. A row already listed keeps the terms it was
listed under, and a change is never applied backwards.
Ran the independent checkers exactly as documented (git clone, pip install cryptography rfc8785, python scripts/conformance_runner.py) in an isolated venv, no Vaara install. Establishes that the checkers reproduce their own stated verdicts against the shipped case files at this commit. Does not establish interoperability between Vaara's proofs and our own (invinoveritas) proof format.
