1 Introduction↩︎

Database systems have long separated logical correctness from physical execution through transactions, recovery, isolation, logging, and integrity constraints [1]–[4]. Workflow systems extend these ideas to long-running activities with retries, timeouts, idempotency, and compensation [5]–[7]. Both families, however, usually assume that the submitted unit of work is meaningful enough to be treated as a transaction request: it may conflict, fail, or abort, but it is not itself a hallucinated, stale, or semantically invalid proposal produced by an untrusted reasoning process.

Agentic workflows violate this assumption. The candidate transaction may be generated by a language model, an optimization solver, or a team of agents, including prior multi-agent planning systems that add validation and transaction-style guarantees [8]–[15]. Yet a well-formed proposal can still be wrong in ways a syntactic check accepts.

Consider a concrete case from multi-agent planning [8]. In a family’s Thanksgiving plan, the father lands in Boston and picks up Grandma on the way home so dinner can start on time. His flight is delayed, so an LLM agent reactively replans the afternoon’s pickups and drives. The new schedule parses as valid, yet two faults slip through. It reuses the off-peak drive time from the original 3 pm plan, ignoring that the delayed pickup now lands in rush-hour traffic, so the rescheduled pickup is physically impossible. And after reshuffling the drivers, it silently drops Grandma’s pickup, leaving her stranded so dinner never starts.

A conventional transaction layer would commit this well-formed schedule and inherit both faults. ATP instead routes each revised assignment through a deterministic gate against the declared constraint set \(\mathcal{C}\) over the current effective state (the StateView). The infeasible pickup is rejected because its travel time violates \(\mathcal{C}\); the replan is rejected for dropping Grandma’s pickup, since a committed obligation cannot silently disappear. Feasible reassignments commit; the rest are rejected with a recorded reason. The durable guarantee thus comes from outside the model: a stronger planner gets more of the day right, but none can erase a standing commitment or commit a physically impossible plan.

Admission stops bad proposals, but some failures are not proposals at all. Suppose the gate has committed a feasible afternoon and execution begins, and then an unforeseen disruption strikes that no policy anticipated: a highway closure makes the committed airport leg infeasible in mid-execution. No pre-registered compensation covers it. Here ATP does not merely reject; it reacts. The affected commitment wakes and launches a bounded local repair that re-times only the disrupted leg and its dependents, leaving the rest of the day untouched, and the repair it produces re-enters the same admission gate. A wrong reactive repair is caught exactly like any other proposal, while the blast radius stays contained to the affected region instead of forcing a full re-plan. Static admission and bounded reactive repair are thus two halves of one boundary: nothing becomes truth, whether first proposed or repaired, without passing the gate.

The failure boundary is no longer only the commit protocol. It is the transition from generated intent to durable truth. For agentic workflows, the first transaction question is not merely “can this transaction commit?” but: should this generated proposal be admitted as a transaction at all?

This paper introduces Agentic Transaction Processing (ATP), a transaction model for generated workflows.¹ What is new is not the failure but the proposer. Capable AI now drafts and repairs workflows at a speed and scale no human author matches, and that is genuinely useful: an LLM or agent can react to a disruption no designer anticipated and propose a fix in seconds. But the same models hallucinate, and they are sycophantic (asked to validate their own plan, they tend to endorse it), so the proposer cannot be its own judge. Speed, autonomy, and reactivity are exactly what we want from AI, and exactly what makes an unguarded transaction layer dangerous: we can neither simply trust the proposer nor surrender the automation. ATP keeps both. It admits AI, solver, agent, and trigger output as untrusted proposals that only a deterministic gate may turn into committed truth, so the system stays smart and reactive where it proposes while remaining correct where it commits. The central rule is:

Generated actions may propose. Active workflow obligations may wake. Solvers may repair. Runtime drivers may orchestrate. But only the transaction layer may admit and commit. And the first clause is not the whole story: no proposal, however well admitted, foresees every future disruption, so ATP does not stop at the gate.

This yields a separation that classical transaction processing never needed. Because every generated action, repair, and learned policy is a proposal that only the gate may admit, committed-state correctness is decoupled from the intelligence layer. Relative to a declared constraint set \(\mathcal{C}\), a more capable model produces better proposals, while a faulty or adversarial one produces more rejected work, but neither can write committed truth that violates \(\mathcal{C}\). Intelligence governs usefulness; the transaction layer governs correctness, and building that layer is a data-management problem: it lives in a committed transition log, an effective-state projection, and a deterministic admission gate, not in the prompt.

This boundary is the complement of agent-side approaches. Where SagaLLM [8] brings transactional discipline to the LLM planner, ATP opens the transaction layer to untrusted planners: one disciplines the proposer, the other governs the committer, and together they bracket the same goal from both ends.

1.0.0.1 Why this is not input validation.

For decades the unit of work submitted to a transaction system was authored by a person or a trusted application and reviewed before submission, so the system could assume the submitter held the authority to transact; classical input validation and integrity constraints then checked only data quality (does this command satisfy fixed predicates), never the submitter’s right to commit. A generative proposer breaks that assumption, and that is what is new. ATP governs the prior question (whether an untrusted, generated proposal may become a transaction request at all), so what it enforces is an authority contract over committed state, not a richer predicate on a trusted command: a proposal is validated against the effective-state witness (StateView), a repair may not destroy the evidence that justified it, an active commitment may wake but never write, and concurrent proposals are admitted as if serial. The hardest of these, evidence-preserving repair, has no analogue in classical validation, which never had to distrust the author of the command.

1.0.0.2 The second half: reactive local repair.

Admission decides which proposals may commit, but it cannot, by itself, handle a disruption that strikes after commit and that no registered compensation covers: a breakdown, a closure, a late arrival. For these, ATP adds a second mechanism: a localized cascading repair protocol (LCRP). When such a failure fires, the affected obligation wakes and LCRP edits only the affected region of the committed plan, under a bounded edit radius and iteration cap, propagating along effective dependencies and escalating to rollback if it cannot contain the damage. The repair LCRP produces is itself a proposal that re-enters the same admission gate, so reactive recovery inherits the same guarantee: a wrong repair cannot commit. Admission keeps a bad proposal out; LCRP keeps an unforeseen disruption from forcing an unbounded, unguarded re-plan, the proposal-time and runtime faces of a single authority rule (§3.2).

1.0.0.3 Contributions.

1. A new database-systems problem. Agentic transaction processing: a generated action must earn transaction authority before it becomes committed truth (§[sec:motivation]).

2. The ATP model. A transaction model that decouples committed-state correctness from the intelligence layer by treating every LLM, solver, and agent output as a proposal, with active commitment records (ACRs), transaction-log-resident obligations whose wakeups are themselves proposals (§2.2).

3. Four safety theorems. Authority separation, serial-equivalent generative admission, evidence-preserving repair, and obligation containment, proved relative to a constraint set \(\mathcal{C}\) (§2.3, §3).

4. Reactive local repair. A bounded localized repair protocol (LCRP) whose output re-enters admission, with a bounded-recovery contract and a reduction of recursive recovery to sequential recovery (§3.2).

5. The Mnemosyne runtime. An executable ATP substrate over a committed-transition log, effective-state projection, deterministic admission, dependency-safe compensation, and PostgreSQL-backed concurrency (§4).

6. Evaluation. Nine falsification-style safety experiments, a cost audit, a disruption-containment study (LCRP edits an order of magnitude fewer operations than global recompute), and a recovery-during-recovery analysis (§5).

2 Agentic Transaction Processing↩︎

Generated workflow actions fail in ways ACID does not address: an invalid transition, a compensation that orphans effective dependents, conflicting or stale-world proposals, or a repair that destroys the evidence that triggered it. ACID governs a transaction after the system accepts it [1]–[3]; ATP governs whether a generated proposal should be admitted as a transaction at all. This section presents the failure model (§2.1), the transaction model (§2.2), the properties it adds beyond ACID (§2.3), and the invariants the runtime enforces (§2.4).

2.1 Failure Model↩︎

Mnemosyne addresses failure modes that ACID does not govern, because ACID constrains a unit of work only after it is admitted. We describe the principal modes below; Table 1 pairs each with the mechanism that rejects or contains it.

Invalid generated transition. An LLM proposes a workflow transition that violates a finite-state constraint. A conventional workflow engine may persist the action unless application code rejects it. ATP requires a deterministic validator to reject it before commit.

Compensation with effective dependents. A record is compensated after downstream records have depended on it. Raw log history still contains the record, but it is no longer effective. ATP disallows compensation that would orphan currently effective dependents or break the effective-state chain.

Conflicting proposals. Two agents propose different plans for the same tenant and entity. Both may be individually feasible. ATP rejects the active proposal set before commit because the proposals conflict over the same admission scope.

Stale-world proposal. A solver proposes a route assuming a deadline of 17:00, but an observed world snapshot reports the deadline is now 11:00. ATP rejects the proposal before commit because its assumptions no longer match observed facts.

Evidence-destroying repair. A coding agent observes that continuous integration is red and proposes to “repair” the repository by deleting the failing tests. A periodic checker may see the next CI run turn green and conclude the violation is gone, but the defect has not been repaired: the evidence has been destroyed. ATP requires admission to preserve the evidence that triggered repair unless the validator accepts that the repair addresses the underlying condition rather than suppressing its observable signal.

2.2 The Agentic Transaction Model↩︎

We model an ACR as: \[\begin{align} r = \langle &\text{id}, \text{txn}, \text{commitment}, \text{scope}, \text{trigger},\\ &\text{continuation}, \text{guard}, \text{validator}, \text{compensation},\\ &\text{expiry}, \text{failure-key}, \text{status}\rangle . \end{align}\] Typical status values are live, fired, proposed, admitted, rejected, compensated, expired, and discharged.

