Repository navigation
Conversation
Curator daemon + CLI bridging OpenClaw workspace memory into DKG V10 three-layer verifiable memory (WM -> SWM -> VM) with maturity tracking, secret redaction, and an explicit human-gated Verifiable Memory publish. Validates against schema: 0 errors (VM write-authority warning is expected and justified in fitNotes: promotion is CLI-gated, never automatic, per the bounty's no-UI-endorsement rule).
- commit re-pinned to the pushed HEAD (previous value did not resolve) - LICENSE and provenance publish workflow added to the repo - security.notes document the Round-1 VM scope justification
kiyeps
changed the title
…/version fixes, demo + designBrief
…, normalise writeAuthority paths
… -> recorded walkthrough
…uence The previous pin (a595a809) still carried the buggy createKA(name, quads) form, which DKG node v10.0.19 rejects with 409 KA_ASSERTION_ALREADY_FINALIZED on every subsequent wm/write. 8a8427d routes the write path through writeKaSequence (draft -> append -> finalize) with discard-on-failure, adds wmDiscard to the client, and tracks the real node KA name in maturity.slug so timestamped re-ingests resolve when shared. Tests: 33/33 pass. Schema validation: 0 errors, 1 warning (VM write authority, justified in security.notes as the interactive-only publish gate).
…quence) Same code as 8a8427d; the follow-up commit only syncs README/CLAUDE.md/AGENTS.md with the corrected write sequence, node version and corpus size. Pinning the full 40-char SHA keeps the entry consistent with the published repo state.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
integrations/openclaw-memory-curator.json— a registry entry for OpenClaw Memory Curator, a curator daemon + CLI that bridges OpenClaw workspace memory into DKG V10's three-layer verifiable memory system.Repo: https://github.com/kiyeps/openclaw-memory-curator (commit pinned in entry)
What it does
memory/*.mdworkspace files into Knowledge Assets with provenance quads, lands them in Working Memory (272 files smoke-tested live, 43 secrets auto-redacted, 0 errors)share:tag),swm/shareseals by default → publish-ready assertions (verified via SPARQLshared-working-memoryview)curator publish <ka>) with interactive confirmation — never automatic. This satisfies the bounty rule that UI endorsement is disallowed; the gate is a deterministic human/CLI act.Why it fits
The first-party OpenClaw adapter is a chat bridge + read-only memory recall; all writes are delegated to the agent via SKILL.md prose (lossy, undisciplined). This integration fills that gap with deterministic, auditable curation — the LLM-Wiki / autoresearch direction the bounty targets.
Checklist
security.notes)urn:openclaw:memory:*subjects, no per-quad graph fieldSubmission metadata — final update (2026-10-15)
Tag:
cfi-dkgv10-r1Pinned commit:
494b0b22a61ff75f9cfd00260228bdeda8938fa6(v0.1.2)Contributor attestation (§8a.8): I attest that this submission is my own original work (or properly licensed third-party work), and that it contains no intentional backdoors, no hidden remote-execution paths, and no undeclared network egress. — @kiyeps
Design brief: https://github.com/kiyeps/openclaw-memory-curator/blob/main/docs/DESIGN.md
Demo: https://github.com/kiyeps/openclaw-memory-curator/blob/main/docs/demo-transcript.txt — recorded against a live local DKG V10 node (v10.0.15, Base Sepolia testnet, context graph
openclaw-curator) with an isolated demo memory directory. Real runtime interaction: status → ingest → list → recall returning WM + SWM bindings.Round-1 VM-scope justification (validator warning): The validator flags
writeAuthoritybecause the entry declares one VM operation (POST /api/knowledge-assets/:name/vm/publish). This declaration exists for accuracy, not because Round-1 features depend on it: the operation is the documented end of the WM → SWM → VM promotion path and is reachable only through the interactivecurator publish <ka>CLI command gated by a y/n confirmation. It is never invoked automatically, never invoked by the daemon loop, and no other VM operation (/endorse,/verify,/update) is declared or used. All Round-1 functionality (ingest, recall, list, share, daemon) operates purely in WM/SWM. Declaring a gated capability the code genuinely contains was preferred over omitting it; we believe this satisfies "explicitly justified". If the committee prefers, the field can be trimmed to WM/SWM-only in a follow-up commit.Security notes (§8): Secret redaction (private keys, API tokens, mnemonics) runs before any literal leaves the process. All HTTP egress is restricted to the local node (
http://127.0.0.1:9200). Reads the DKG auth token from~/.dkg/auth.token; never logs it. SWM share seals assertions by default. Curator-authority surfaces are documented in the registrysecurity.notes. Recall display hardened against string/term binding shape differences.Write-sequence correctness (v0.1.2): DKG node v10.0.19 seals an assertion at creation time, so
createKA(name, quads)returnswm-sealedand every laterwm/writeis rejected with409 KA_ASSERTION_ALREADY_FINALIZED. The pinned commit routes the write path throughwriteKaSequence—createKA(name, [])→wmWriteper batch →wmFinalize— and discards the partial KA when any step fails, so a failed ingest can never leave residue. This was found and fixed during live operation, where 8,890 partial KAs had accumulated and inflated the Working Memory view by 90%.Maintenance commitment: Maintained by @kiyeps; support window ≥ 6 months post-merge.