[cfi-dkgv10-r1] Add langchain-dkg: LangChain memory + retriever for DKG v10

[haroldboom]

What this PR does

Adds langchain-dkg as a community integration. LangChain BaseChatMessageHistory, RunnableWithMessageHistory, and BaseRetriever components backed by DKG v10 Working Memory and Shared Working Memory — gives any LangChain agent persistent, verifiable, queryable memory with full UAL provenance.

Integration links

• Repo: https://github.com/haroldboom/dkg-langchain
• Commit pinned: ad6295e6a9c9d94e75dd63bb215aa892b9630dac
• Published package: langchain-dkg@0.1.1
• Design brief: https://github.com/haroldboom/dkg-langchain/blob/master/DESIGN_BRIEF.md
• Demo (video): https://youtu.be/0XVYrikAZFQ
• Demo (Colab notebook, runs offline against MockDKGClient): https://colab.research.google.com/github/haroldboom/dkg-langchain/blob/master/demo.ipynb

Scope & faithfulness

• Integration uses only the supported public interfaces (HTTP API). It does not import internal DKG packages, patch node source, or write to SPARQL directly (bypassing the assertion lifecycle / Curator).
• memoryLayers correctly reflects which layer(s) the integration touches (WM primary; SWM via explicit promote_to_shared).
• v10PrimitivesUsed correctly reflects which primitives are exercised (UAL, KnowledgeAsset, ContextGraph, Assertion).
• Terminology matches the v10 vocabulary (Context Graph, Assertion, Knowledge Asset, Curator, WM/SWM/VM).

Security declarations (Section 8a)

• security.networkEgress is empty — integration only contacts the local DKG node on localhost:9200.
• security.writeAuthority lists every DKG write operation. The Curator-authority op POST /api/assertion/{name}/promote (SHARE, WM→SWM) is called out explicitly; it is invoked only when the agent explicitly calls promote_to_shared(turn_uri), never automatically.
• security.credentialsHandled is empty — DKG bearer token is read from DKG_TOKEN env var and handled by the operator.
• The published wheel has no preinstall / install / postinstall scripts (Python pip install does not use them; package is plain hatchling-built).
• Build provenance: this release was uploaded with plain twine upload. PyPI Trusted Publishing with attestations: true via pypa/gh-action-pypi-publish will be added before the next patch release.
• The pinned git SHA ad6295e6… is the exact commit on master where this entry's behaviour is verified.

Contributor attestation

• This integration is my own work, MIT-licensed.
• It contains no intentional backdoors, malicious logic, or data-exfiltration paths beyond what is declared in security.networkEgress (which is empty).
• I understand the integration may be delisted for any material misrepresentation in the registry entry.
• I commit to a minimum 6-month maintenance window post-acceptance.

Notes for the committee

Components shipped.

Class	LangChain interface	DKG mapping
DKGChatMessageHistory	BaseChatMessageHistory	One POST /api/memory/turn per turn → one Knowledge Asset in WM
DKGMemory	LCEL RunnableWithMessageHistory wrapper	Convenience binding for chain composition
DKGRetriever	BaseRetriever	Tri-modal search (vector + SPARQL + text) over WM/SWM

Verification. 25/25 unit tests pass against the published wheel (langchain-dkg==0.1.1 installed into a fresh venv outside the source tree). GitHub Actions CI runs the suite on Python 3.10/3.11/3.12 for every push and PR — green at the pinned commit. Verified end-to-end against a live DKG v10 rc.8 node via the offline demo.ipynb (uses MockDKGClient, no node needed to reproduce).

Sister submission. github-dkg — PR #10 is the same author's other Round 1 entry: a GitHub issues / PRs / reviews ingestor for DKG v10 Working Memory. Together they form a write-side / read-side pair — github-dkg writes engineering tacit knowledge into the substrate; langchain-dkg gives any LangChain agent persistent memory backed by it.

Submission tag: cfi-dkgv10-r1.

[haroldboom]

Patch release 0.1.1 published.

While preparing for review I caught and fixed a few bugs in 0.1.0. The integration JSON in this PR is unaffected (no version pin), but anyone installing langchain-dkg via pip will now get the corrected build.

Fixes in v0.1.1:

• DKGRetriever — read SPARQL JSON results under the "results" key (per W3C spec) and extract .value from each binding cell. The previous code silently returned 0 documents against real DKG responses.
• DKGRetriever — escape SPARQL string literals to close a quote/backslash injection vector in the query argument.
• DKGRetriever — sync _get_relevant_documents now works inside Jupyter / async servers (was RuntimeError: This event loop is already running); added the run_manager kwarg required by BaseRetriever; migrated to Pydantic v2 ConfigDict.
• examples/research_agent.py — fixed an AttributeError (get_ual → get_turn_uri).
• DKGMemory — corrected docstring (.wrap → .wrap_chain, layer values wm/swm).

