Per-item schema comparison: world-model-mcp (v0.9.1) and piia-engram

[SaravananJaichandar]

This Discussion captures a side-by-side comparison between two shipped MCP memory implementations: world-model-mcp (v0.9.1) and piia-engram. The dimensions are the ones @Patdolitse named in anthropics/claude-code#47023: per-item fields, provenance semantics, confirmation state, pending/settled lifecycle, and what each system refuses to infer.

The world-model-mcp column is populated from the v0.9.1 shipped schema (committed source). The piia-engram column was initially populated from the public README at https://github.com/Patdolitse/piia-engram and from @Patdolitse's public comments on anthropics/claude-code#47023 and safal207/LS#651. Canonical Engram-authored source of record: Patdolitse/piia-engram discussion #38 — read the piia-engram column below alongside that doc.

This Discussion covers shipped artifacts only. Roadmap items, in-progress design, and unreleased schema changes for either project are out of scope and should be raised in the project's own repo issues.

---

1. Per-item fields

world-model-mcp (v0.9.1):

• id: UUID
• subject, predicate, object: the triple
• confidence: float in [0, 1]
• asserted_by: tool or agent identifier that wrote the fact
• confirmer: tool or agent identifier that confirmed the fact (NULL if unconfirmed)
• confirmation_state: enum — synthesized, corroborated, settled, canonical, superseded
• evidence_type: enum — source_code, test, session, user_correction, bug_fix
• valid_at, invalid_at: timestamp range
• last_decay_at: timestamp of last decay computation
• source_tool: tool that observed the fact (distinct from asserted_by in the multi-tool case)

piia-engram (from public README + Patdolitse comments):

• source_tool / source_agent: tool or agent that asserted (e.g. claude_code, codex — tool/agent level, not model/version)
• last_validated_at: timestamp set when an item is confirmed via typed signal
• Tier: staging → verified (the pending → settled axis)
• Typed confirmation signal: confirm-by-test, confirm-by-human, confirm-by-anchor

For the source-of-record piia-engram schema, see Patdolitse/piia-engram discussion #38.

---

2. Provenance semantics

world-model-mcp:

• Asserter and confirmer are distinct fields. A fact can be asserted by one agent (e.g. claude_code) and confirmed by another (e.g. a test ToolResult or user_correction).
• Confidence is a float that decays over time per evidence_type.
• A new assertion from the same source_tool does NOT count as independent corroboration; corroboration requires a distinct source_tool.

piia-engram:

• Source is at the tool/agent level (e.g. claude_code, codex), not model/version level.
• For confirmer-vs-asserter handling and confidence semantics, see the canonical Engram-authored source at Patdolitse/piia-engram discussion #38.

---

3. Confirmation state

world-model-mcp:

Enum with 5 states:

• synthesized: model proposal, not yet confirmed
• corroborated: confirmed by an independent source_tool (counts as evidence but not settled)
• settled: confirmed via a typed ToolResult (test, bug_fix, or user_correction)
• canonical: settled AND asserter differs from confirmer
• superseded: previously corroborated/settled, now invalidated by later evidence

Transitions are event-driven (a ToolResult event flips state) and threshold-driven (decayed confidence below 0.10 demotes corroborated; below 0.20 demotes synthesized).

piia-engram:

• Two-tier: staging → verified
• Staging items do not auto-promote to verified (per @Patdolitse, 2026-06-25).
• For full transition rules, see Patdolitse/piia-engram discussion #38.

---

4. Pending/settled lifecycle

world-model-mcp:

• A fact is created in state synthesized (or corroborated if a confirming source_tool already exists)
• A ToolResult event with matching subject/predicate flips state to settled
• Conflicting evidence with higher confidence transitions the older fact to superseded
• Per-evidence-type half-lives: test 180d, bug_fix 365d, user_correction 730d, source_code 365d, session 14d
• A fact below the confidence threshold for its state demotes to a lower state

piia-engram:

• last_validated_at stamp set on the typed confirmation signal
• For expiry / decay behavior on verified items, see Patdolitse/piia-engram discussion #38.

---

5. What each system refuses to infer

world-model-mcp:

• Refuses to treat repeated assertion by the same source_tool as independent corroboration (requires distinct source_tool)
• Refuses to authorize execution from a fact in synthesized state at PreToolUse (defers instead, per the v0.7.0 defer enforcement tier)
• Refuses to silently overwrite a canonical fact on conflict (creates a new fact + supersedes the older one)
• Refuses to infer evidence_type from the asserting agent alone (must come from the ToolResult event)

