Content hash freshness + KU schema: potential interop with IETF draft

[tomjwxf]

Hi - the knowledge-engine's dual-layer architecture (wiki + Memvid) with content hashing and drift detection maps closely to patterns formalized in the IETF Knowledge Unit draft. Wanted to point out the specific overlaps in case interoperability is interesting.

Content hashing and source provenance

Your Bridge layer uses content hashes to keep wiki and Memvid layers synchronized, flagging drift before inconsistencies compound. The KU draft's source provenance section (Section 3.4) standardizes exactly this pattern:

{
  "sources": [
    {
      "uri": "file:///docs/architecture.pdf",
      "retrieved_at": "2026-04-01T10:00:00Z",
      "content_hash": "sha256:a1b2c3..."
    }
  ]
}

Every KU carries the content_hash of its source material, so downstream consumers can detect when the underlying document has changed - the same drift detection your Bridge performs, but standardized across systems.

Layer mapping

Your two-layer design (human-readable wiki + machine-searchable Memvid) maps to the KU draft's disclosure levels:

knowledge-engine layer	KU disclosure level
Wiki page (curated, structured)	L0 (assertion) - L1 (sourced claim)
Memvid Smart Frame (raw, comprehensive)	L2 (deliberation trace) - L3 (full provenance)
Source attribution in search results	Source provenance array (Section 3.4)

The .mv2 files with their append-only, immutable Smart Frames are a natural fit for L3 (full deliberation) storage - they already carry timestamps and checksums.

Freshness as a first-class property

Your system queries wiki first, then falls back to Memvid, merging results with source attribution. The KU schema makes freshness explicit through retrieved_at timestamps and content_hash fields on every source, so a consumer can programmatically decide whether a knowledge unit needs re-ingestion.

What this could look like

Your wiki markdown pages could carry KU-compatible frontmatter:

---
title: "Deployment Architecture"
ku_version: "draft-04"
canonical_question: "How is the production system deployed?"
sources:
  - uri: "file:///docs/deploy-guide.pdf"
    content_hash: "sha256:abc..."
    retrieved_at: "2026-04-01T10:00:00Z"
confidence: 0.88
---

This would let other KU-compatible systems consume your wiki output without needing access to the Memvid layer.

Links

• IETF draft
• Spec page
• Live wiki
• Verify any KU: npx @veritasacta/verify

Happy to discuss how these could work together.

[tashisleepy]

Thanks TJF. Interesting alignment. The content-hash drift detection does map to what Section 3.4 of your draft standardizes.

Position for now: watching the IETF draft as it progresses. Not committing to schema adoption yet since the draft is early and changes would cascade through every wiki page frontmatter in the field. Happy to revisit if the draft stabilizes or reaches WG adoption.

One small note: the npx @veritasacta/verify tooling and acta.today references read as a single-vendor ecosystem rather than a neutral standard. Worth separating the spec proposal from the tooling pitch in your outreach, since maintainers tend to evaluate those differently.

Will keep the issue open as a tracker.

[tomjwxf]

Thanks @tashisleepy, the single-vendor feedback is fair and well taken, and worth addressing directly.

The IETF draft itself is vendor-neutral by design (JCS, Ed25519, signature-agnostic, no proprietary anchoring), but the point about the outreach reading as a single-vendor pitch is accurate. A more honest picture of what exists today:

• protect-mcp (tooling I built): hook into Claude Code / MCP.
• asqav / APS governance hook (aeoess, independent team): parallel implementation, same receipt format, cross-verified in crewAI#5283.
• sb-runtime (separate crate): OS-level sandbox, emits receipts in the same format.
• protect-mcp-adk (Python, for Google ADK): third implementation, merged via adk-python#5164.

Four implementations from two independent teams, producing mutually verifiable receipts against the shared IETF format. Not a full multi-vendor ecosystem yet, but not single-vendor either. The test of a real standard is that someone else can implement it from the draft alone and have their receipts verify, which is what is happening here.

Leaving the issue as a tracker is reasonable. If the draft reaches WG adoption I will loop back. Appreciate the candid read, it sharpened how this should be framed elsewhere.