Figure 1 shows the core ATP path. The proposal is not committed directly. It passes through admission. The commit log is the source of committed truth, while StateView exposes current effective state.

Algorithm 2 gives the executable contract used by the implementation and by the RQ1–RQ5 experiments. The details of \(\mathcal{C}\) are application-specific, but the authority pattern is fixed: proposal generation can vary, while admission and commit remain deterministic runtime operations.

2.3 Properties Beyond ACID↩︎

ACID is necessary but insufficient for agentic workflows. Atomicity, consistency, isolation, and durability protect a transaction once the system has accepted it [1]–[4]. They do not decide whether a generated action should have been accepted as a transaction in the first place. ATP adds an admissibility layer in front of commit: ACID protects committed transactions, while ATP protects the authority boundary before a generated action becomes a transaction. The properties below make the ATP layer precise, and Section 3 proves the four that matter most.

Table 2 aligns each classical guarantee or mechanism with the ATP property that governs it once the writer is an untrusted generator. Most rows extend a familiar guarantee to generated proposals; the last names a concern ACID never had.

2.4 Safety Invariants↩︎

We state the core safety conditions as invariants here; the properties that follow are proved as theorems in §3, with full proofs in the extended version. The results are relative systems-safety claims rather than complexity-theoretic claims. Throughout the section, fix a trusted constraint set \(\mathcal{C}\) consisting of the deterministic admission validator, application finite-state constraints, dependency and compensation rules, stale-world checks, evidence-preservation rules, and conflict-scope rules. A committed transition is \(\mathcal{C}\)-valid if the admission gate accepts it under this constraint set and current effective state. All guarantees below are relative to \(\mathcal{C}\); if \(\mathcal{C}\) omits a hazard, ATP does not claim to detect it.

2.4.0.1 Bounded executable constraint set.

ATP does not assume an oracle for semantic correctness. In the implementation and experiments, \(\mathcal{C}\) is a finite executable constraint set over proposal structure, tenant/entity scope, operation and idempotency keys, current StateView, dependency edges, retained evidence handles, declared world facts, and application validators. Thus \(\mathcal{C}\) is decidable for the artifact workloads. In richer deployments, constructing a faithful \(\mathcal{C}\) is part of the application engineering problem rather than something ATP solves by itself. Appendix 15 gives a taxonomy and grammar of \(\mathcal{C}\), showing that most rules are derived structurally or declared as predicates rather than hand-coded per case.

2.4.0.2 Gate closure.

The theorems assume gate closure: proposer, solver, runtime-driver, benchmark, and ACR-wakeup code can emit proposal packages but cannot append domain truth to CTL except through admission. Mnemosyne’s reference implementation is organized around this boundary and includes regression tests for non-authoritative wakeups, rejected proposals, and commit-boundary behavior, but this paper does not claim a machine-checked noninterference proof of the entire Python codebase. The formal claims therefore apply to executions that satisfy this gate-closure assumption.

2.4.0.3 Where the difficulty lives.

Theorem 1 is deliberately simple once the gate is trusted: if only \(\mathcal{C}\)-valid transitions are appended, committed state is \(\mathcal{C}\)-valid. The systems contribution is not that implication but the structure of \(\mathcal{C}\) and the witness the gate reads. A classical validator checks a submitted command against static predicates; ATP’s gate instead reads the effective-state projection rather than raw history, enforces dependency-closed compensation, rejects stale-world and conflicting proposals, and, hardest of all, refuses a repair that would discharge its own trigger by destroying evidence. We therefore lead the development conceptually with evidence-preserving repair (Theorem 3), the guarantee with no classical analogue, and read authority separation (Theorem 1) as the umbrella it instantiates.

3 ATP Theorems↩︎

We prove the invariants of §2.4 as safety theorems: first for the admission of generated proposals, then for reactive repair under unforeseen disruptions (§3.2).

3.1 Admission Safety↩︎

The intelligence layer may make the system more or less useful; it cannot make committed state incorrect with respect to \(\mathcal{C}\) unless it is granted authority to bypass or weaken the admission boundary. This is the central systems claim: the model can hallucinate, the solver can be wrong, the agent can be adversarial, and a learned policy can be bad, yet none can corrupt committed truth unless \(\mathcal{C}\) itself admits the transition.

This theorem is stronger than audit traceability. Traceability says the alarm can be found later; evidence-preserving repair says the alarm cannot be silenced by the repair.

3.1.0.1 Decidability caveat for repair.

Theorem 3 does not decide whether an arbitrary real-world failure has truly been fixed. That question can be open-ended or outside the information available to the runtime. ATP requires either an executable validator in \(\mathcal{C}\) that accepts the repair as resolving the triggering condition, or continued retention of the triggering evidence. If neither condition can be established, the safe behavior is rejection or escalation rather than admission.

3.1.0.2 What these guarantees do and do not claim.

All ATP guarantees are relative to the declared trusted constraint set \(\mathcal{C}\). If \(\mathcal{C}\) is incomplete, ATP cannot reject violations outside \(\mathcal{C}\). The theorems do not prove convergence, optimality, monotonic improvement, unlimited liveness, or full-code bypass freedom. They prove a narrower systems property: intelligence, learning, and recovery memory remain non-authoritative. They may propose, rank, delay, or over-reject, but they cannot commit domain truth except through admission under \(\mathcal{C}\).

3.2 Reactive Repair for the Unforeseen↩︎

Admission decides whether a generated proposal may become truth. But not every threat to committed state is a proposal: the world also produces failures no proposal anticipated: a delayed flight, a machine breakdown, a road closure mid-execution. A generated plan can be perfectly admitted and still be overtaken by an event it never modeled. ATP therefore pairs admission with a second mechanism. A proposal is not truth, and no proposal foresees every disruption: the first clause is enforced by the gate, the second by reactive local repair.

ATP distinguishes two failure modes. Anticipated failures have a recovery path the designer registered in advance (a cancelled booking that triggers a declared compensation), and are handled by the evidence-preserving, dependency-closed compensation of Theorems 3 and 4. Unforeseen failures have none: the committed log reaches a state no compensation addresses. Here a fired ACR hands the disrupted region to a localized cascading repair protocol (LCRP) rather than recomputing the whole plan.

3.2.0.1 The reactive loop.

The runtime runs one loop per event (propose, admit, commit, monitor, repair), and on disruption LCRP applies bounded edits instead of a global recompute. It edits only the disrupted region under an iteration cap \(K\) and a displacement budget \(\delta_{\max}\), where the edit radius counts the transitions (operations or jobs) touched. Each iteration revalidates feasibility against \(\mathcal{C}\) and propagates effects only along the effective dependencies of the disrupted region, so a change ripples to a successor only if that successor actually depends on the changed record in the current StateView. The runtime, not the proposal, computes the reversibility class of each candidate edit, so a repair cannot self-certify as safe; one that would cross an irreversible boundary is vetoed. Crucially, the repair LCRP produces is itself a proposal that re-enters the admission gate, so a wrong reactive repair is caught exactly like any other proposal and can never become committed truth.

3.2.0.2 Repair phases.

A single repair round proceeds in three phases over the disrupted region. (I) Status update records the disruption as a new world fact (marking the affected committed records ineffective and retaining the disruption as evidence), so the repair is computed against the true post-disruption StateView, not the stale plan. (II) Effect propagation pushes the consequences (delays, freed resources, violated guards) forward along effective dependencies, computing the minimal set of downstream transitions that must change. (III) Bounded reassignment re-times or re-assigns only those transitions, under \(\delta_{\max}\) and \(K\), and emits the result as a proposal package. Each phase is contained to the dependency closure of the disruption, which is what keeps the edit radius small; the package then passes ordinary admission before any of it commits.

These guarantees are relative to \(\mathcal{C}\) and the runtime’s effective-state model; they do not assert that the proposer finds a globally optimal repair, nor that \(\mathcal{C}\) is semantically complete.

3.2.0.3 Recovery during recovery.

A repair is itself an execution, so a failure can strike while a repair is in flight: a second disruption arrives before the first is absorbed, or a compensation itself fails. This recursive recovery appears to demand a recovery stack whose depth must be tracked and bounded. It does not, but the reason must be stated carefully, because a disruption is a new fact about the world and must never be dropped. After the most recent committed restore point \(S_k\), the runtime maintains a pending observation set \(D_k\): the disruptions observed since \(S_k\) that no admitted repair has yet absorbed. Every repair candidate is validated against \(S_k\), \(\mathcal{C}\), and all of \(D_k\), so it must account for every outstanding failure, not only the latest.

3.2.0.4 Why reactive repair is the hard half.

Reactive repair is where admission stops being a predicate check. A generated repair runs over effective state, must preserve the very evidence that triggered it, must close its own dependencies and conflict scope, and may be interrupted by a fresh disruption, yet ATP keeps every committed transition feasible and loses no observation, with edit radius and recovery depth both bounded. This is the systems content behind the second clause of the principle: because no proposal foresees every disruption, the transaction layer must react safely, not merely admit. Reactive planning is thus fully in scope; only preemptive guard synthesis (anticipating disruptions before they occur) is deferred to future work (Limitations).

4 Mnemosyne Architecture and System Specification↩︎

Mnemosyne is the executable substrate for ATP. Its design objective is not to make the proposer smarter; it is to make proposal authority explicit. The architecture therefore separates four planes: the proposal plane, where LLMs, solvers, benchmark adapters, learned policies, and active commitments generate candidates; the admission plane, where deterministic validators decide whether a candidate may become truth; the commit plane, where admitted transitions are durably appended; and the projection plane, where current effective state is materialized for future admission. Runtime engines sit outside these planes as orchestrators. They schedule work, retry steps, and wake obligations, but they do not own committed truth. Figure 4 shows these planes, the proposers that feed them, and the durable stores that only admitted transitions may extend.

