Verify + get the badge
Building on CloakAPI means your users inherit a real, verifiable guarantee — but only if your integration actually keeps to it. The conformance suite and the “Verified by CloakAPI” badge make that falsifiable rather than a promise.
This page is a pointer. The conformance corpus and the badge/trademark governance rules are maintained alongside the platform (see below) — this page tells you where they live and how they fit the builder flow, so the two don’t drift.
Why verify
CloakAPI can guarantee the parts it controls — the sealed engine, the blind relay, the signed receipt (enforcement, pushed to ~100%). What it cannot see is whether your build wired those parts correctly: did you tokenise on the client before egress, do you actually emit and check receipts, do you avoid mislabelling a Level-2 path as Level-1? The conformance suite tests exactly that residual, and the badge signals a build that passed.
The conformance suite
The cloakapi-conformance suite is a fixture corpus + runner that checks a build
against the platform contract:
- Client-side tokenisation happens before egress (Level-1), and the engine reports the expected version/hash provenance headers.
- Receipts are emitted, well-formed OpenReceipt v3, and verify offline against the public key — including chain linkage.
- Fail-closed behaviour — high-stakes secrets are refused, not silently sent.
- Honest labelling — any Level-2 path is declared as lower-assurance, not described with the client-side (“no raw PII reaches CloakAPI”) wording.
The receipt-level fixtures build on the existing OpenReceipt conformance corpus
(repo/tests/conformance — positive/negative/chain fixtures with expected
PASS/FAIL) that already backs the receipt protocol. See
Verifying a receipt and the
OpenReceipt protocol for the receipt half of the contract.
The “Verified by CloakAPI” badge
Builds that pass conformance may display the “Verified by CloakAPI” badge. The badge is trademark-governed: it asserts a specific, tested claim (this build inherits the client-side guarantee and emits verifiable receipts), so its use is tied to passing the suite and to the honest-wording rules on the Build on CloakAPI page. The badge and governance rules are maintained with the conformance program; follow those rules rather than copying badge assets ad-hoc.
What the badge does not claim. It does not claim “100% detection” or “100% safe” — no build can, because detection is best-effort and fail-closed by design. It attests to the enforcement and receipt guarantees, and to honest Level-1/Level-2 labelling. Keep your own copy inside those same lines.
Where these live
- Conformance corpus + runner:
cloakapi-conformance(receipt fixtures today inrepo/tests/conformance). - Badge assets + trademark/governance rules: maintained with the conformance program (the badge/governance doc paths) — reference those, don’t duplicate.
- The assurance model your build is measured against: Build on CloakAPI.