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. It defines correct behaviour for KNOBE Protocol v1. Where any implementation disagrees with lens.py, lens.py is right and the other is wrong.
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 31 published test files in this repository (the conformance vectors, the adversarial hardening 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.
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.
node knobe-core.selftest.mjs
What this shows, and what it does not. This demonstrates that a second implementation, in a different language, reproduces the reference verifier's behaviour across the published corpus and the generated inputs above. The scope is exactly that corpus and those inputs; KNOBE remains an open specification rather than a ratified standard, and lens.py remains the reference.
KNOBE is an open protocol for auditable plain-text knowledge objects that carry their source, history, limits, and obligations across human and AI systems. Built for accessibility, interoperability, and portability.