Repository navigation
RFC-0003: Provenance typing — claimClass, assertedBy, mergedFrom (format 1.2) #14
Description
Summary
Provenance today answers what justifies this (episodeID, evidenceEpisodeIDs, confidence, supersededBy, the audit log) but not how a memory came to be — asserted by a person, observed by the system, inferred by a model, merged from earlier records, imported through an adapter — nor who asserted it. Those are the cuts an accuracy or erasure review asks for first ("show me every inferred claim about this person"), and sources carry them (the Engram spec's claim_class / attribution; conversation roles) while our adapters keep them only as opaque vendor metadata.
Proposal (short form — full text in Spec/rfcs/0003-provenance-typing.md)
Three optional fields on episode, fact, edge, entity:
claimClass:asserted | observed | inferred | merged | imported(open enumeration; unknown values preserved).assertedBy: one principal in RFC-0001's<type>:<id>syntax —user:…,agent:…,model:gpt-5@2026-06.mergedFrom: ids of records consolidated into this one (withclaimClass: merged); merged-away records are superseded, not deleted.
Evidence Pack rows carryclaimClass+assertedBy. Aligns with W3C PROV (wasAttributedTo,wasDerivedFrom) without carrying a graph.
Input wanted
- Five classes — right granularity? (Engram keeps
documentedvsasserted; this collapses them.) assertedBysingular vs list.- Should
episodecarryclaimClassat all, or issourceTypealready that? (Proposed: both — channel vs epistemic status.) - Model identifier convention:
model:<name>@<version>?
Relationship: depends on RFC-0002 for lossless carriage on non-episode kinds; bundled into format 1.2.0 with RFC-0001 (#11). Comment period to 2026-10-05.
Activity
docs(spec): RFC-0002 ext for all kinds, RFC-0003 provenance typing; p…
docs(spec): RFC-0002 ext for all kinds, RFC-0003 provenance typing; p…
Krivoblotsky commentedon Sep 14, 2026
RFC text: #12 (Python repo) · MacPaw/portable-memory-swift#13 (Swift repo — same bytes).
wmdubberley commentedon Sep 18, 2026
On input question 1 (five classes — right granularity?): the granularity looks right, but there is an axis the enumeration cannot express at any granularity.
The five values type how a claim was obtained. They do not type when it was obtained relative to now, and for records consumed by systems reasoning about live state that distinction changes what the claim means.
A case. A monitoring agent records "service X is running" with
claimClass: observed. It was observed — the check ran and returned true. Five hours later a consumer reads that record. The class is still accurate, and the service has been down for three of those hours. A record written this second, alsoclaimClass: observed, is indistinguishable from it.Both claims are correctly typed. They are not the same knowledge, and they should not drive the same decision.
This cannot be fixed by adding a sixth class. Age is orthogonal to how a claim was obtained: an
inferredclaim can be hours old, anassertedone years old, and a sixth value would force a producer to choose between saying how it knew and saying when. That is two axes in one enumeration.Proposal: an optional
asOftimestamp on the claim, recording when the evidence underlying it was obtained — distinct from the record's own write time, which may be much later formergedorimportedclaims.Deliberately not proposing a
staleflag. Staleness is a judgement against a tolerance, and tolerances differ by claim: a process list is stale in seconds, an installed-package inventory in weeks. Encoding the judgement fixes a threshold the producer cannot know. The timestamp is the fact; staleness is the consumer's inference from it — which is itself a derived claim, and arguably wants its ownclaimClasswhen recorded.If age is considered out of scope for a format describing memory at rest, that is a reasonable line. The case for including it is that these records are read by systems acting on live state, and at that point a claim's age is load-bearing in a way its provenance alone cannot express.