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.
50suites
47passed
0failed
3skipped
88cases
generated 2026-09-13T17:30:38Z
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-22
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.
Every row names what kind of run it was. What a run
establishes is a property of who wrote the verifier and who wrote the
vectors, not of how well it went, and the four are not degrees of one
another. A reproduction is the author's checkers over the author's
vectors: it establishes that the artefact runs and is byte-stable somewhere
other than the author's machine, and nothing about the specification text.
A construction reproduction derives a published value from the
prose that describes it, without running the author's verifier and without
writing a second implementation: it establishes whether the description was
sufficient to get there, which is a question about the text answerable with
no code on either side. An independent implementation from the text,
run against the author's vectors, establishes something about the text,
because a second reader had to decide what the sentences meant and then
build to that decision. An independent implementation run against
independently constructed vectors establishes something about both. A
row that does not name its kind reads as the first, because that is the
weakest claim available. Rows listed before this field existed carry no kind
and are never edited to add one, so this rule covers them instead.
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.
45 passed, 0 failed, 1 skipped, 75 cases. Runner exit 0. The skip is `article12_fold_v0` (checker wants a bundle zip argument rather than a bare case directory — structural, not environmental). An earlier same-day run at f0dbf4d8 gave 44/45, 65 cases, 0 failures, before the corpus grew.
Kind of run
Not stated. An unstated kind reads as a reproduction, the weakest of the three.
This is a reproduction of the author-supplied checkers and vectors at commit a209864e. It is not an independent implementation of draft-sirkkavaara-vaara-receipt and not a validation of the specification text. The figures match row #612 at the same commit on a different machine and OS (Linux, Python 3.12, clean venv), making this an independent confirmation of that row's byte-stability. pq_hybrid_v0 and qualified_time_v0 ran with their optional dependencies installed rather than skipped.
#32026-08-24Emek Can DoğruVERAX TEKNOLOJİ LİMİTED ŞİRKETİ — independent of Vaara
45 passed, 0 failed, 1 skipped, 75 cases. Runner exit 0. The skip is `article12_fold_v0`, whose checker validates a passed-in bundle zip rather than a bare case directory — structural, not environmental.
Kind of run
Reproduction: the author's checkers over the author's vectors
This is a reproduction of the author-supplied checkers and vectors at commit a209864e. It is not an independent implementation of draft-sirkkavaara-vaara-receipt and it is not a validation of the specification text. The checkers importing no Vaara code is what makes the reproduction worth anything; it remains the author's corpus grading the author's cases. The skip is `article12_fold_v0`, whose checker validates a passed-in bundle zip rather than a bare case directory — structural, not environmental.
Reproduction of author-supplied checkers at the pinned commit, macOS arm64 / Python 3.14.6, clean venv. Validates the pinned independent vector lanes. Does not establish hosted-service interoperability, official SCITT conformance, or an independent implementation.
Reproduces the published independent vector lanes at commit 54a69b3 using only standard public libraries (cryptography, rfc8785), with no Vaara code imported. 43/46 suites passed, 0 failed, 3 skipped (optional-dependency lanes). Establishes reproducibility of Vaara's published verdicts over the pinned corpus. Does not establish integration of Insight oracle attestations into Vaara records, nor any opinion on Vaara's compliance standing.
2 suites passed, 0 failed, 0 skipped; both selected suites matched their published expected verdicts. No declared case count is exposed by this pinned corpus layout; see record.
Kind of run
Reproduction: the author's checkers over the author's vectors
Suites
record_conformance_v0, record_set_v0
At commit
d44b8b0de4f5f3e4e5c0248ad1e6fbbc3972b317
Their scoping
Ali Toygar Abak / Phionyx executed Vaara's published record_conformance_v0 and record_set_v0 checkers over the pinned SEP-2828 1.0.0 vectors at commit d44b8b0de4f5f3e4e5c0248ad1e6fbbc3972b317. This is a reproduction of the author's checkers over the author's vectors. It does not establish an independent implementation, independently constructed vectors, specification correctness, complete Vaara product conformance, hosted-service interoperability, Vaara-AIREP interoperability, certification, or endorsement.