Durable substrate. The committed-transition log (CTL) is the source of committed truth: tenant-scoped, versioned, and logically append-only, it stores admitted transitions, compensation and supersession records, and ACR lifecycle records, so later transitions may supersede earlier ones without erasing the fact that they were admitted. StateView projects current truth from CTL by replaying only effective records (not compensated, superseded, or invalidated, with dependency chains intact); admission reads StateView, never raw history, which is the mechanism behind effective-state soundness. A recovery-event log records the fine-grained events of repair and obligation execution, and in the PostgreSQL substrate tenant-scoped uniqueness over event identifiers, idempotency keys, and recovery sequence positions is the concrete idempotency boundary of Theorem 2.

Concurrency and contention. The serialization unit is the conflict scope, not the whole log: proposals over disjoint scopes (distinct tenant, entity, or resource) commit concurrently, so throughput scales with scope-level parallelism rather than a single global lock. Within one hot scope, the PostgreSQL substrate orders contenders through row-level locking and a unique constraint over (tenant, scope, idempotency key, recovery sequence position), so concurrent proposals either converge to one canonical committed transition or reject the conflicting losers, exactly the boundary of Theorem 2; MVCC snapshot isolation lets the StateView projection read effective state without blocking admission. A large disruption that wakes many obligations therefore degrades to serialized admission on the affected scopes only, trading latency for serial equivalence rather than risking an invalid interleaving, and rejected contenders retry against the updated StateView under the memoryless repair model (§3.2). Cross-scope independence is what keeps dense conflict-scope collisions from becoming a global bottleneck.

Authority boundary. The admission gate is the only authority boundary. A proposal package carries a candidate transition, declared scope, proposer identity, an optional solver certificate, world assumptions, and evidence; the gate checks finite-state validity, idempotency, scope, dependency closure, compensation safety, stale-world conditions, conflicts, and evidence preservation, treats a solver certificate or LLM rationale as evidence rather than authority, and returns an admitted transition, a reasoned rejection, or an escalation. ACRs are durable obligations in the same substrate, recording guards, triggers, continuations, compensation hooks, scopes, and validators; on firing, an ACR may resume a continuation that constructs a repair proposal, which still passes ordinary admission, so memory is active but non-authoritative.

Boundaries and drivers. External events enter through an inbox deduplication boundary, and external effects leave through an outbox that stages provider calls with idempotency keys, so a domain commit never silently becomes an external effect and duplicate observations never create duplicate commits. Runtime drivers, including durable engines such as Temporal and Cadence [16], [17], orchestrate execution, timers, retries, and wakeups but remain non-authoritative: a driver may detect a ready ACR, call a provider, and submit a package, yet may not mutate domain truth, so the deployment substrate can change without changing ATP’s correctness. Table 3 states each component’s authority contract: what it owns, what it does not own, and the failure that results if its boundary is bypassed.

3pt

The full proposal-and-obligation lifecycle (propose\(\rightarrow\)admit\(\rightarrow\)commit\(\rightarrow\)project, with an obligation’s create\(\rightarrow\)watch\(\rightarrow\)wake\(\rightarrow\)resume rejoining the same proposal-admission path) together with the six-point functional contract, the storage substrate (SQLite default and optional gated PostgreSQL), and the deployable service boundary, is specified in Appendices 11–16; Appendix 17 gives concrete JSON-level proposal examples, and Appendix 18 traces one transaction end to end. The invariant they enforce is the one already proved here: an ACR wakeup is not a commit; it only returns the system to ordinary proposal admission, so no component receives a privileged commit path because it is a solver, a learned guard, or an active commitment.

5 Evaluation↩︎

This paper evaluates ATP as a data-management system, not as an LLM planning method. The experiments validate the assumptions behind the theorems and the correctness of the implementation; they make no claim about learning, regret, or preemptive planning, which are future work. Planning and recovery workloads are derived from the REALM-Bench planning benchmark and instantiated here as the J1–J4 benchmark harness [18]. We reserve the name P1–P10 for broader readiness suites that are tracked as a separate artifact and are not certified in this draft. The evaluation is organized around five research questions. RQ1 asks whether the authority boundary holds across hazard classes and end-to-end; RQ2 compares against workflow/saga guardrails; RQ3 separates proposer usefulness from committed-state correctness; RQ4 audits artifact-level cost; and RQ5 examines reactive repair: how contained a bounded repair is, and whether recovery during recovery stays safe. RQ1–RQ4 are completed in the released Mnemosyne artifact. RQ5’s containment (edit radius) is reported on a companion job-shop scheduling harness that implements the same bounded-repair protocol, where blast radius is directly measurable and the claim is a systems property (bounded edit radius at equal feasibility), not planning quality; recovery during recovery is validated by construction (Proposition 3), with broader empirical study in progress.

5.1 Overview and Scoreboard↩︎

The current implementation covers the falsification-oriented empirical spine of the released artifact: six theorem- and property-validation benchmarks, two end-to-end usefulness benchmarks, one mechanism-level workflow/saga comparator, and one infrastructure-cost audit. The six safety benchmarks check, respectively, that generated proposals stay non-authoritative until admitted (AuthorityBench); that concurrent proposals commit to a serial-equivalent history (SerialAdmissionBench); that a repair cannot discharge its own trigger by destroying evidence (EvidenceRepairBench); that commitment wakeups resume recovery without mutating domain truth (ObligationBench); that compensation and supersession preserve effective-state projection (CompensationProjectionBench); and that storage-level uniqueness, idempotency, and transactional projection reject duplicate or malformed attempts without corrupting StateView (StorageSubstrateBench). J1J4EndToEndBench drives planning and recovery cases through the boundary, ProposerQualityBench varies proposer quality while tracking usefulness and the invalid-commit invariant, and GuardrailComparatorBench compares ATP with a workflow/saga guardrail stack (schema validation, finite-state checks, idempotency keys, timers, local saga compensation, proposer self-checking) that lacks ATP-specific evidence, effective-state, obligation, compensation-closure, and conflict-scope admission.

These benchmarks are falsification-oriented systems tests rather than stochastic model-quality experiments. The deliberately permissive baselines expose each targeted failure mode by giving generated actions, repairs, wakeups, or storage writes more authority than ATP permits. The guardrail comparator (RQ2) then reduces the strawman-baseline concern by comparing ATP with a mechanism-level workflow/saga guardrail stack. A result is meaningful only when the comparator commits the specified violation, while ATP commits zero such violations and still admits valid operations. Figure 5 summarizes the safety evidence across every hazard class and the comparator; the cost audit (RQ4) is reported separately because it measures infrastructure overhead rather than violation suppression.

4pt

Together, Table 4 and Figure 5 are the scoreboard: the permissive baselines expose the targeted failure mode, the comparator adds a mechanism-level workflow/saga guardrail comparison, and ATP suppresses the failure mode without turning into a reject-all system.

5.2 RQ1: Does the Authority Boundary Hold Across Hazard Classes and End-to-End?↩︎

The first and primary question is whether the admission boundary actually holds: across every hazard class ATP is designed to stop, does committed state stay \(\mathcal{C}\)-valid even when generated proposals, repairs, wakeups, or storage writes are given more authority than ATP permits? We answer it with six falsification benchmarks, one per hazard class, each comparing ATP against deliberately permissive baselines. Figure 5 is the scoreboard: in every class the permissive baseline commits the targeted violation, while ATP commits zero such violations and still admits the valid operations. Per-class designs and full result tables are in Appendix 8; we summarize the six classes here.

AuthorityBench (Theorem 1) gives five proposer classes direct or self-validated commit authority: both baselines commit \(35\) invalid transitions, while ATP commits zero and still admits the five valid ones. SerialAdmissionBench (Theorem 2) runs \(80\) concurrent proposals over a shared capacity object; the unserialized and weak-lock baselines commit invalid proposals and underflow capacity, while ATP commits only the \(32\) valid proposals through a serialized boundary and yields a serial-equivalent history. ObligationBench (Theorem 4) fires active commitment records under four continuation sources; the baselines let wakeups mutate domain state directly (\(12\) and \(16\) unauthorized mutations), while ATP routes every wakeup through ordinary admission and commits zero. CompensationProjectionBench stresses compensation, supersession, and replay across seven dependency scenarios; the projection baselines admit invalid compensations and project ineffective history as current truth (seven StateView mismatches), while ATP keeps StateView the projection of effective committed records only, with zero mismatches. StorageSubstrateBench exercises duplicate, stale, and malformed storage attempts; the unconstrained log commits \(64\) invalid attempts and mis-projects the total, while the ATP storage path (SQLite default, optional gated PostgreSQL) rejects all \(64\) and preserves projection.

The distinctive case is EvidenceRepairBench (Theorem 3), which has no classical analogue. It constructs repairs that discharge their own trigger by deleting a failing test, suppressing an alert, compensating a diagnostic record, or hiding a violated guard. A naive repair agent and a workflow baseline without an evidence-preservation rule each commit \(20\) such evidence-destroying repairs; ATP commits zero, rejecting every repair that would succeed merely by removing the signal that justified it, while still admitting the eight genuinely valid repairs. This is the property that separates ATP from audit logging: the alarm cannot be silenced by the repair.

Across all six classes the pattern is identical: the permissive baseline commits the targeted violation, while ATP commits zero and still admits valid work. This is the operational content of the four theorems of Section 3, relative to the declared constraint set \(\mathcal{C}\). Because the boundary is enforced by construction, these results are best read as evidence that the implemented gate is wired and unbypassed on the tested hazards, not as a competitive comparison; the comparison against state-of-practice mechanisms is RQ2.

