Your agent transcript is already an event log

A write never updates a value in place. It appends HypothesisScored{confidence: 0.86} to a stream, and the current confidence is whatever the fold over that stream returns. Every read model derives from the log, which makes it disposable and rebuildable. If a projection has a bug, fix the fold and replay instead of migrating corrupted rows.

A stream is a session. An event is a custom entry whose custom_type names the event type. That field is a real discriminator slot, not a type you smuggle into the payload. Ordering is an explicit parent_id chain, and the engine returns it on every append. So the log is a linked list rather than a timestamp-sorted bag.

iii trigger session::append session_id=$SID \
  message='{"role":"custom",
            "custom_type":"ClaimRecorded",
            "content":[{"type":"text","text":"{\"claim\":\"one consumer attached\"}"}],
            "timestamp":1717800000000}'

{ "entry_id": "e_45d958d6…", "parent_id": "e_5e3d1086…", "timestamp": … }

session::append has no conditional write. Pass expected_revision and the engine accepts the parameter, ignores it, and appends anyway. No error tells you that your concurrency control does nothing:

$ iii trigger session::append session_id=$SID expected_revision=3 message=…
{"entry_id": "e_399c8b87…", "parent_id": "e_20ec1d48…"}   ← appended regardless

parent_id, meanwhile, is real, and the engine does validate it: an unknown parent returns session/parent_not_found. So it looks exactly like the conditional-append primitive. It isn't. Two writers appending at the same parent both succeed:

writer A -> e_fd3ce7e1ffe6   (parent e_9da6…)   ok
writer B -> e_cad909ed44b3   (parent e_9da6…)   ok

$ iii trigger session::messages session_id=$SID
  … e_9da67bbfd6c1  {"confidence":0.86}
  … e_cad909ed44b3  {"claim":"writer B"}
                                       ← A is not here

$ iii trigger session::get-message entry_id=e_fd3ce7e1ffe6
  {"id":"e_fd3ce7e1ffe6", "message":{…"writer A"…}, "revision": 0}

A's event is durable, and you can fetch it by id, but it sits on a sibling branch. session::messages does not walk that branch, so no projection reading the ordinary way will ever see A's event. Still, A's writer received a success response, and nothing anywhere reports a problem.

def append(self, stream, type, payload, *, expected_version=None) -> Event:
    log = self._streams.setdefault(stream, [])
    if expected_version is not None and expected_version != len(log):
        raise Conflict(f"{stream}: expected {expected_version}, found {len(log)}")
    event = Event(seq=len(log) + 1, type=type, payload=payload, stream=stream)
    log.append(event)
    self._notify(event)
    return event

Four lines. Which is what makes the absence notable: this is not a hard feature to write. The convincing near-miss is what makes it dangerous rather than just missing.

The more valuable half of the from-scratch build is the UnreliableBus. That bus is a notification channel that is at-least-once and unordered on purpose, because session-manager documents that contract for itself. It exists so one test can prove the claim below, which is the single most transferable finding in this series:

_seed(store)                       # 4 events, appended in order
bus.drain(lambda e: (naive_handler(e), doorbell_handler(e)))

truth = Projection("truth", incident_fold).rebuild(store.read(STREAM))

assert doorbell.state == truth    # re-reads the ordered log. correct.
assert naive.state    != truth    # folds in arrival order. corrupted.
assert len(naive.state["claims"]) != len(truth["claims"])

Identical events. Identical fold function. One projection is right and one is silently wrong. The only difference is whether it trusted the delivery order. Neither case raises an exception, and the wrong projection just reports a wrong number.

• An ordered log does not give you ordered projections. iii orders its log by the parent chain. The docs call its notifications "at-least-once and unordered". Those two facts live in different documents, and the gap between them is where wrong dashboards come from. Check both guarantees in whatever you are using, because almost nobody states them in the same place.
• Treat the notification as a doorbell, not as data. Re-read the ordered log on every notification, and you are immune to reordering, duplication and gaps. That immunity costs one read per event. Fold the delivered event directly and you are fast and wrong. Both implementations arrived at the same rule independently.
• A near-miss is worse than an absence. A missing feature makes you build something. But a feature that accepts your parameter and then ignores it makes you believe you have a guard. The parameter next to it does validate, which is what makes the pair convincing. Test that your concurrency control rejects a conflicting write.
• Replay is worth more with a model in the loop. Fork the stream just before a model call, then replay it with a different prompt. That loop beats re-running and hoping, because a re-run does not reproduce the run.

That ends the series: the same incident-analysis workflow over actors and supervision, a blackboard, and an event log. Three architectures, one task, two implementations each. The pattern across all three is that iii supplies more of each model than expected. Its gaps are consistently the parts that fail without an error, rather than with one.