Proposition Revision Management and Auditing

[igordayen]

DICE Revision Memory: Short Concept Proposal

The Core Example

Assume DICE has three propositions after the first memory change:

Commit C1
    P1 -> R1
    P2 -> R2
    P3 -> R3

Meaning:

P1 has revision R1
P2 has revision R2
P3 has revision R3

Later, DICE changes P2 and adds P4:

Commit C2
    P2 -> R4
    P4 -> R5

Now the full memory state after C2 is:

P1 -> R1
P2 -> R4
P3 -> R3
P4 -> R5

Commit C2 is only what changed.
Memory view after C2 is the full state after the change.

So the audit delta from C1 to C2 is:

P2 changed: R2 -> R4
P4 added:   none -> R5

What DICE Already Has

DICE already has a proposition-first memory model.

It has:

• propositions as the main memory facts
• context ids to scope memory
• confidence
• decay
• importance
• created and revised timestamps
• access timestamps
• lifecycle status such as active, stale, superseded, contradicted
• temporal metadata such as valid-from, valid-to, invalidation, supersession, contradiction
• grounding and provenance
• collector audit records
• projection lineage records

These concepts provide the base for temporal memory.

But it mostly represents the current proposition state plus timestamps and lineage around some operations.

What Is Missing

The missing concept is:

historical versions of propositions

If proposition P2 changes from R2 to R4, DICE needs to retain both:

P2/R2 was current before C2
P2/R4 became current at C2

Without that, DICE cannot reliably answer:

What did memory look like after C1?

because the old version may have been overwritten.

Proposed Concepts

Proposition

The logical memory fact.

Example:

P2

This is the stable identity of the memory fact.

Proposition Revision

One historical version of a proposition.

Example:

P2/R2
P2/R4

P2 is the same logical proposition.

R2 and R4 are different versions of it.

Memory Commit

One logical change to memory.

Example:

Commit C2
    P2 -> R4
    P4 -> R5

A commit is not the whole memory.

A commit is only what changed together.

Memory View at Commit

The full memory state after a commit.

Example:

Memory after C2
    P1 -> R1
    P2 -> R4
    P3 -> R3
    P4 -> R5

This is what lets DICE answer:

What did memory look like after commit C2?

Memory Delta

The difference between two memory views.

Example:

C1 -> C2
    P2: R2 -> R4
    P4: none -> R5

The delta says what changed.

The collector, projection, ingestion, or agent audit explains why it changed.

What About Time?

Commit is the primary coordinate.

Use:

memory after C2

not primarily:

memory at 11:03:12.534

Time lookup resolves to a commit:

memory at time T
    means
latest commit at or before T

This avoids ambiguity around clocks, concurrent writes, and transaction boundaries.

What About Snapshots?

There are two different concepts:

Historical Memory View

This is the full memory state after a commit:

P1/R1
P2/R4
P3/R3
P4/R5

This is built from proposition revisions.

Memory Use Record

This records which proposition revisions were supplied to a reasoning step.

Example:

Agent step S selected:
    rank 1: P2/R4
    rank 2: P4/R5
    rank 3: P1/R1

rank means position in the returned retrieval result.

For example, rank 1 is the first proposition revision supplied to the reasoning step, rank 2 is the second, and so on. Rank preserves retrieval order for replay and audit. It does not mean confidence rank globally across all memory.

Replay has two levels:

Memory replay
    DICE reconstructs memory from proposition revisions.

Execution replay
    Embabel Agent reconstructs the execution using its own prompt, model, tool, and output audit.

DICE is responsible for memory replay, not full execution replay.

For memory replay, DICE can answer:

What was the full memory after commit C2?
    -> return P1/R1, P2/R4, P3/R3, P4/R5

What memory did reasoning step S receive?
    -> read Memory Use Record for S
    -> return rank 1 P2/R4, rank 2 P4/R5, rank 3 P1/R1

That output can then be used by the Embabel Agent audit layer to reconstruct the surrounding execution context.

The result is audit replay, not guaranteed deterministic re-execution of an LLM. To re-run the same LLM call deterministically, the framework would also need the original prompt, model/options, tool responses, and output record.

Proposition revisions and commits come first.

Responsibility Split

DICE Should Own

DICE owns memory history:

• proposition revisions
• memory commits
• memory views at commit
• memory deltas
• memory use records when DICE supplies memory to a reasoning step

DICE answers:

What revision of each proposition was current after C2?
What changed between C1 and C2?
Which revision did the agent actually use?

Embabel Agent Framework Layer

DICE uses Embabel Agent as the agent execution, LLM, and tool framework.

Execution history belongs at that framework layer rather than inside the DICE proposition store:

• agent execution id
• action or step lifecycle
• LLM calls
• tool calls
• prompts
• model options
• action outputs
• failures

DICE memory operations can attach DICE-owned identifiers to the surrounding Embabel Agent execution context:

context id
commit id
memory use record id