End-to-end. Beyond the unit hazards, real planning-and-recovery cases must run end-to-end through the same boundary. J1–J4 instantiate four REALM-Bench planning and disruption-recovery cases [18], each emitting valid and invalid packages (six valid, three invalid) along benchmark case \(\rightarrow\) proposal \(\rightarrow\) admission \(\rightarrow\) CTL \(\rightarrow\) StateView, measured against a direct-workflow baseline that commits every package. Table 5 shows the result: ATP admits the six valid packages, rejects the three invalid ones, completes all four cases with zero invalid commits and a consistent StateView, while the baseline commits all nine and leaves three StateView mismatches. These cases also exercise the reactive-repair path of §3.2: when a disruption fires, the affected obligation wakes and proposes a bounded local repair that re-enters admission, so end-to-end safety already covers reactive recovery; RQ5 then quantifies how contained that repair is.

3.2pt

5.3 RQ2: Does ATP Catch Hazards Workflow/Saga Guardrails Miss?↩︎

Does ATP catch hazards that common workflow, saga, or guardrail mechanisms would miss? The safety benchmarks (RQ1) use falsification baselines to isolate each hazard class. RQ2 strengthens the comparison with GuardrailComparatorBench, which models mechanisms commonly available in durable workflow engines and guarded agent stacks: schema validation, finite-state checks, idempotency keys, retry and timer execution, local saga compensation, and proposer self-checking. This comparator is not a product benchmark of Temporal, Cadence, Argo, LangGraph, or any specific framework; it is a semantic baseline for mechanisms those systems commonly provide and hazards they typically leave to application-level logic. Consequently, RQ2 should be read as a mechanism-level baseline rather than a third-party product comparison; adding a live Temporal, LangGraph, or saga-library baseline is future empirical work.

The benchmark contains fourteen cases: four valid operations, four classical guardrail hazards, and six ATP-specific hazards. The classical hazards are a malformed proposal, a finite-state violation, a duplicate operation key, and a failed proposer self-check. The ATP-specific hazards are a stale-world plan, an evidence-destroying repair, a direct obligation mutation, an orphaning compensation, an ineffective-record projection error, and a conflict-scope violation. The workflow/saga guardrail stack rejects the classical hazards but does not implement ATP-specific admission over effective StateView, evidence preservation, obligation containment, dependency-closed compensation, or conflict-scoped generative admission.

4.5pt

Table 6 shows the completed mechanism-level comparator run. The raw generated write baseline commits all fourteen cases, including ten invalid cases. The workflow/saga guardrail stack improves on that baseline by rejecting all four classical guardrail hazards, but it still commits the six ATP-specific hazards. ATP admits the four valid cases, rejects all ten invalid cases, commits zero invalid cases, and misses zero ATP-specific hazards. This is the artifact-level answer to the input-validation objection: ATP is not merely a predicate checker before commit. It makes effective state, retained evidence, active obligations, compensation closure, and generative conflict scopes part of the transaction authority boundary. Appendix 9 extends this comparison to a production transaction-processing substrate, auditing which layer owns each enforcement responsibility.

5.4 RQ3: Does Proposer Quality Affect Usefulness but Not Correctness?↩︎

How does proposer competence affect utility while ATP holds committed-state correctness fixed? We evaluate this using ProposerQualityBench. The benchmark emits 60 proposals from six proposer classes: no-intelligence, random, rule-based, solver-like, LLM-like, and adversarial proposers. Proposal quality controls how many attempts are valid under \(\mathcal{C}\) and how much utility an admitted attempt contributes. We compare ATP with a direct-commit baseline that commits every attempt.

4pt

Table 7 shows the safety invariant. The direct-commit baseline commits all 60 attempts, including 37 invalid attempts. ATP admits 23 valid attempts, rejects 37 invalid attempts, and commits zero invalid attempts. The total valid utility is the same because invalid proposals carry zero utility; therefore the usefulness signal appears in the proposer-level acceptance and utility profile, not in the unsafe direct-commit row. The proposer classes in this artifact are deterministic adapters rather than live calls to a frontier LLM, chosen so the safety result is reproducible; the failure modes they inject are exactly those that live models such as Claude 3.7 and GPT-4o produce in multi-agent planning [8]. Because admission is evaluated against \(\mathcal{C}\) and the effective StateView, the authority-boundary claim is independent of how a proposal is generated: a live-model proposer changes which proposals are useful, not whether an invalid one can commit.

4.5pt

The per-proposer profile (Figure 6 and Table 8) shows that proposer quality affects usefulness and admission efficiency. The solver-like proposer has the highest acceptance rate and admitted utility; the no-intelligence and adversarial proposers are mostly rejected. Yet every proposer class has zero invalid commits under ATP. This supports the paper’s central separation: intelligence governs usefulness, while the transaction layer governs committed-state correctness relative to \(\mathcal{C}\). This is not a learning experiment; it makes no cross-episode improvement, regret, or preemptive-planning claim.

5.5 RQ4: What Does the Safety Boundary Cost?↩︎

RQ2 establishes that ATP rejects the ATP-specific hazards in the mechanism-level workflow/saga comparator; RQ4 audits the cost visible in the implemented ATP infrastructure paths. We do not time the RQ2 oracle comparator as though it were the ATP runtime, and we do not claim a production load test. Instead, we run a repository infrastructure workload covering kernel admission, runtime admission, commit-boundary enforcement, effective-state projection, validation, compensation, active recovery, and Temporal activity-boundary validation. Each repeat executes 20 ATP infrastructure paths, and we measure 30 repeats at worker counts \(1\), \(4\), and \(8\). The workflow/saga semantic comparator is still executed to preserve the RQ2 baseline, but its single semantic test is not treated as a throughput competitor for the 20-path ATP infrastructure workload.

3.8pt

Table 9 reports the real-infrastructure result. All ATP infrastructure runs pass at all three worker counts. At one worker, the 20-path workload requires \(5192.7/5266.5\) ms end-to-end \(p_{50}/p_{95}\), with admission latency \(0.040/17.235\) ms and commit latency \(2.574/8.620\) ms. At four workers, measured throughput rises to \(709.10\) infrastructure units per minute, with projection plus validation accounting for \(5.63\%\) of end-to-end runtime. At eight workers, measured throughput reaches \(804.43\) infrastructure units per minute; admission and commit tail latency increase, as expected under concurrent pytest execution, but projection plus validation remains bounded at \(4.96\%\) of end-to-end runtime. Thus ATP safety is not free, but the artifact exposes where its implemented infrastructure cost appears. Together, RQ2 and RQ4 report the safety result and the local artifact overhead audit; they do not establish production-scale throughput or a product-level comparison against a deployed workflow engine.

5.6 RQ5: Is Reactive Repair Contained, and Safe Under Recovery-During-Recovery?↩︎

RQ1 shows reactive repair stays safe end-to-end; here we ask how contained it is, then whether recovery during recovery stays safe. The Bounded Reactive Repair guarantee (Proposition 1) promises a repair confined to a bounded edit radius, and containment is only meaningful on a workload where a single disruption can ripple across many dependent operations. We therefore measure it on the job-shop instances of REALM-Bench [18] using a companion scheduling harness (MAPLE) that implements the same bounded-repair protocol as Mnemosyne’s reactive-repair path. After computing a feasible baseline schedule, we inject a single machine breakdown and recover it two ways under the same disruption and seeds: LCRP, the bounded localized repair, edits only the affected region under the displacement budget \(\delta_{\max}\) and iteration cap \(K\); global recompute re-solves the instance from the disruption point with no localization. Both must end feasible. Because raw makespan alone rewards a global reset that is physically expensive on a shop floor, we score repair under a cost-aware objective that also charges for disturbance, \[J = \Delta C_{\max} + \underbrace{\lambda_o N_{\mathrm{ops}} + \lambda_j N_{\mathrm{jobs}} + \lambda_w N_{\mathrm{wip}} + \lambda_s N_{\mathrm{setup}}}_{H},\] counting edited operations, touched jobs, work-in-progress moves, and machine-sequence (setup) changes, with \(\lambda_o{=}1,\;\lambda_j{=}5,\;\lambda_w{=}1,\;\lambda_s{=}10\) as a sensitivity model that weights job and setup disturbance above a single operation shift.

3.2pt

Table 10 reports medians and means over six instances; both policies recover feasibility (\(6/6\)). The contrast is the containment story behind Proposition 1. Global recompute wins on raw makespan (it is free to rebuild unfinished work, so \(\Delta C_{\max}\) is large and negative), but it disturbs the whole shop to do so, editing \(59.8\) operations on average against LCRP’s \(7.2\) (\(12.0\%\) as many, and about \(4\%\) at the median), touching all \(8\) jobs against LCRP’s \(1.8\), and moving \(59.8\) in-progress operations against LCRP’s \(7.2\). LCRP holds the median makespan exactly (\(\Delta C_{\max}=0\)) while keeping edit radius and WIP disturbance an order of magnitude smaller, and its cost-aware objective \(J\) is lower in both the mean (\(58.0\) vs.\(161.8\)) and the median (\(53.5\) vs.\(125.0\)). This is the empirical face of bounded reactive repair: a disruption is contained to its neighborhood instead of triggering a global reset, at equal feasibility and equal-or-better makespan where it matters. When the extra makespan headroom is genuinely worth the disturbance, the runtime can still escalate to a global recompute; the point is that ATP does not pay that cost by default.