PyPI: https://pypi.org/project/langchain-dkg/0.1.1/
Diff: haroldboom/dkg-langchain@v0.1.0...v0.1.1

All 25 unit tests pass.

[haroldboom]

rc.8 compatibility check + CI

Verified langchain-dkg 0.1.1 against DKG v10-rc.8 (released 2026-05-15) — no client changes needed. The rc.4 → rc.8 release notes touch libp2p relay hardening, MCP agent-chat tools, and Base Sepolia contract redeploys, but leave /api/memory/turn, /api/memory/search, and /api/query (the entire surface this adapter calls) unchanged.

Also added a GitHub Actions workflow that runs the 25 unit tests on Python 3.10 / 3.11 / 3.12 on every push and PR — green: https://github.com/haroldboom/dkg-langchain/actions

Happy to address any reviewer feedback when you get to this one.

[haroldboom]

Contributor Attestation

Restating the registry submission attestations against the pinned commit (ad6295e6) for reviewer convenience:

• Authorship & license. Sole author. MIT-licensed; LICENSE at the pinned commit matches the declared license.
• No backdoors / no exfil. security.networkEgress: []. Verified by inspection of src/langchain_dkg/: every httpx.AsyncClient call resolves to DKGClient.base_url (read from DKG_BASE_URL env var, default http://localhost:9200). No outbound calls to any other host.
• No install hooks. Plain hatchling wheel; PEP 517 build, no native install steps. pip install langchain-dkg==0.1.1 is a read-only filesystem operation.
• Tests verified against the published wheel. pip install langchain-dkg==0.1.1 into a fresh venv outside the source tree; 25/25 unit tests pass. GitHub Actions CI runs the suite on Python 3.10/3.11/3.12 for every push.
• Runtime dependency audit clean. pip-audit against the declared requires of langchain-dkg==0.1.1: no known vulnerabilities.
• Curator-authority discipline. Only POST /api/assertion/{name}/promote (WM→SWM SHARE) is callable, exposed as the explicit promote_to_shared(turn_uri) method — never invoked automatically. No PUBLISH (Verified Memory) calls anywhere in the codebase.
• Maintenance commitment. Minimum 6-month support window post-acceptance.

Two follow-ups planned before the next patch release:

1. PyPI Trusted Publishing via pypa/gh-action-pypi-publish@release/v1 with attestations: true for SLSA build provenance (the unchecked box under Section 8a in the PR description).
2. A "Positioning vs other Round 1 submissions" section in DESIGN_BRIEF.md framing this entry as complementary to the OpenClaw/Hermes-cluster integrations rather than competing.

[haroldboom]

Update — attested release shipped.

langchain-dkg@0.1.2 was published a few minutes ago via PyPI Trusted Publishing (workflow publish.yml) — this checks the open build-provenance box in the PR description.

Per-distribution attestations are fetchable from PyPI's integrity endpoint:

• https://pypi.org/integrity/langchain-dkg/0.1.2/langchain_dkg-0.1.2-py3-none-any.whl/provenance
• https://pypi.org/integrity/langchain-dkg/0.1.2/langchain_dkg-0.1.2.tar.gz/provenance

Both decode to a PEP-740 in-toto Statement v1 signed by the GitHub Actions runner. Signer identity in the bundle:

{"kind": "GitHub", "repository": "haroldboom/dkg-langchain", "workflow": "publish.yml", "environment": "pypi"}

Registry entry bumped: pin → 97ecf2a, install.oneLiner now pins ==0.1.2 so installers grab the attested wheel, security.notes declares the attestation path.

Wheel content is byte-for-byte equivalent to 0.1.1 (the diff is the publish workflow + DESIGN_BRIEF section 10 added in bd7bc94; neither ships in the wheel). All 25/25 unit tests still pass against the new wheel in a fresh venv. Existing 0.1.1 users can ignore this release; the value is the signed, attested distribution path for any future fix release.

This is the sister submission's matching attested release — github-dkg@0.1.1 shipped earlier today through the same path.

[haroldboom]

🔐 Security maintenance release — langchain-dkg v0.1.4

Routine dependency-security pass. Bumped the langchain-core dependency floor from >=0.2.0 to >=1.3.3 so installs can no longer resolve a version affected by CVE-2026-44843 (fixed upstream in langchain-core 0.3.85 / 1.3.3).

• No source or API changes — purely a dependency-constraint hardening.
• 25/25 unit tests green against langchain-core 1.4.7 (latest).
• Published to PyPI via Trusted Publishing with a PEP-740 attestation: langchain-dkg 0.1.4 · provenance at https://pypi.org/integrity/langchain-dkg/0.1.4/langchain_dkg-0.1.4-py3-none-any.whl/provenance.

Registry entry updated on this PR: commit → f84ecf6, install.oneLiner → ==0.1.4, security.notes documents the CVE remediation.

(Sister submission github-dkg #10 was audited in the same pass — its only direct deps are httpx + click, neither affected, so no release was needed there.)

[haroldboom]

Compatibility release — verified against DKG v10 node 10.0.0-rc.17.

Bumped langchain-dkg to v0.1.5 (attested via PyPI Trusted Publishing). The registry pin on add/langchain-dkg now points to commit ba48662 and install.oneLiner → ==0.1.5.

No source or API changes — this is a verification release. I reviewed the rc.2→rc.17 node changelog for every HTTP endpoint the adapter calls (POST /api/context-graph/create, /api/memory/turn, /api/memory/search, /api/assertion/{name}/{write,promote,history}, /api/query); the only request-shape change in that window — rc.12 dropping the deprecated participantIdentityIds/requiredSignatures from context-graph/create — is already non-breaking here, since the client only ever sends {"name": ...}. 25/25 unit tests green. PEP-740 attestation: https://pypi.org/integrity/langchain-dkg/0.1.5/

[haroldboom]

v0.1.6 — verified compatible with DKG v10 node 10.0.0-rc.19

Following the rc.19 testnet release, I re-audited the adapter against the node's daemon HTTP API. No source change required — this is a verification-only compatibility release.

I diffed every daemon route this adapter calls across both hops (rc.17 → rc.18 → rc.19):

Endpoint	rc.17 → rc.19
POST /api/memory/turn	byte-identical
POST /api/memory/search	byte-identical
POST /api/query	byte-identical
GET /api/agents (ping)	byte-identical
POST /api/context-graph/create	additive — now also accepts contextGraphId as an alias for id (#1102), backward-compatible
POST /api/shared-memory/{write,publish}, POST /api/assertion/* (opt-in SHARE)	additive — new optional params + new 503 CURATOR_UNCONFIRMED / 409 CURATOR_REJECTED codes (OT-RFC-49); existing request contracts unchanged

• PyPI: langchain-dkg 0.1.6, published via Trusted Publishing with a PEP-740 attestation.
• Registry pin updated to commit 36046ae; install.oneLiner → ==0.1.6.
• 25/25 unit tests green; CI green on Python 3.10/3.11/3.12.

[haroldboom]

v0.1.7 — bug fix: SHARE-path quad shape

While auditing against rc.19 I found a latent bug in the two opt-in SHARE write helpers and fixed it:

• DKGClient.shared_memory_write was POSTing {"triples": [str, ...]}, but the node reads a quads field — so the request was silently rejected (HTTP 400 Missing "quads").
• DKGClient.assertion_write POSTed {"quads": [str, ...]} — right field, but string elements. The node requires an array of {subject, predicate, object[, graph]} objects, and since node rc.19 it 400s string-shaped quads outright.

Fix: both methods now accept structured quads (a mapping, or a 3-/4-tuple), normalize them to the node's object shape, and POST {"quads": [...]}. Malformed input (raw strings, wrong arity, non-string terms) now fails fast with a clear client-side ValueError instead of an opaque 400.

Core paths (/api/memory/*, /api/query) were unaffected and remain rc.19-verified.

• PyPI: langchain-dkg 0.1.7, Trusted Publishing + PEP-740 attestation.
• Registry pin → commit 0a12230; install.oneLiner → ==0.1.7.
• 5 new unit tests (wire shape, tuple normalization, raw-string regression guard, arity guard, assertion_write); 30/30 green, CI green on Python 3.10/3.11/3.12.

[haroldboom]

v0.1.8 — typed curator-ack errors on SHARE/PUBLISH

Follow-up to the rc.19 work: the node returns 503 CURATOR_UNCONFIRMED / 409 CURATOR_REJECTED on the SHARE/PUBLISH write paths when the Context Graph curator doesn't confirm (or rejects) a write (OT-RFC-49 curator-leader). These previously surfaced as an opaque httpx.HTTPStatusError.

• New exception hierarchy: DKGError → CuratorAckError → CuratorUnconfirmedError (503) / CuratorRejectedError (409), each carrying code, curator_delivery, context_graph_id, and the underlying response. Exported from the package top-level.

• shared_memory_write, shared_memory_publish, assertion_write, and assertion_promote now raise the typed errors; a generic 503/409 without the curator code still falls through to raise_for_status(), so unrelated outages aren't mislabelled.

• PyPI: langchain-dkg 0.1.8, Trusted Publishing + PEP-740 attestation.

• Registry pin → commit e0fb1e7; install.oneLiner → ==0.1.8.

• 4 new unit tests (503→Unconfirmed, 409→Rejected, promote mapping, generic-503 passthrough); 34/34 green, CI green on Python 3.10/3.11/3.12.