The spec, built more than once.

A protocol is defined by its specification and its test vectors. An implementation earns trust by agreeing with them. KNOBE Protocol v1 has a Python reference verifier and two JavaScript verifiers that reproduce its verdicts across the published test files, with one documented exception noted below.

The reference verifier

lens.py is the reference verifier: a single Python file that uses only the standard library, with no external dependencies. The published test vectors and their expected results are the arbiter of conformance; where they leave a detail undecided, lens.py is canonical for serialization ambiguity under spec §5, and rulings for everything else are documented in ERRATA.md, with normative text prevailing over observed reference behaviour and any conflict recorded there.

The browser Lens

The browser Lens (knobe.org/lens, site/lens.html) is a JavaScript verifier that runs entirely in the page: drop in a .knobe.md file and see the verdict, with nothing uploaded. It reproduces lens.py's verdicts across the vectors, with one deliberate exception: in a browser, where numeric canonicalization cannot match Python's guarantees, it declines to issue a hash verdict on bare-numeric payloads (a §5 violation) and defers to lens.py as canonical for that case.

A JavaScript sibling engine

knobe-core.js is a JavaScript sibling verifier: a single standalone file, with no dependencies, that runs in Node and in the browser. It was written by closely studying lens.py: a sibling, sharing no code but sharing lineage.

Unlike the in-page browser Lens, it reproduces lens.py's verdicts including the bare-numeric case, and it goes beyond verification: it also seals, creates, and derives KNOBEs and evaluates their use conditions, using the same rules as the reference. It is the engine that Studio and the MCP server are built on.

Applications and integrations

Verifiers answer to the test vectors; applications build on the protocol. This registry lists both. A listing is a factual entry, not an endorsement: each project answers to its own maintainer, and each states its own limits.

• KNOBE Studio (this site) builds, verifies, transforms, and batch-checks sealed objects in the browser page, on knobe-core.js. Nothing is uploaded.
• knobe-mcp (npm) exposes verify, read, create, transform, and permits to any MCP client, on the same engine, running locally.

To be listed, a project needs: a named maintainer; public source; if it verifies, behaviour checked against the published test vectors; and a plain statement of what it does and does not do. Open an issue with those four things and it goes in the list. For how to name a tool that builds on KNOBE, so people can tell it from the reference tools, see Name and mark use in the governance doc.

What has been checked

knobe-core.js and the reference verifier were run against the 37 published test files in this repository (the conformance vectors, the adversarial hardening set, the interpretation set, and the sealed examples) and against roughly 61,000 additional, automatically generated adversarial inputs: malformed structure, Unicode edge cases, numeric formatting, oversized and deeply nested payloads, invalid encodings, and mutations of the fixtures.

Across all of them, the two verifiers returned identical verdicts (status, conformance level, body result, computed and stored hash, block counts, and exit code) with no disagreements and no crashes within that generated set. An earlier run did surface a divergence: a floating-point value that the two languages formatted differently. It was traced, fixed, and re-checked clean.

The corpus is also how the specification improves. When an implementer building from the text reports an ambiguity, the steward resolves it as a documented ruling in ERRATA.md, pinned where practical by a new vector both reference engines agree on before publication; the third verifier, built from the specification text alone, surfaced erratum E11 exactly this way. As of July 2026, no implementation independent of the steward, as GOVERNANCE.md defines independence, has passed the full vector set: that is the open milestone the shared-governance triggers turn on, and the door is the issue tracker.

Running the check yourself

Both verifiers ship in this repository. The parity check runs both over every vector and example and reports agreement. It needs Python 3 and Node present, because it is a cross-language check by design.