Recovery during recovery. The hardest reactive case is a failure that arrives while a repair is still in flight, and we ask whether nesting introduces any new way to corrupt committed truth. By construction it cannot. ATP keeps no recovery stack: after the most recent restore point \(S_k\) it maintains a pending-observation set \(D_k\) of unabsorbed disruptions and validates every repair candidate against \(S_k\), \(\mathcal{C}\), and all of \(D_k\), so a failure arriving mid-repair is simply appended to \(D_k\) and recovery restarts single-shot from \(S_k\). Proposition 3 states the consequence: recursive recovery is exactly sequential recovery over the accumulated observations, every committed transition stays \(\mathcal{C}\)-feasible at any nesting depth and failure timing, and a sequence of \(F\) failures terminates in at most \(FK\) rounds before success or escalation. Empirically, the only way a mid-repair failure could commit invalid state is an in-flight repair that mutates outside admission, and that path is already covered by RQ1: every repair, nested or not, is an ordinary proposal subject to AuthorityBench and ObligationBench, so a wrong or interrupted repair is rejected exactly like any other proposal. We therefore report recovery-during-recovery as validated by construction and by the existing safety suite, and flag a dedicated stress harness (injecting failures at controlled depths and measuring realized round counts against the \(FK\) bound and the escalation frequency) as in-progress empirical work.

5.7 Artifact Availability and Reproducibility↩︎

The executable artifact is a tagged GitHub snapshot [19]: https://github.com/eyuchang/Mnemosyne/tree/arxiv-atp-rq1-rq9b-r8-v2. The default reproducibility path is PostgreSQL-free and runs the safety experiment files with pytest (expected result 9 passed). Full validation commands, the RQ4 infrastructure-cost benchmark, and the optional environment-gated PostgreSQL path (MNEMOSYNE_POSTGRES_DATABASE_URL) are described in the artifact README.

6 Related Work↩︎

Transactions, recovery, and input validation. A classical transaction provides the ACID guarantees (atomicity, consistency, isolation, and durability) over a submitted unit of work, together with concurrency control, logging, and recovery, with ARIES the canonical write-ahead-logging design [1]–[4]. ATP is complementary: ACID governs how an admitted unit of work commits, whereas ATP governs whether an untrusted generated action should be admitted as a transaction at all. Schema checks and integrity constraints reject malformed commands from a trusted application, whereas ATP distrusts the generator itself and adds the effective-state witness, evidence preservation, obligation containment, and serial-equivalent generative concurrency, none of which a per-command predicate expresses.

Compensation and event sourcing. Sagas decompose long-running transactions into compensatable subtransactions [5], and event sourcing and CQRS separate an append-only history from read-side projections [20], [21]. Mnemosyne adopts both separations but adds constraints they do not: compensation must be dependency-closed over effective state and must itself pass admission, and StateView is the effective-state witness the gate reads rather than a mere read model, because ATP targets generated proposals that may be hallucinated, stale, or adversarial rather than commands already granted authority.

Active databases and provenance. Active database systems attach event-condition-action rules to database events [22]; ACRs are deliberately weaker, waking a continuation and constructing a proposal but unable to mutate committed truth, which is the basis of obligation containment. Provenance and scientific-workflow systems record lineage for audit [6], [23]–[25]; ATP uses provenance-like evidence for a stronger admission condition, since a repair cannot discharge its own trigger by destroying the evidence that justified it, making evidence part of the safety contract rather than only explanatory metadata.

Workflow engines and LLM agents. Workflow engines provide retries, timers, task graphs, and durable execution [7], [16], [17], [26], [27], and LLM-agent research improves generation, tool use, reflection, memory, and multi-agent simulation [9]–[14], [28]. ATP treats both as proposers or drivers: engines may schedule, retry, and wake, and an agent’s reasoning trace, tool call, or memory retrieval is evidence, but neither owns committed truth, which changes only through admission.

Relationship to SagaLLM. SagaLLM [8] and ATP pursue trustworthy multi-agent LLM execution from opposite ends. SagaLLM brings transactional discipline to the agent, wrapping multi-agent planning in the saga pattern with persistent memory, validation agents, and compensating transactions. ATP works from the data-management end: a generated action holds no authority until a deterministic gate admits it, and committed-state correctness is provably independent of the proposing layer (Theorems 1–4). The two are complementary: one disciplines the proposer, the other lets the transaction layer accept untrusted proposers under one admission boundary. On the failures SagaLLM documents, the contrast is concrete: a canceled flight that leaves a hotel active is a dependency-closed compensation the gate refuses if it would orphan an effective dependent; a replan that drops a satisfied constraint is a stale-world rejection against the effective-state witness; and a repair that hides the violated constraint is blocked by evidence-preserving repair. Beyond this duality, ATP contributes the effective-state projection, the safety theorems at the transaction layer, and a complete runtime; preventive or self-improving recovery is left to future work.

7 Conclusion↩︎

Agentic workflows need transaction systems that do not trust generated actions: an LLM, solver, or agent may propose, but a generated proposal is not committed truth. Our central claim is authority separation: relative to a declared executable constraint set \(\mathcal{C}\) and a gate-closure assumption, proposer behavior affects proposal usefulness, not the ability to append committed truth. We formalize four safety properties of this boundary (authority separation, serial-equivalent generative admission, evidence-preserving repair, and obligation containment), add reactive local repair whose proposals re-enter the same gate, and implement them in Mnemosyne. The reproducible artifact exercises nine safety tests, a cost audit, and a disruption-containment study in which bounded local repair edits an order of magnitude fewer operations than global recompute: ATP rejects the specified violations while still admitting valid work, at modest overhead. Production deployment, a live-LLM quality study, a third-party workflow benchmark, and cross-episode learning, regret, and preemptive planning remain future work [29], [30]. ACID protects admitted transactions; ATP protects admission into committed truth.

Limitations↩︎

ATP’s guarantees are relative to \(\mathcal{C}\): hazards outside \(\mathcal{C}\) are undetected, and writing a faithful \(\mathcal{C}\) is itself work. RQ2’s guardrail comparator is implemented in the artifact, not benchmarked against a deployed workflow engine; the proposer-quality experiments use deterministic adapters that replay live-model failure modes, so results are reproducible while authority separation holds for any proposer. The artifact does not statically verify that no path bypasses admission, and RQ4’s overhead is a local audit, not a production load test.

Distributed execution. The evaluation runs against a single durable store, which is the linearization point for committed truth: each tenant and conflict scope has one authoritative CTL, so the authority boundary is well defined within a store even when proposers, solvers, and orchestrators are distributed. External orchestration engines such as Temporal drive execution but never hold commit authority (Appendix 16); under network partitions or worker-node failure they re-drive activities at least once, and the operation idempotency key together with the outbox deduplication boundary make replays converge to a single committed transition and a single external effect rather than duplicating either. What we do not yet evaluate is multi-region or sharded operation, where committed truth would span several stores: maintaining serial-equivalent admission and outbox idempotency across asynchronous cross-region updates would require partitioning conflict scopes across stores or a shared consensus log, which, with production-scale load testing, we leave to future work.

8 Per-Property Safety Results↩︎

This appendix gives the full per-class result tables for the six safety hazard classes summarized in RQ1 (Section 5.2) and visualized in Figure 5; each compares Mnemosyne against the deliberately permissive baseline(s) for that class. Table 11 reports AuthorityBench: a raw-append baseline and a self-validation baseline each commit \(35\) invalid generated transitions, while ATP commits zero and still admits the five valid proposals. Table 12 reports SerialAdmissionBench: under \(80\) concurrent proposals over a shared capacity object, the unserialized and weak-lock baselines commit invalid proposals and underflow capacity, while ATP commits only the \(32\) valid proposals through a serialized boundary and yields a serial-equivalent history. Table 13 reports EvidenceRepairBench: the naive-repair and no-rule workflow baselines each commit \(20\) evidence-destroying repairs, while ATP commits zero and still admits the eight valid repairs. Table 14 reports ObligationBench: the trigger-direct and timer-direct baselines commit \(12\) and \(16\) unauthorized wakeup mutations, while ATP routes every wakeup through ordinary admission and commits zero. Table 15 reports CompensationProjectionBench: the projection baselines admit five invalid compensations and produce seven StateView mismatches, while ATP produces zero and still commits the two valid compensations. Table 16 reports StorageSubstrateBench: the unconstrained log commits \(64\) invalid storage attempts and one StateView mismatch, while the ATP storage path rejects all \(64\) with zero mismatches.

4pt

3.5pt

4pt

4pt

3.5pt

9 Coverage Audit: ATP and a Production Transaction-Processing Substrate↩︎

This appendix extends the RQ2 comparator (Table 6) with a third layer: a production transaction-processing (TP) substrate such as PostgreSQL. ATP is not a replacement for production TP. PostgreSQL-style systems provide the durable substrate, with atomicity, isolation, durability, uniqueness, foreign keys, checks, triggers, and serializable execution. ATP is complementary: it governs whether a generated proposal should receive transaction authority before it becomes an ordinary transaction. The distinction matters because several agentic hazards are not storage-level violations unless application developers manually encode ATP-specific semantics.

Table 17 is an analytical coverage audit, not a throughput benchmark: each entry is a by-design assessment of which layer naturally owns the corresponding check. “App-only” means the TP substrate can enforce the property only if the application explicitly encodes the ATP-specific rule; “partial” means the mechanism catches one implementation of the hazard but not its general ATP form.

4pt

The audit identifies a layer boundary rather than a weakness in PostgreSQL or other TP systems. Production TP systems are strong commit substrates, but they do not by themselves define which generated proposal should be granted transaction authority. ATP adds StateView-based admission, retained-evidence checks, dependency-closed compensation, non-authoritative ACR wakeups, and generative conflict scopes before a proposal becomes a transaction; once a proposal is admitted, ATP relies on a production TP substrate for atomic commit, durability, uniqueness, and isolation.

An executable version of this audit (ProductionTPComparatorBench) is future work. It would run the same cases through (i) a PostgreSQL-style TP substrate with keys, foreign keys, checks, triggers, and serializable transactions; (ii) a workflow/saga guardrail layer; and (iii) ATP/Mnemosyne over the same durable store. The expected systems claim is not that production TP is weak, but that ATP supplies the missing authority semantics for generated proposals.

