Supporting technical evidence

When enterprise memory changes, the right state should still govern the next answer.

LLMs can reread history. FieldHash remembers what currently governs. It maintains the current governed state directly — materialized, not re-derived at every read — so memory stays reliable across update, rejection, drift repair, rollback, compaction, and repeated reads.

Governed lifecycle reads

2400/2400

normal stateful reads across 200 projects

Rollback restored state

200/200

post-update state reverted

Drift detected + repaired

200/200

deliberate state corruption surfaced and recovered

Compaction retained state

200/200

protected state survived compaction

Production risk avoided

A vendor decision, contract rule, policy exception, or API migration can be approved, superseded, rolled back, and repaired over time. The operational failure is not that the archive forgets; it is that the agent keeps using the wrong version after the business decision changed.

Rollback

A reverted decision becomes current again instead of being buried by later notes.

Repair

Corrupted state is detected before the answer path treats it as authoritative.

Compaction

Protected state survives cleanup instead of being compressed away.

Repeated reads

The same governed state keeps governing after the first successful answer.

The tested distinction

A selector can choose today's best-looking record. Governed memory has to remember what happened.

The lifecycle harness mutates a persisted project store across 13 phases: initial prior, first promotion, stale re-entry, rejected option, scope collision, drift injection, drift repair, second promotion, rollback to the first update, reapply second update, compaction, post-compaction stale re-entry, and repeated read.

The stateless selectors below see only the record text at each read — not the operation log. That isolates the operational distinction: FieldHash materializes the current state once and reads it directly; the selectors have to reconstruct authority from bounded history each time.

Rollback is state, not prose. The rollback lives in the operation log, not in the visible text of the later record — which is why selectors reading text alone kept choosing the rolled-back update 200/200 times.

What happened at n=200

FieldHash governed state

2400/2400 normal lifecycle reads correct.

Gemini Flash Lite stateless selector

2200/2400 normal reads correct; all 200 misses were rollback.

GPT-5.5 stateless selector

2200/2400 normal reads correct; all 200 misses were rollback.

Rollback failure mode

Both stateless selectors kept choosing the later second update after rollback.

Boundary condition: when a baseline is given the full operation log, it can replay the lifecycle too. The measured distinction here is durable materialized state versus bounded read-time reconstruction.

Lifecycle arc

What the pillar proves.

The narrow claim is not better one-shot reading. The claim is durable governed state that survives the messy operations real memory systems need.

Persist

State survives the next read.

Each phase reloads the store written by the previous phase, so the benchmark is not a stack of independent fixtures.

Rollback

The earlier approved state can become current again.

FieldHash reverted correctly 200/200 times. Stateless selectors shown only record text missed this phase 200/200 by continuing to choose the later update.

Repair

Bad state is visible before it is fixed.

The harness deliberately corrupts state, verifies the wrong answer path becomes visible, detects it, then repairs it 200/200.

Compact

Compression does not erase protected state.

Protected current state remained available through compaction and post-compaction stale re-entry in 200/200 cases.

What this supports

Governed state is durable, not just semantic.

A read-time LLM selector can be excellent at choosing the current-looking record. This diagnostic isolates the stateful part: when governance changes which memory has authority, future reads should not have to rediscover that decision from scratch.

That is the practical carry-forward claim for Governed Memory: no base-model retraining, but future behavior changes because governed memory state changed and stayed changed.

Reviewer boundaries

How to read the result.

This is an internal diagnostic on a FieldHash-authored corpus. Authority metadata is written by governed operations, so the result should be read as lifecycle-state enforcement, not authority inference from raw text. It is not external validation, base-model weight learning, or a broad model-superiority claim. The next competitive proof bar is a stateful memory-framework comparison using each framework's own update and rollback mechanisms.

In a robustness control, when rollback was added as visible retrievable text, GPT-5.5 recovered the restored value 30/30. The main result therefore isolates rollback represented as durable governed state, not visible rollback instructions.

A separate full-operation-log control ties the lifecycle, so this page does not claim model superiority. The supported Governed Memory claim is architectural: materialized governed state remains stable under update, rollback, repair, compaction, and repeated reads, while bounded read-time reconstruction has to recover that state from history every time.

Continue with the full governed loop.

This lifecycle pillar shows governed state surviving change over time. The loop synthesis connects that durability to promotion, enforcement, and audit evidence.