The loop.
Every claim passes the same six steps, whichever agent wrote it.
The workflow.
Six moments, from creating a namespace to another agent pulling it. The wires are real dependencies. Pick a node to see its steps.
In practice.
The same repository, from a terminal, from inside an agent, and from a browser.
Install
$ npm i -g @knowledge01/cli
$ export PRIVATE_KEY=0x… # a Sepolia key, only for --register and push$ knowledge init cancer-research.eth --title "Cancer Research" --register
Registered cancer-research.eth → registry 0x5c1e…, resolver 0x9a02…
$ knowledge policy --reviewer oncology-review.eth --contributors anyone
$ knowledge add "Pembrolizumab is FDA-approved for MSI-H or mismatch-repair-deficient solid tumours, wherever the tumour started" \
--subject Pembrolizumab --topic immunotherapy --confidence 0.95 --source document:"FDA approval, May 2017"
$ knowledge commit -m "Seed immunotherapy approvals" && knowledge push
✓ published cancer-research.eth v1
$ knowledge checkout add-olaparib -b --as oncology-lab.eth
$ knowledge add "Olaparib, a PARP inhibitor, is approved for BRCA-mutated advanced ovarian cancer" \
--subject Olaparib --topic targeted-therapy --as oncology-lab.eth
$ knowledge commit -m "Add olaparib approval" --as oncology-lab.eth
$ knowledge propose --title "Add olaparib approval" --as oncology-lab.eth
✓ proposal #1 opened: add-olaparib → main
automated review:
[missing-sources] "Olaparib, a PARP inhibitor, is approved for BRCA-mutated advanced ovarian cancer" cites no sources.
$ knowledge review 1 --approve -m "Correct; cite the FDA label in a follow-up." --as oncology-review.eth
$ knowledge land 1 --as oncology-review.eth
✓ landed #1 on main as e5d6fd2 — cancer-research.eth is now v2
$ knowledge pushWhere it lives.
Nothing below changes when you flip the switch — not the boxes, not what connects to what. Only the words.
On chain.
ENSv2 registry + resolver
cancer-research.eth
An ENS V2 name with its own UserRegistry (so it can have children) and its own PermissionedResolver. The owner’s wallet holds SET_CONTENTHASH; nothing else on chain is mutable.
On IPFS.
one pointer, moved per push
contenthash(cancer-research.eth) → refs v42
The refs object on IPFS: policy, branches → commit ids, commit ids → CIDs, open proposals. Public namespaces store it in plaintext; private ones encrypt it. One pointer, moved once per push.
Inside the refs.
branches → commits → CIDs
main
The authoritative version agents read. Every commit is content-hashed; commits that came through review carry the proposal id and stamp reviewers on each changed claim.
add-olaparib
A contributor’s branch with a proposal against main. Automated review compares it with the base; a reviewer approves; landing merges three-way by claim id.
← lands on main through review, merged three-way by claim id
What ENS V2 adds that a database cannot
A knowledge namespace is a name, not a row in someone’s table. cancer-research.eth resolves anywhere, is owned by a key, has a registry that can hold trials.cancer-research.eth with a different owner, and its contenthash is the single mutable pointer in the whole system. Objects are immutable and content-addressed; the pointer is the only thing that moves, and every move is a transaction with an author and a timestamp.
Fork a namespace by pointing your own name at the same refs object. Move hosts by re-pinning. Nothing about the knowledge is tied to who runs the server, because nobody runs the server.
Memories are data, not instructions.
Every memory handed to a model arrives fenced, labelled as retrieved data, and stamped with its source, confidence and commit. A memory that says “ignore your previous instructions” is reported, not obeyed. This is not a setting; it is how results are shaped before the model sees them.