10 R8 Deployment Smoke-Load Variability↩︎

R8 implements a deployable Mnemosyne service boundary with health, proposal-submission, StateView, and metrics endpoints. The purpose of the R8 smoke-load audit is not to claim production-scale throughput, but to check that the deployment service preserves ATP’s authority-separation rule under concurrent HTTP proposal submission: clients may submit proposals, but invalid proposals and explicit bypass attempts must not become committed truth.

Table 18 reports two consecutive local runs of the same deployment load script. Each worker setting submits 200 HTTP proposal requests. The workload contains 120 valid proposals and 80 invalid or bypass proposals. In both runs, every worker setting admits exactly 120 proposals, rejects exactly 80 proposals, and produces zero invalid commits. Thus the safety result is stable across repeated local runs.

The throughput measurements are intentionally treated as diagnostic rather than production evidence. The 16-worker setting shows substantial run-to-run throughput variability despite similar \(p_{50}/p_{95}\) request latency, indicating sensitivity to local client scheduling, socket backlog, and short-run wall-clock effects. We therefore use R8 only as deployment-boundary evidence: concurrent HTTP submission preserves the ATP admission boundary, while production load testing over durable PostgreSQL storage, Kubernetes workers, networked workflow services, and pool saturation remains future work.

4pt

11 Mnemosyne Architecture and Runtime Data Structures↩︎

This appendix specifies the runtime data structures that realize the architecture of Section 4 at the level of record fields. The intent is to make the authority boundary inspectable: every object below is either committed truth, a projection of committed truth, a durable obligation, or an external boundary, and no proposer-side object can become truth except by passing admission.

11.0.0.1 Object taxonomy.

Mnemosyne keeps four kinds of object apart, and logs only the last. An event is an immutable observed fact (for example, a provider confirmation or a disruption notice). A candidate is a proposed finite-state transition that an admitted commit may or may not produce. A constraint evaluation is a predicate that the admission validator checks. A committed transition is the durable record of an admitted transition: a CTL record. Events, constraints, and finite-state structure live outside the CTL; only an admitted, committed transition is a CTL record. A vetoed or rejected proposal leaves a queryable rejection or escalation entry, never a committed transition.

11.0.0.2 The committed-transition log record.

A CTL record is the unit of committed truth. Its identity and ordering fields are fixed; its recovery metadata and domain evidence are carried in two typed side-channels, the metadata map \(M\) and the typed extension \(X\), so that recovery and provenance fields can evolve without changing a transition’s identity. Table 19 lists the fields.

The storage layer enforces two uniqueness constraints that carry the safety load: rid is the primary key, so a retried commit cannot double-apply, and (eid, fsm, version) is unique, so each entity has exactly one ordered history. The saga group tx_group_id is indexed but deliberately not unique, so one saga spans many records. The metadata map \(M\) carries the recovery and audit fields, including status (one of active, compensated, or superseded), restore (whether the record is a clean restore point), and the compensates or supersedes links naming the rids a record reverses or replaces. The typed extension \(X\) carries domain attributes (location, ETA, deadline, route, assignment) and causal-audit evidence; \(X\) is schema-validated rather than free-form.

11.0.0.3 Identity and log position.

Mnemosyne keeps three identities distinct rather than collapsing them into one: the individual entity eid, the role-binding binding_id, and the session or instance workflow_id. Conflating them breaks repeated participation (one entity acting twice), multi-party instances (one session with several participants), and reassignment (a resource re-bound to a new role). Independently of the wall-clock timestamp, the store assigns a monotonic log_position that provides total append ordering for replay and recovery; replay can proceed by per-entity version or by global log_position. The recovery-event log records the fine-grained events of repair and obligation execution (packages created, idempotency keys observed, sequence positions assigned, conflicts detected, outcomes accepted or rejected). In the PostgreSQL substrate, tenant-scoped uniqueness over event identifiers, idempotency keys, and recovery sequence positions provides the concrete concurrent-idempotency boundary.

11.0.0.4 StateView: the effective-state projection.

StateView exposes current operational truth. It is reconstructed from the CTL by replaying only effective records: records that have not been compensated, superseded, or invalidated and whose dependency chains remain effective. Current state is derived, never stored. Beyond the bare finite-state value, a StateView for an (eid, fsm) pair folds the \(X\) attribute deltas forward (location, ETA, deadline, route, assignment) and carries the set of effective records that support it, so that admission and the reactive loop read where each entity currently is, not a static plan. The projection is materialized per (eid, fsm) and is a cache: replay from the CTL remains the source of truth. A cross-entity correction must re-project every affected entity, because refreshing only the issuing entity could leave a now-ineffective record lingering as current truth elsewhere.

11.0.0.5 Active commitment records.

An ACR is a durable workflow obligation stored in the same committed substrate as ordinary transitions. It is created by an admitted step, and creating it is itself an admitted transition. An ACR records an assumption or commitment together with the fields in Table 20. When its trigger fires, the runtime may resume the continuation to construct a repair proposal, but the ACR itself cannot mutate committed state: its wakeup re-enters the ordinary admission gate. ACR status moves through values such as live, fired, proposed, admitted, rejected, compensated, expired, and discharged.

11.0.0.6 Inbox and outbox boundaries.

External events enter through an inbox deduplication boundary; external side effects leave through an outbox boundary that stages provider calls with idempotency keys. The outbox is an intent log: provider execution remains outside committed truth until its result is observed and admitted as a subsequent transition. This prevents a domain commit from silently becoming an external effect, and prevents a duplicate external observation from creating a duplicate commit. Both boundaries sit on the commit side of the authority line but neither owns truth: the inbox only deduplicates inbound observations, and the outbox only stages outbound intent.

12 Admission, Commit, Logging, and Replay↩︎

This appendix gives the deterministic admission contract under \(\mathcal{C}\) and the commit, logging, and replay sequence at the mechanism level. The contract is independent of proposer identity: an LLM, solver, runtime driver, benchmark adapter, or ACR wakeup may change the proposal package, but only the ordered admission steps can create committed truth.

12.0.0.1 The admission contract.

Admission is the deterministic pre-commit procedure that decides whether a proposal may become a committed transition. It reads current effective state from StateView and retained evidence, never speculative or rejected proposal history, and applies the ordered checks below. Steps 1–8 are the executable contract used by the implementation and the RQ1–RQ5 experiments.

1. Parse the proposal package and reject malformed packages before commit processing begins.

2. Check tenant, entity, idempotency key, operation key, and declared conflict scope.

3. Read current StateView and retained evidence; do not validate against speculative or rejected proposal history.

4. Apply the deterministic constraints in \(\mathcal{C}\): finite-state rules, policy rules, stale-world checks, dependency closure, and compensation safety.

5. If the proposal is a repair, require that the underlying failure is resolved under \(\mathcal{C}\), or that the trigger evidence remains effective and queryable after the repair.

6. If the proposal is an ACR wakeup, require a proposal package and forbid direct mutation of the CTL or StateView.

7. Serialize or reject overlapping incompatible conflict scopes; admit only if the resulting transition is valid over current effective state.

8. Atomically append the admitted transition and recovery metadata to durable storage and update StateView; otherwise record a queryable rejection reason.

A solver certificate or LLM rationale is treated as evidence supplied to these checks, not as authority. The validator reads log-grounded effective state only: a finite-state edge is checked for legality with action_type disambiguating self-loops; each dependency is required to be committed and still effective (existence alone is insufficient); and application constraints are keyed by (fsm, action_type) so that, for example, a pickup may be required to follow the driver’s arrival as read from the driver’s effective state. The gate returns an admitted transition, a rejected proposal with structured reasons, or an escalation request for a wider scope.

12.0.0.2 Commit, logging, and projection.

An admitted proposal commits through a single atomic step that also produces the projection update. The commit batch is the unit of multi-entity atomicity. In one transaction it: locks the affected entities in sorted key order, verifies the expected monotonic version for each (eid, fsm), re-checks that every dependency in \(D\) is committed and effective, appends all CTL rows, updates the synchronous StateView projection for every affected key, and stages any outbox intents. Three guarantees hold exactly at the write: idempotency (the rid primary key, with op_id as the client key when rid is server-assigned), ordering (the monotonic per-entity version), and dependency effectiveness (\(D\) committed and not since compensated or superseded). Only after this step does a row exist; a rejected proposal yields a queryable rejection, not a row.

12.0.0.3 Idempotency and retry safety.

Because durable runtime drivers execute steps at least once, the commit path must be idempotent under retry. The rid primary key (or op_id when rid is server-assigned) makes a retried commit return the existing committed record rather than duplicate domain truth. This is why the idempotency key is part of the proposal package and is checked at Step 2 before any state mutation: a retried submission after a crash or timeout resolves to the same committed transition, so the commit batch is safe to re-drive.

12.0.0.4 Replay.

The CTL is the source of committed truth, and current state is recovered by replay rather than read from a stored cursor. Replay of an (eid, fsm) history proceeds in order and self-checks consistency: each record’s state_before must equal the prior record’s state_after, and a mismatch is a replay error that signals log corruption. The bare replay yields the finite-state value; the full reconstruction is the StateView that additionally folds the \(X\) attribute deltas forward and retains the effective records supporting the state. Because compensation and supersession are themselves later admitted transitions, effective-state replay reproduces current truth without deleting history or moving a cursor: the effective index marks which records still count, and the projection excludes the rest.

13 Disruption, Recovery, and Compensation↩︎