piia-engram (per @Patdolitse, 2026-06-25; canonical source Patdolitse/piia-engram #38):

When opt-in governance is enabled:

• Memory informs context but does not by itself authorize action, export, publication, overwrite, or promotion
• Staging items do not auto-promote to verified
• High-impact writes and owner-level exports are gated
• Governance gates fail closed
• Context-governance preview modes are proposal-only

---

@Patdolitse — please correct, extend, or replace any of the piia-engram entries above. The canonical Engram-authored source of record is at Patdolitse/piia-engram discussion #38; the entries here are pointers to that doc plus highlights from the public comments.

[rpelevin]

This comparison is useful because it stays at the shipped-artifact level instead of turning into a standards claim too early.

One axis I would add is what each row is allowed to prove.

For a memory item, the fields are only half the contract. The other half is the runtime boundary:

1. Assertion boundary: which agent or tool wrote the item, and whether that source can independently confirm it.
2. Confirmation boundary: which typed event moved it from pending to settled, and whether the confirming source is distinct from the asserting source.
3. Validity boundary: which workspace, trajectory, continuation, and time window the item is valid for.
4. Influence boundary: whether the item may inform context, produce a warning, force a defer or stop, or merely appear in audit.
5. Authority boundary: whether the item can ever authorize a downstream action by itself.

The negative rows are where the comparison becomes portable:

1. The same tool asserts the same item twice; this should not count as independent corroboration.
2. A pending item is retrieved during resume; it can appear in context, but cannot silently become a verified fact.
3. A confirmed item is valid for a different trajectory or stale continuation; it should remain auditable but non-binding.
4. A low-confidence item has an explicit typed confirmation event; policy may still bind on the confirmation source rather than retrieval confidence.
5. A memory write from the current run is later read back by the same run; it should not self-authorize a dependent claim or tool call.
6. A verified item conflicts with newer repository or test evidence; the comparison should show whether the older item is superseded, demoted, or preserved as historical context.

That keeps the table from becoming only a schema comparison. It becomes a comparison of safety semantics: what the memory layer records, what it proves, what it may influence, and what it refuses to authorize.

Boundary: architecture and test feedback only; no claim about using world-model-mcp or piia-engram, validating either implementation, proposing a standard, or representing any project.

[Patdolitse]

Thanks for putting this together. I'll keep a canonical Engram-authored note in the Engram repo and link it here as the stable source of record. That keeps Engram's semantics anchored to Engram's public docs instead of compressing them into a comparison row.

One correction to the current table: Engram's refusal / authority semantics should not be treated as blank. When Engram's opt-in governance layer is enabled, memory can inform context but does not by itself authorize action, export, publication, overwrite, or promotion. Staging items do not auto-promote to verified; high-impact writes and owner-level exports are gated; governance gates fail closed; context-governance preview modes are proposal-only.

A framing note worth keeping explicit: world-model-mcp and Engram aren't quite the same layer — world-model-mcp uses memory in a codebase / PreToolUse enforcement path, while Engram is a user-owned identity and knowledge layer where memory is context and proposal, not execution authority.

Canonical Engram-authored note: Patdolitse/piia-engram#38

[SaravananJaichandar]

@Patdolitse Thanks for the canonical doc link. Have updated Section 5 (refusal/authority) of the comparison table to reflect: when opt-in governance is enabled, memory informs context but does not by itself authorize action, export, publication, overwrite, or promotion; staging items do not auto-promote to verified; high-impact writes and owner-level exports are gated; governance gates fail closed; context-governance preview modes are proposal-only. Have also updated the source-of-record pointers in Sections 1 through 4 to direct readers to Patdolitse/piia-engram#38 for the piia-engram column.

One framing note on the layer distinction. world-model-mcp does sit in a PreToolUse enforcement path via the defer tier, but the enforcement path is one downstream consumer of a broader temporal knowledge graph that also covers cross-session learning, codebase-identity facts (entities, relationships, asserted_by / confirmer provenance), and per-evidence-type decay. The PreToolUse defer is the runtime-governance leg; the rest of the graph operates independently as context, just as Engram does. The two projects do sit at different ends of "user-owned identity" vs "codebase-grounded knowledge" but the overlap in the middle (provenance schema, confirmation lifecycle, decay semantics) is where the comparison stays useful.

[Patdolitse]

Thanks for the updates and the canonical pointers. Agreed that world-model-mcp is broader than just the PreToolUse defer path, and that the provenance / confirmation-lifecycle / decay overlap is useful to compare.

The distinction I'd preserve is that this isn't a narrow-vs-broad hierarchy: world-model-mcp is centered on codebase / agent-grounded knowledge and task governance; Engram is centered on the human owner's cross-tool identity and memory authority. The overlap is real, but it isn't a subsumption relationship — different primary object, not different size.

That framing works for me, and the canonical note will stay the source of record for the Engram column.