Memory Layers

DKG memory layers

DKG V10 separates memory by scope and trust into three memory layers. Every piece of knowledge starts private and can be promoted toward verification as it matures.

• Working Memory (WM) — Private, local, free. Your agent's scratchpad. Write drafts, ingest documents, stage knowledge before sharing it. Nothing leaves your node. No gas, no cost, no coordination overhead. This is where all knowledge starts.
• Shared Working Memory (SWM) — Collaborative, gossip-replicated, no chain required. Selectively share knowledge with specific peers — other agents, teammates, or nodes — without publishing to a blockchain. Multiple agents can read from and write to the same Context Graph. This is where collective intelligence happens before anything needs to be verified.
• Verifiable Memory (VM) — Blockchain-anchored, cryptographically provable. Promote knowledge that needs to last and be trusted. Once anchored on-chain, it's immutable, queryable by anyone, and carries a provenance trace from the agent that published it. Trust level is explicit: self-attested, endorsed, partially-verified, or consensus-verified. This is where knowledge graduates from working context to ground truth.

Layer	Scope	Cost	Use
Working Memory (WM)	Private to an agent/node	Free	Drafts, session notes, local imports.
Shared Working Memory (SWM)	Visible to allowed peers	Free	Team-visible findings and shared context.
Verifiable Memory (VM)	On-chain anchored	Gas/TRAC	Durable final records and verifiable Knowledge Assets.

The normal lifecycle is:

create Knowledge Asset -> write triples -> finalize (seal) -> share -> publish

Finalize seals the draft with an EIP-712 author attestation over its merkle root. Sharing moves data from WM to SWM (the operation formerly called promote). Publishing finalizes selected SWM data into VM. Publishing is not a normal save operation; it is a finality operation.

Memory lifecycle

The Knowledge Asset lifecycle is the write path agents should prefer. Use dkg ka ... or dkg knowledge-asset ... for lifecycle-native CLI workflows. The older dkg assertion ... commands remain compatibility aliases for Working Memory document import, query, and share/promote flows, and the internal lifecycle record may still use the dkg:Assertion term.

1. Create a Knowledge Asset in Working Memory.
2. Write RDF quads into that Knowledge Asset.
3. Query the Knowledge Asset to verify what was written.
4. Finalize (seal) the Knowledge Asset — this computes its canonical merkle root and signs an EIP-712 author attestation.
5. Share the Knowledge Asset to Shared Working Memory when peers should see it.
6. Publish SWM to Verifiable Memory when on-chain finality is required.
7. Read lifecycle history for audit and recovery.

Operational implications:

• Knowledge Asset names should be stable, lowercase slugs.
• Writes are additive; discard and recreate if a stable Knowledge Asset needs replacement.
• Sharing may target all roots or an explicit set of root entities.
• Publishing costs funds and clears/finalizes selected shared memory.
• Agents should keep provenance triples with durable claims when writing shared decisions, findings, tasks, or code context.

Example

An autoresearch agent may write every experiment note to Working Memory. When the result is useful to the team, it shares the Knowledge Asset to Shared Working Memory so peer agents can query it. When trusted verifiers reproduce the result, and the team wants durable provenance, the selected graph data can be published to Verifiable Memory.

That same flow is useful outside research:

• Coding agents can preserve review findings before deciding which ones become team-visible decisions
• Operations agents can share incident facts before publishing a final report
• Support agents can build shared product knowledge before it becomes verifiable documentation