This appendix specifies recovery at the mechanism level. The central property is that recovery does not bypass admission: a disruption, a fired obligation, or a crash-recovery action produces a proposal that passes through the same gate as any generated action. Recovery decisions are made in the proposal and policy layers; the substrate supplies only the mechanism and the invariants.

13.0.0.1 Obligation wakeups do not bypass admission.

When an ACR trigger fires, the runtime may resume its continuation and construct a repair proposal, but the wakeup carries no write authority. The resumed proposal declares the ACR’s bounded dependency scope and re-enters the ordinary admission gate, where Step 6 requires that an ACR wakeup supply a proposal package and forbids direct mutation of the CTL or StateView. A proposal generated by an ACR may touch only the dependency scope recorded by that ACR, unless a wider scope is explicitly admitted as an escalation. Thus a fired obligation can only return the system to the proposal-admission path; it cannot install committed truth on its own. Rejected or compensated ACR proposals with matching failure signatures remain queryable as historical evidence for future ranking or guard strengthening, which is how memory becomes active without becoming authoritative.

13.0.0.2 Three recovery moves.

The class of an action against the full governed-invariant set, re-checked at commit time, selects the recovery move; the substrate supplies the mechanism and the policy layer supplies the timing. Table 21 states the three moves. A restore (return to a clean checkpoint) is the bulk form of an undo: it resets state but, unlike an exact undo, does not reverse external effects, so it is paired with compensation.

13.0.0.3 Dependency-closed compensation and supersession.

Compensation is represented as a new admitted transition, never as physical deletion, and the whole saga group identified by tx_group_id unwinds together. The group is compensated in reverse topological order over the group’s dependency subgraph, not merely reverse insertion order, so a leg is never compensated before the legs that depend on it. Admission enforces dependency-closed compensation through the recovery invariants: a compensation is rejected if it would leave an effective record depending on an ineffective record (no orphaned effective dependents), and a compensation is rejected if it would break the effective chain for an entity (effective-chain preservation). Supersession is the related operation by which a later admitted transition replaces an earlier one through the supersedes link in \(M\); like compensation, it changes effectiveness without erasing history.

13.0.0.4 Effective-chain preservation under cross-entity correction.

Compensation and supersession never delete history; they only change which records are effective. Because the projection is materialized per (eid, fsm), a correction that touches several entities must drop the corrected record from current truth on every entity it touches, not only the entity that issued the correction. Refreshing only the issuing entity would let a now-ineffective record linger as current truth elsewhere. Replay from the CTL therefore remains the source of truth, and the per-entity projection is rebuilt for all affected keys after a correction.

13.0.0.5 Evidence-preserving repair.

A memory-initiated repair must not discharge its own trigger by deleting, overwriting, compensating, or obscuring the evidence that justified it. Admission permits a repair to alter trigger evidence only if it verifies, under the retained evidence and validator rules, that the proposed repair addresses the triggering condition rather than merely suppressing its observable signal (Step 5). Concretely: let a repair proposal be triggered by evidence \(E\) of a failure condition \(F\). Admission admits the repair only if either \(F\) is resolved under \(\mathcal{C}\), or \(E\) remains effective and queryable after the repair. As a result, no admitted repair can clear its own trigger by destroying the evidence that caused it, and a repeated failure remains visible through its failure signature for later analysis.

13.0.0.6 Crash recovery as invariants in reverse.

A transactional fault, such as a crash mid-leg, is handled with the same mechanisms. Recovery locates the most recent record marked as a clean restore point, appends compensating transitions for the saga groups committed after it in reverse topological order (marking them compensated), and resumes the reactive loop from the resulting effective state. Nothing is deleted and no cursor moves: the original records remain for audit, and effective-state replay yields current truth because each compensation is itself a later committed transition. Recovery is thus the ordinary commit invariants (idempotency, monotonic versions, dependency effectiveness) run in reverse under a policy.

14 Staged Implementation (R0–R8) and Reproducibility↩︎

This appendix records the staged build of Mnemosyne and the reproducibility path. The build follows a small-to-large discipline: a visible, auditable correctness kernel is established before scale-out infrastructure is connected, so that the authority boundary (the central claim) is not obscured by an external engine or solver. Table 22 lists stages R0 through R8 and their status. The deployment service boundary (R8) is now complete: a deployable service with health, proposal-submission, StateView, and metrics endpoints is implemented and audited for authority separation under concurrent HTTP submission (Appendix 10).

14.0.0.1 Default reproducibility path.

The default reproducibility path is PostgreSQL-free and deterministic. It runs the nine executable safety experiment files directly with pytest; the expected result is 9 passed. These nine experiments correspond to the safety properties evaluated in RQ1–RQ4 and the mechanism-level comparator: authority separation, serial-equivalent admission, evidence-preserving repair, obligation containment, effective-state and compensation safety, storage-substrate correctness, the J1–J4 end-to-end execution, proposer-quality safety invariance, and the workflow/saga guardrail comparison. A broader safe command additionally runs tests/core, tests/apps, and tests/benchmarks. Reviewers should not run all of tests/experiments as a blanket command, because older exploratory imports outside the ATP artifact path are intentionally excluded from the reproducibility suite.

14.0.0.2 Infrastructure-cost benchmark (RQ4).

The cost audit is run as a separate infrastructure-cost benchmark over selected real infrastructure tests rather than as a violation-suppression experiment. It reports end-to-end, admission, and commit latency, projection-plus-validation overhead, and throughput at one, four, and eight workers; projection plus validation remains bounded at under \(6\%\) of end-to-end runtime. The benchmark script that generates the RQ4 table is included in the artifact alongside ARTIFACT_EVALUATION.md, which lists the exact safety validation command and expected reports.

14.0.0.3 Optional live PostgreSQL path.

The live PostgreSQL path for the storage-substrate experiment is optional and environment-gated by the MNEMOSYNE_POSTGRES_DATABASE_URL variable, with an optional connection-pool dependency. When supplied, it validates recovery-event append and list operations, canonical duplicate-idempotency behavior, clean sequence-conflict handling, and pooled connection use. The artifact claim does not require a live database: default CI remains PostgreSQL-free and pool-dependency-free, so the 9 passed result reproduces without any database setup.

15 Structure and Scalability of the Constraint Set \(\mathcal{C}\)↩︎

A natural objection is that ATP merely moves the correctness burden from the agent prompt into the validator: if every semantic rule must be hand-coded, \(\mathcal{C}\) does not scale. In the implementation most of \(\mathcal{C}\) is not hand-coded per case. Its rules fall into three classes (Table 23).

1. Structurally derived. Generated mechanically from declarations the application already maintains. Finite-state legality is derived from the per-entity transition table keyed by action_type; dependency effectiveness and compensation closure are derived from the effective-chain over CTL; idempotency and conflict scope are derived from the record’s identity triad. No per-rule code is written.

2. Declarative predicates. Declared once as data, not procedures, and checked by a generic evaluator: schema and type constraints, required-evidence handles, world-fact freshness keys, and conflict-scope keys.

3. Application validators. The only genuinely hand-written part: domain semantics that cannot be derived or declared (for example, a capacity rule specific to one operation). In the artifact these are a small minority of the constraint surface.

4pt

A proposal package is admissible when it satisfies the conjunction of all applicable constraints, which in grammar form is:

admit(p)       := structural(p) AND declarative(p) AND validators(p)
structural(p)  := fsm_legal(p) AND deps_effective(p)
                  AND compensation_closed(p) AND idempotent(p)
                  AND scope_consistent(p)
declarative(p) := schema_ok(p) AND evidence_present(p)
                  AND world_fresh(p)
validators(p)  := conjunction of application-declared predicates

Because the structural and declarative classes are generated from declarations the application already keeps (entity FSMs, the dependency model, the schema), adding a new operation typically extends \(\mathcal{C}\) by declaration rather than by new validator code. That is what keeps the admission boundary scalable as an application grows, and it bounds the hand-written surface to genuine domain semantics.

16 Workflow-Engine and Storage-Substrate Selection↩︎

This appendix records the substrate selection and its rationale. The governing principle is that the substrate is non-authoritative: a workflow engine or storage backend may change deployment scale, availability, or throughput, but it must preserve the ATP authority boundary. Committed truth is produced only by admitted transitions, regardless of which engine orchestrates the work or which store persists the log.

16.0.0.1 Why the substrate is non-authoritative.

Mnemosyne separates orchestration from authority. Runtime drivers schedule work, fire timers, retry steps, and wake obligations, but they do not own committed truth: a driver may detect that an ACR is ready, call a proposal provider, submit a package, and record a deterministic summary, yet it may not directly mutate domain truth. Keeping the source of truth in the CTL rather than in engine-internal state is a deliberate design fork. Letting the engine own state would tie the design to one engine and weaken the validator’s evidence story, because admission reads the effective-state projection rather than engine-private execution history. Holding the authority boundary in the admission gate is what lets a deployment substrate change without changing the correctness semantics.

16.0.0.2 Two-tier, PostgreSQL-anchored recommendation.

The deciding requirement is a true ACID store with snapshot isolation, which PostgreSQL provides natively through MVCC. The recommendation is therefore a PostgreSQL-anchored two-tier substrate: a Postgres-backed durable-execution and transaction core that hosts the CTL, the effective-state projection, and the recovery-event log in one store, with a compute fan-out tier layered beneath it for concurrent proposal and probe execution. The durable tier supplies transactional bookkeeping and a measurable commit-failure rate; the compute tier supplies node-count scale. In the reference implementation the store protocol admits SQLite as the deterministic default for local development and CI and PostgreSQL (and pooled PostgreSQL) as optional, environment-gated live-validation paths (Figure 7). The scalability and Kubernetes deployment phase is a deployment concern that may add containerized services, durable-workflow workers, orchestration, observability, and load tests; it changes deployment scale, not ATP correctness semantics.

