KNOBE is a context-survival protocol, not a hard security primitive. This page is for engineers, security reviewers, and adopters: an account of where the protocol provides value and where it provides none.
The open layer of KNOBE v1 verifies integrity, not truth. A passing verification proves that a sealed object has not been altered since its hash was computed. It does not prove that the author is who they claim to be, that the content is accurate, that consent was actually obtained, or that the object is appropriate for any particular use.
Where KNOBE provides value
The protocol's high-value domain is context loss through entropy, not adversarial forgery. Context is stripped away as artifacts move through pipelines, summarization tools, copy-paste workflows, and AI ingestion systems. The protocol's primary opponent is not a malicious actor; it is the loss of interpretive context that occurs automatically every time a document is reduced, restructured, or repurposed.
Entropy and the lossy middleman
KNOBE v1.0 makes context stripping evident. The primary "adversary" is an automated pipeline: a RAG scraper that drops metadata, an LLM ingestion engine that summarizes without provenance, a corporate wiki that flattens attribution, a copy-paste action that detaches a document from its source. By sealing context (fidelity limits, attribution, quarantine status, accessibility lineage) and binding it to the text with a mathematical hash, KNOBE makes any subsequent tampering evident.
It proves what context was attached to the text at the moment of sealing. Downstream actors who want to misuse the text must now actively strip the cryptographic block, leaving an auditable trail of destruction rather than passively benefiting from context that has already evaporated.
This is the protocol's main job. Knowledge objects that traditionally lost their interpretive obligations in transit now carry them in plain text, verifiable without infrastructure, and visible to any tool or human downstream that chooses to look.
Where KNOBE provides no value
The protocol does not defend against active identity forgery. This is a design choice, not an oversight. The v1 open layer is deliberately authority-free: anyone can produce a sealed KNOBE locally, and the verifier cannot distinguish a genuine seal from a fraudulent one.
Active forgery in a zero-verification culture
KNOBE v1.0 provides zero protection against active identity forgery. If a malicious actor creates a fraudulent policy document, attributes it to "The Office of the Provost," and seals it locally, the math is completely sound. A verifier will report status: verified. The seal is intact. The lie is preserved exactly as the attacker wrote it.
If downstream human receivers conflate cryptographic verified (the file has not changed since sealing) with organizational authentic (the Provost actually wrote this), the protocol can actively harm the receiver by providing security theater. KNOBE fails as an identity-trust mechanism when deployed without a PKI overlay, an institutional signing tier, or a ledger anchor.
The boundary
What status: verified proves
The payload of this file is byte-identical to what someone sealed at some point. The author's declared attribution, fidelity limits, use conditions, and interpretive context are intact as the author wrote them.
What status: verified does not prove
Who that author actually was. Whether their attribution is honest. Whether the content is accurate. Whether the sealing happened recently or years ago. Whether the institution they claim is real. Whether the consent they assert was actually obtained.
The receiver bears the responsibility for interpreting what verification means in their specific context. A KNOBE received from a known colleague in a trusted workflow carries different weight than one received anonymously from the internet, even if both verify identically. The protocol does not collapse this distinction; it surfaces it.
How identity verification can be added
v1's identity_status: "declared" field is a deliberate placeholder. identity_status: "signed" is reserved for future tiers where cryptographic identity binding becomes available. This is one of three composition pathways:
- Application-tier identity. An institution that issues credentials to its members can require KNOBE files produced by those members to be wrapped in a signed envelope at submission. The open KNOBE remains plain text; the institutional layer adds the identity guarantee.
- Ledger anchoring. A KNOBE's payload hash can be anchored to a distributed register at sealing time, providing existence-at-a-time proof. The open protocol provides integrity; the ledger provides timestamps the open protocol cannot. An anchoring tier integrating KNOBE with Apache ResilientDB (a high-throughput permissioned ledger developed at UC Davis) is being developed by the author and collaborators; other public anchoring options including OpenTimestamps over Bitcoin are also under evaluation.
- Credentialed authoring environments. Authoring tools that hold institutional credentials can layer signing infrastructure over the open protocol. Files produced inside such an environment inherit institutional identity; files produced outside it do not, and the distinction is visible.
The deliberate v1 posture: provide an integrity layer that does not require any of these to function, and let each be added by composition where the trust requirements demand it.
Classroom-scale patterns that compose these paths with nothing installed (the time sandwich, cohort receipts, and the signet design) are described on the teaching page.
Adversaries the protocol does and does not resist
Resists
- The lossy pipeline. RAG scrapers, summarization tools, AI ingestion engines that drop metadata. The sealed payload travels with the body or is visibly stripped.
- The post-hoc revisionist. If the object was sealed with a
body_hash, an actor who edits the document after the fact produces a mismatch that the verifier detects (verified-body-modified). The original narrative cannot be silently rewritten without triggering this state or stripping the seal entirely. If the originator omittedbody_hash, this protection is not available: the verifier will reportverified · body_verified: omitted, which is itself the receiver's signal that body integrity was never sealed. - The shadow-payload appender. An adversary who appends a second payload block to a legitimate file cannot do so silently: verifiers MUST surface multiple-block presence per spec §3.3.
- The lineage forger detected at traversal. An author who fabricates a parent hash seals a lie; any graph-traversal application that tries to resolve the parent chain will find the broken link.
Does not resist
- The identity forger. Anyone can declare any attribution and seal it. Identity verification requires a layer above the open protocol.
- The original liar. A document sealed with a lie is sealed with a lie. The protocol preserves the lie exactly; it does not detect untruth.
- The metadata stripper or careless intermediary. A receiver who deletes the payload block (or a human who copy-pastes only the human-readable markdown body and leaves the Base64 block behind) produces ordinary text that no longer verifies. This is a property of any portable plain-text format. The seal itself is unaffected: it remains present and checkable by any tool, human, or future AI agent that looks for it. Automated pipelines that move whole files preserve the payload; manual GUI interactions that select only visible text do not.
- The fail-open consumer. Most current consumers of
.knobe.mdfiles (text editors, LLMs, web tools) do not run the verifier. The seal does not enforce itself. Verification is the receiver's choice and responsibility. - The unverified parent claim. An adversary can list arbitrary strings as parent hashes. The lie is sealed and detectable on traversal, but the open protocol layer does not perform the traversal itself.
The disposition
KNOBE makes it harder for fragments to pass as whole objects, in a world where context is lost not through malice but through automation. It provides what its name says: a knowledge object boundary that survives transit.
Identity verification requires a PKI. Timestamp proof requires anchoring. KNOBE v1 claims integrity of declared context, and no more. Receivers who need more can compose it with infrastructure that provides more; receivers who need only what it provides can use it alone.
For audiences accustomed to PKI-grounded hard security, this is a different category of tool: one that verifies integrity of declared context rather than identity or truth.