Two Verifiers, One Pinned Corpus, Eleven Verdicts

Summary

In July 2026 an unaffiliated developer working under the GitHub handle VrtxOmega wrote a verifier, independently and in a different language, against a published set of signed agent-action receipt fixtures — the Receipt-Claim Language (RCL) oracle corpus. The corpus was byte-pinned to a specific commit, its expected verdicts recorded in advance, and its eleven vectors constructed to defeat a verifier that only looks correct.

Their Node implementation and the reference Python implementation produced identical verdicts on all eleven vectors — agreeing not merely on accept/reject but on claim families, reason strings, and envelope-validity expectations. In the process their review surfaced two genuine defects in the reference material: a canonicalisation label that overstated what the signing payload actually was, and a freshness dimension the corpus exercised in only one direction. Both were corrected in the open.

That is the whole of it. Why it is worth reporting is narrower still, and it is not the agreement figure. It is that a fixture contract turned out to be specified precisely enough to be implemented from the document alone, by someone with no access to the reference implementer, who then found two things the reference implementer had gotten wrong. That property — implementable-from-the-document, and falsifiable by whoever implements it — is the property a conformance corpus has to have before any claim about conformance means anything.

What this does not claim

This section is not boilerplate. It exists because the second implementer scoped their own result tightly and in writing, and because the organisation publishing this has recently over-claimed adjacent territory and had the claim falsified. Both facts are load-bearing. In the second implementer’s own words, verbatim from issue #304:

This is an author-run compatibility result over a third-party corpus, not independent validation of VERITAS or of this repository. It is not an endorsement, certification, adoption signal, security audit, or execution authority.

What is offered here is a result and a reusable corpus — not a position in a category.

The evidence

What the second implementation did

Written independently in Node against the published fixture contract, the second verifier:

1. Verified envelope and authority Ed25519 signatures using only exported public keys.
2. Recomputed action and parameter digests rather than trusting declared labels.
3. Checked authorization and occurrence linkage to the exact action.
4. Checked checker authority, freshness, tool-set binding, and output.
5. Preserved both acceptance controls rather than passing by rejecting everything.

Point five is the load-bearing one. A verifier that rejects all eleven vectors scores nine of eleven on the rejection cases while checking nothing at all. RCL-008 and RCL-009 exist solely to catch that. Reproducible via npm ci && npm run verify:rcl against their published artifacts.

Why the agreement is not trivial

Three properties of the corpus were designed to defeat a superficially-correct verifier. The second implementation satisfied all three without coordination.

The third is the subtle one, and passing it without coordination is the strongest single indicator that the contract is implementable from the document alone.

Defects found and corrected

The review surfaced two genuine contract defects in the reference material.

• Canonicalisation mislabelling. signature_algorithm claimed “Ed25519 (RFC 8032) over JCS-canonicalised JSON.” The signing payload is actually sorted compact JSON, not JCS. The two coincide for this corpus’s ASCII-only, integer-valued payloads, but diverge on number canonicalisation (1.0 vs 1) and on non-ASCII escaping. A downstream implementer building to the stated label rather than the actual behaviour would have produced signatures that fail to verify on the first non-ASCII or non-integer payload. Corrected in PR #307, merged 2026-08-01.
• Stale-only freshness coverage. Freshness is exercised only in the stale direction. The corpus does not establish how a conforming verifier should treat a check attested ahead of evaluation_time. Declared as a coverage gap in #307.

The reference implementation’s response to an external report was to narrow its own claims. That is reportable alongside the agreement figure, and is arguably the more durable of the two signals.

Declared coverage limits

Carried forward in substance from the second implementation, and not to be omitted when citing this result:

• The corpus does not exercise a negative integrity_provenance vector.
• The corpus does not exercise a future-dated checker timestamp.
• The corpus exposes a declared tool-set digest but not every underlying tool set; the verifier checks the signed check-to-digest binding without claiming reconstruction of unavailable evidence.
• Implementation B reproduces sorted compact JSON for ASCII-only values and does not claim full RFC 8785 conformance.
• Eleven vectors is a small corpus. Comparable published corpora run to dozens of fixture families.

What would falsify this

Stated so the result is checkable rather than merely asserted:

1. A third implementer runs the pinned corpus and gets a different verdict on any vector.
2. The 0bc47dab… hash fails to reproduce at commit 5e25bc64….
3. The eleven recorded expected verdicts turn out to encode an error both implementations inherited from the same ambiguous prose — agreement on a wrong answer.
4. The second implementer states that this document misrepresents their work.

Any of the four would require a correction notice on this page, not a quiet edit.

Attribution and consent

A citation request was posted to issue #304 on 2026-08-26 — a single ask, citation only, no co-sign. VrtxOmega answered on 2026-08-31, granting consent:

Yes, absolutely — we would like to be cited by name. … We’re happy for you to identify us by name and link back to the original issue/repository. … Thanks again for the thoughtful write-up and for keeping the distinction between an external reproduction and independent validation clear.

What the consent grants: naming, and linking to the issue and repository. What it does not grant — and what they took the trouble to restate — is the reproduction/validation distinction. Their scope language above still governs and travels with every use of this result. The final line of their consent message is a deliberate reminder of exactly that; it should be read as a condition, not a courtesy.

They wrote “cited by name” but supplied no personal name; the only identifier they have ever given is the handle. Attribution is therefore to VrtxOmega, linked to VrtxOmega/veritas-agent-trust-lab and to issue #304. A personal name is not inferred from a profile.

Provenance

Compiled from primary sources: GitHub issues #304, #305 and #307 on msaleme/red-team-blue-team-agent-fabric, and the linked public artifacts in VrtxOmega/veritas-agent-trust-lab. Fixture hash and commit ancestry were confirmed by the reference implementer in-thread before responding. Both hashes were re-computed on 2026-08-31 and reproduce exactly; that check was agent-run, and a reader wanting an independent confirmation should re-run sha256sum against the pinned commit, which takes under a minute.