16.0.0.3 Durable-execution survey: interop targets, not authority.

The 2025–2026 durable-execution category provides persistence, retries, and exactly-once or ACID semantics as infrastructure, and Mnemosyne builds the CTL and the ATP layer on top of such an engine rather than reimplementing logging or recovery primitives. Table 24 summarizes the engines considered. They are treated as interoperability or deployment targets behind an engine-agnostic interface, not as the authority for committed truth: durable workflow engines such as Temporal and Cadence orchestrate execution but are non-authoritative, and Argo Workflows is retained as a Kubernetes deployment and export target rather than a transaction engine. Checkpoint-persistence agent frameworks are explicitly excluded as the transactional substrate, because checkpoint persistence is not durable execution with exactly-once or ACID guarantees; they may serve only as optional agent-authoring layers above a real durable engine.

16.0.0.4 Engine portability.

The durable-execution core sits behind an engine-agnostic interface so that the choice of orchestrator is a contained substitution. The Temporal-style boundary makes the contract concrete: the workflow layer is deterministic and side-effect free (timers, timeouts, retries, signals), while the activity layer performs the side effects (validate the commit batch, build the CTL records, commit, reproject StateView, stage outbox). The workflow orchestrates and the activity commits, but the store and CTL own truth. Because activities execute at least once under a retry policy, the op_id idempotency key makes a retried activity return the existing committed record rather than duplicate domain truth. This portability is why the same authority boundary holds whether the orchestrator is a local driver or a durable workflow engine, and why a change of engine does not change the safety properties proved in the main text.

17 Worked Proposal Examples↩︎

This appendix makes the proposal is not truth boundary concrete. The examples use compact JSON-like records to show what crosses the proposal boundary and what the admission gate does before anything becomes committed truth. They are illustrative but match the implementation contract used throughout the artifact: a proposal package carries a tenant, entity, operation, dependency set, world assumptions, conflict scope, evidence handles, and an idempotency key. Admission evaluates the package against the current effective StateView, retained evidence, and the declared constraint set \(\mathcal{C}\). Two axes matter independently: whether the proposal is well formed, and whether the committed output it would produce is \(\mathcal{C}\)-valid.

17.1 Valid Proposal↩︎

A valid proposal may come from an LLM, solver, workflow driver, or active commitment wakeup. The proposer supplies a candidate action, but the candidate stays non-authoritative until admission accepts it.

{
  "proposal_id": "p_valid_hotel_001",
  "tenant": "t1",
  "entity": "trip_17",
  "operation": "book_hotel",
  "depends_on": ["flight_f1"],
  "world_assumptions": {"flight_f1_status": "confirmed"},
  "conflict_scope": "t1/trip_17/lodging",
  "evidence": ["user_request_e1"],
  "idempotency_key": "book_hotel_trip17_once"
}

Admission result. Accepted. The referenced flight remains effective in StateView, the world assumption is current, no incompatible proposal occupies the lodging conflict scope, and the idempotency key is fresh.

Committed effect. The admitted hotel-booking transition is appended to the committed-transition log (CTL); StateView projects the booking as effective current truth; a confirmation message may be staged in the outbox under its own idempotency key.

17.2 Invalid Proposal↩︎

The next proposal is syntactically well formed but semantically stale. A classical parser would accept the record; ATP rejects it before commit because its assumptions disagree with observed effective state.

{
  "proposal_id": "p_stale_hotel_002",
  "tenant": "t1",
  "entity": "trip_17",
  "operation": "book_hotel",
  "depends_on": ["flight_f2"],
  "world_assumptions": {"flight_f2_status": "confirmed"},
  "observed_world": {"flight_f2_status": "cancelled"},
  "conflict_scope": "t1/trip_17/lodging",
  "evidence": ["user_request_e1"],
  "idempotency_key": "book_hotel_trip17_once"
}

Admission result. Rejected. The proposal depends on a flight that is no longer effective under the observed world facts. The rejection is recorded with a durable reason, but no domain transition is appended.

Committed effect. CTL is unchanged with respect to domain truth, StateView is unchanged, and no external side effect is staged.

17.3 Valid Output After a Valid Proposal↩︎

A valid admitted proposal may create a valid outbox intent. The outbox record is not the external effect itself; it is an admitted intent to perform the effect under an idempotency key.

{
  "proposal_id": "p_notify_after_booking_003",
  "tenant": "t1",
  "entity": "trip_17",
  "operation": "stage_outbox_notification",
  "depends_on": ["hotel_booking_b1"],
  "message_type": "booking_confirmation",
  "recipient": "user_u1",
  "conflict_scope": "t1/trip_17/notification",
  "idempotency_key": "notify_trip17_booking_once"
}

Admission result. Accepted. The booking dependency is an effective committed fact, the outbox idempotency key has not been consumed, and no incompatible notification intent exists for the same scope.

Committed effect. CTL records the admitted outbox intent; StateView exposes the notification as staged; the provider call stays outside committed truth until its result is observed and admitted as a later transition.

17.4 Invalid Output After a Valid Proposal↩︎

Even after a valid domain proposal, a later output proposal can be invalid. Here an agent tries to charge a card twice by changing only the provider-level idempotency key while targeting the same committed payment obligation.

{
  "proposal_id": "p_duplicate_charge_004",
  "tenant": "t1",
  "entity": "trip_17",
  "operation": "stage_outbox_payment",
  "depends_on": ["hotel_booking_b1"],
  "payment_obligation": "hotel_booking_b1/deposit",
  "amount": "250.00",
  "conflict_scope": "t1/trip_17/payment/deposit",
  "idempotency_key": "pay_deposit_trip17_b1_once",
  "provider_idempotency_key": "new_key_but_same_obligation"
}

Admission result. Rejected (or escalated for reconciliation). The proposal targets an already staged or satisfied payment obligation under the same semantic conflict scope and obligation idempotency key. A changed provider key is evidence, not authority to create a duplicate external effect.

Committed effect. No duplicate outbox payment intent becomes current truth, and the rejected package remains queryable as evidence for audit or guard strengthening. Only the first and third proposals commit; the second and fourth are rejected with a durable reason, so committed-state correctness is independent of how the proposal was generated.

18 An End-to-End Transaction Trace↩︎

This appendix traces one disruption-recovery path through ATP, separating five objects that agentic systems often conflate: input observation, proposal package, admission decision, committed log record, and external side-effect intent. It continues the trip scenario of Appendix 17.

18.1 Input Observation↩︎

flight_cancelled(flight_f1)
source_event_id = flight_provider_event_e123
observed_at     = 2026-06-30T10:15:00Z

The input observation is evidence. It is not, by itself, a domain repair, and it grants no write authority to the proposer or the runtime driver.

18.2 Proposal Package↩︎

A planner or active commitment wakeup proposes a repair package:

{
  "proposal_id": "p_repair_trip_017",
  "tenant": "t1",
  "entity": "trip_17",
  "operation": "repair_trip_after_flight_cancellation",
  "depends_on": ["flight_f1", "hotel_h1"],
  "evidence": ["flight_provider_event_e123"],
  "conflict_scope": "t1/trip_17",
  "proposed_steps": [
    "compensate_hotel(hotel_h1)",
    "search_alternate_flight(trip_17)",
    "notify_user(user_u1)"
  ],
  "idempotency_key": "repair_trip17_after_flight_f1_once"
}

The proposal is not committed truth; it is a candidate package supplied to the admission gate.

18.3 Admission↩︎

Admission evaluates the package against \(\mathcal{C}\) and the current effective state:

checks:
  dependency closure:    hotel_h1 depends on flight_f1
  stale-world facts:     flight_f1 is observed cancelled
  compensation safety:   no effective downstream record is orphaned
  evidence preservation: flight_provider_event_e123 stays queryable
  conflict scope:        no active repair owns t1/trip_17
  idempotency:           repair_trip17_after_flight_f1_once is fresh

If all checks pass, the proposal is admitted; if any fails, the rejection and its reason remain durable, but the proposed repair does not become domain truth.

18.4 Committed-Transition Log↩︎

An admitted repair appends records such as:

CTL append:
  compensation_requested(hotel_h1)
  repair_proposal_admitted(trip_17)
  ACR_updated(trip_repair_obligation)
  recovery_metadata(...)

CTL is the source of committed truth. Compensation is logical: the earlier hotel record is not erased; it becomes ineffective only through admitted compensating transitions and effective-state projection.

18.5 StateView↩︎

StateView projects current effective truth from CTL:

StateView:
  flight_f1              = cancelled
  hotel_h1               = compensation_pending
  trip_17                = repair_in_progress
  trip_repair_obligation = live

StateView is not raw history: it excludes compensated, superseded, or otherwise ineffective records while preserving full CTL history for audit.

18.6 Outbox↩︎

External actions are staged rather than executed as hidden side effects of the planner:

outbox:
  notify_user(user_u1)
  idempotency_key = notify_trip17_repair_once
  status          = staged

An outbox intent is not the external effect itself. The provider call and its result stay outside committed truth until observed and admitted as later evidence, which prevents a generated proposal from silently turning into an irreversible external mutation.

18.7 Boundary Summary↩︎

Input observation is evidence, not committed repair. A proposal is candidate intent, not truth. An outbox intent is a staged effect, not external truth. Only admitted CTL records define committed truth, and StateView is the effective projection used for future admission.

References↩︎

---

1. We use workflow and transaction in their classical senses, not as synonyms. A workflow is a sequence of actions and state transitions enacted to accomplish a task; a transaction is a unit of work executed with atomicity, isolation, consistency, and durability guarantees, so “transactional” names a property of how a unit of work commits, not the action sequence itself. A generated workflow step becomes a transaction only when the data layer admits and commits it under these guarantees, and ATP governs precisely that boundary.↩︎