Client-side decision-consistent reads: fold a read model, carry forward the exact log position it was folded at, and let Chronicle.Transactions.UnitOfWork guard a subsequent append with it — the Dynamic Consistency Boundary (DCB) pattern.

Chronicle.decide(fn _unit_of_work ->
  {:ok, %{instance: seat}} = Chronicle.ReadModels.DecisionReads.get(MyApp.ReadModels.Seat, "seat-5")

  if seat == nil do
    Chronicle.EventSequences.EventLog.append("seat-5", %SeatBooked{by: "alice"})
  end
end)

If another process books the same seat between the read and the commit, the kernel rejects the whole batch and Chronicle.decide/2 returns {:error, %Chronicle.ReadModels.DecisionConflict{}} instead of appending anything.

Call get/2 (or its stream variant, get/4) from inside a unit of work — it enrolls the read as a decision dependency automatically. Call get_detached/2 (or get_detached/4) to fold the same way without an ambient unit of work, when you only need the guarded read's current value and are not about to commit anything against it.

What can be guarded

Not every read model shape can be protected: admit/2 and admit_for_stream/2 run the same checks get/2/get_detached/2 do, without any I/O, so a caller can check eligibility ahead of time. See Chronicle.ReadModels.DecisionReadRefused for every refusal reason.

Passive reducers (Elixir-only)

The .NET client refuses every reducer-backed read model outright. A read model produced by a passive reducer (use Chronicle.Reducers.Reducer, active: false) can be decision-read here instead: because a passive reducer is never kept warm by an observer, its current value is always folded fresh from Chronicle.EventSequences.EventLog.get_for_event_source/2, which makes it trivial to capture the exact boundary the fold stopped at. An active reducer is still refused with :reducer — only the client that asked for the fold knows it reached a consistent point, and an active reducer never asks.