Runtime Upgrade Safety
Data written in v0.2.12 reads correctly in v0.2.16.
Memory systems are only useful if they can be trusted over time. An agent writes a fact on Monday running v0.2.12. The system is upgraded Wednesday. The agent reads that fact on Friday running v0.2.16. Is it still there? B13 tests exactly this: three incremental version upgrades, 5 cross-version probes, and a running research program as the most honest form of evidence.
Results at a glance
What this measures
Every persistent system faces the upgrade problem. When storage formats, schema layouts, or serialization approaches change between versions, previously written data can become unreadable. For a memory infrastructure layer, this is a critical failure mode: agents accumulate knowledge over time and that knowledge must survive whatever version the operator chooses to run.
B13 tests upgrade safety across three incremental versions of Iranti: 0.2.12, 0.2.14, and 0.2.16. Data written in the earliest version is probed in the latest. Post-upgrade write capability is confirmed immediately after each upgrade. A conflict state created during the benchmark program is checked for integrity.
Beyond the targeted probe, the benchmark program itself is evidence: 11 benchmark tracks ran across all three versions, and agents naturally read data from earlier versions throughout. No upgrade ever caused a read failure during that program.
How we tested it
Two complementary approaches were used, each with a different signal quality.
5 specific entity-key pairs were written in v0.2.12 and then explicitly queried in v0.2.16 after both intermediate upgrades completed. 4 of 5 returned correctly. The 1 miss was a probe design error — the query used a slightly different key name than what was written. The entity was present and readable with the correct key.
More compelling than any synthetic probe: 11 benchmark tracks ran across all three versions. B6 was re-run in v0.2.14 and v0.2.16 reading entities first written in v0.2.12. B9 did the same. No upgrade caused a read failure. The absence of failures across a real research program running over weeks is the strongest possible evidence.
Version timeline
Data written at v0.2.12 flows intact through two incremental upgrades and remains readable at v0.2.16. Each upgrade step is a full version promotion, not a patch.
Test results
Four upgrade safety properties measured across the v0.2.12 → v0.2.16 upgrade path.
| Test | Result | Note | Pass |
|---|---|---|---|
| v0.2.12 facts in v0.2.16 | 4/5 reads correct | 1 miss = probe used wrong key name | |
| Post-upgrade writes | 3/3 | Immediate, no warmup period | |
| Conflict state | Preserved | Not resolved or altered by upgrade | |
| API surface | Stable | iranti_handshake returns same structure |
The 4/5 cross-version read score reflects a probe design error, not a storage failure. The entity with the missed key was confirmed readable once the correct key was used.
The program as the strongest evidence
We built a research program on top of Iranti across 3 versions. Nothing broke. That is more meaningful than any synthetic test designed to pass.
- →B6 re-run in v0.2.14: read entities originally written in v0.2.12. All reads succeeded.
- →B6 re-run in v0.2.16: same v0.2.12 entities, two upgrades later. All reads succeeded.
- →B9 re-run in v0.2.16: queried v0.2.12 entities for temporal consistency validation. No data loss detected.
- →11 tracks across 3 versions: zero upgrade-related read failures recorded in the entire benchmark program log.
A synthetic probe can be designed to pass. A real research program running continuously across upgrades cannot. The absence of failures here is the kind of evidence operators should care about.
What this means in practice
Agents that wrote facts in an earlier version will find those facts intact after upgrading. No migration step is required.
Post-upgrade write capability is confirmed within the same session. There is no warmup period before the system accepts new facts.
The contested entity created during the benchmark program remained in its exact conflict state through all three versions. Upgrades do not resolve or alter contested knowledge.
The iranti_handshake tool returns the same structure in v0.2.16 as in v0.2.12. Agents do not need to adapt their tool calls across versions.
Honest limitations
Key findings
iranti_handshake tool returns the same structure in v0.2.16 as in v0.2.12. Agents do not need to change their tool usage patterns across minor version upgrades.Full trial execution records, upgrade logs, probe results, and methodology notes in the benchmarking repository.