`

Application Should Own

The application owns business context:

• conversation id
• case id
• user id
• tenant id
• approval events
• submitted reports

Recommended Order

Build in this order:

1. Add proposition revisions.
2. Group revisions into memory commits.
3. Reconstruct memory view at commit.
4. Compute deltas between commits.
5. Add memory use records for execution replay.

Do not start with memory use records.

They depend on the revision/commit model.

Final Concept

The proposed DICE memory history model is:

Proposition
    stable memory fact id

Proposition Revision
    historical version of that fact

Memory Commit
    set of revisions created by one memory change

Memory View at Commit
    full memory state after that commit

Memory Delta
    revision transitions between two commits

Memory Use Record
    optional record of which proposition revisions were supplied to a reasoning step

Audit example:

C1:
    P1 -> R1
    P2 -> R2
    P3 -> R3

C2:
    P2 -> R4
    P4 -> R5

Memory after C2:
    P1 -> R1
    P2 -> R4
    P3 -> R3
    P4 -> R5

Delta C1 -> C2:
    P2: R2 -> R4
    P4: none -> R5

Audit at Framework level

Considering employing observability for implementing an audit at the framework level, such as
changes in object state between actions.

Disclaimer: employ codex for brainstorming

[hornosj]

Thanks for writing this up. I'd been circling the same question from the outside, whether DICE could answer "what did memory look like at T", and having the concepts named and ordered made it much easier to work through.

I ended up implementing all six against DICE as an external observer: a DiceEventListener plus a wrapper over PropositionRepository, without changing DICE itself. Five of the six came out of what DICE already emits. Two gave me trouble, and I thought the details might be useful here.

Where does a commit boundary come from?

Step 2, group revisions into memory commits, is the one I couldn't work out from the outside. As far as I can tell there isn't anything in the event stream to group by:

• interface DiceEvent : Timestamped, so every event knows when it happened but not which run produced it.
• The closest thing to a boundary signal is ExtractionBatchCompleted, but it carries stats and a timestamp, so it says a batch ended without saying which one.
• And it fires before the writes it relates to. PropositionPipeline doesn't persist anything ("this method does NOT persist anything… the caller must persist via PersistablePropositions.persist within its own transaction scope"), so the durable PropositionPersisted events arrive after process() has already returned.

That leaves an observer with one shared "current batch" holder, rotated whenever a marker shows up. It works while ingestion is sequential and stops working as soon as it isn't.

I ran it to see how bad it gets: 8 concurrent ingestion runs, 6 facts each, ground truth known, repeated 5 times. Inference recovered between 2 and 6 of the 8 boundaries depending on scheduling, and in each of the 5 runs one commit ended up holding facts from all eight.

It's quite possible I'm missing a path here. If there's a way to recover the grouping that I overlooked, I'd like to know.

persist() might already be the boundary

If it isn't recoverable from the events, the next question is where it would naturally live. PersistablePropositions.persist() looks like a good candidate: one call, one set of propositions written together, which is close to how you define a commit.

The pattern also seems established in the codebase. CollectorRun groups many CollectorRecords under a shared runId with startedAt/finishedAt, and GraphProjectionService mints one per projection run. Extraction/persistence looks like the one write path without something equivalent.

I tried the smallest version I could think of: a reentrant, thread-bound commit scope opened by persist(), which a listener reads inside onEvent (this works because listeners run inline on the emitting thread). The same measurement came out at 8 commits with none mixed, across all 5 runs. It's one new file plus a wrap in persist(), with no public signatures changed, no changes to any event, and the module's 1193 tests still passing.

Making it reentrant seemed worth it for the responsibility split you describe: a caller can open a wider scope with an id it owns, a case id or a conversation id, around extraction and persistence, and persist() joins that instead of splitting it in two.

On naming I'd defer to you. I used the proposal's vocabulary (MemoryCommit), though runICollectorRun already establishes.

Memory Use Record was the one I couldn't reach cleanly

All 16 DiceEvent types look write-side to me, and I couldn't find anything emitted on retrieval, so a DiceEventListener never sees what a query returned, which is the substance of a Memory Use Record.

I fell back on a dynamic proxy around PropositionRepository, recording what came back in interfaces, so implementing it by hand wasn't practical). It works, but it's aworkaround, and one a consumer shouldn't have to build.

With a retrieval-side event this becomes ordinary listener work, and DICE could record its own memory use instead of depending on someone wrapping the repository.

Commit over clock, under a 30-second skew

I moved a single event's timestamp 30 seconds backwards, roughly what an NTP correction or a second writer on another node would do, and changed nothing else. Timestamp-ordered lookup returned the wrong
answer. Commit-ordered lookup returned the right one.

What none of this touches

The thing you identify as the missing concept, historical versions of propositions, isn't addressed by any of the above. save still replaces by id (propositions[proposition.id] = proposition), so the previous revision is gone. Deriving revisions from an event log works well enough for an outside observer, but keeping them inside DICE is a storage-model question (retention, GC, indexing) and a much bigger one than either item above.

Two smaller things I wasn't sure about

Both came up while building, and I suspect they're undecided rather than wrong:
x

• Revert. With content-addressed revisions, a fact that returns to an earlier state comes back with the same revision id. A model that stores revisions as entities would mint a third id and then need another way to express "this is the same belief as R1". Curious which behaviour you'd want.
• removed in a delta. DICE never deletes, and a status change (ACTIVE → CONTRADICTED) reads as a changed rather than a removal, since status is part of the revision. In practice removed stayed empty throughout. Is there a case it's meant to cover?

---

The listener and the experiments are at https://github.com/hornosj/dice-chronicle if any of it is useful. The commit-scope patch is a small branch against main. Happy to open a PR, or to leave it as input if you'd rather shape it differently.

---

[igordayen]

@hornosj - Thank you very much for evaluating the idea!

Proposition com.embabel.dice.proposition.Proposition may need to be enhanced with revisionId / version (like in Hibernate).

• Revert. With content-addressed revisions, a fact that returns to an earlier state comes back with the same revision id. A model that stores revisions as entities would mint a third id and then need another way to express "this is the same belief as R1". Curious which behaviour you'd want. ==> should employ revisionId
• removed in a delta. DICE never deletes, and a status change (ACTIVE → CONTRADICTED) reads as a changed rather than a removal, since status is part of the revision. In practice removed stayed empty throughout. Is there a case it's meant to cover? ==> changes in Proposition as data structure itself

Looping James @jimador

Thanks.