AXIS Documentation / Security / Transactions

Transactions

VerifiedNo long-lived open transactions

AXIS deliberately avoids holding an open database transaction across the policy decision or a human approval. This shapes retry semantics, evidence ordering, and what operators can expect after timeouts.

Decisions are out-of-band

Policy is evaluated before any database statement is dispatched; the decision does not depend on a transaction cursor.
Approval (REQUIRE_APPROVAL) never opens a DB transaction: the write is executed only on the explicit client retry with approval_id.
Open DB transactions are never held across human approval wait times.

Execution semantics

Stage	Behavior
Evidence before execution	Decision evidence is committed before dispatch; result evidence is appended after the outcome is known
Timeout after dispatch	`execution_state: unknown` is recorded — AXIS does not know whether the write applied; protected writes are not retried automatically
DB failure	Failure evidence is recorded; no silent success
Retry by client	Explicit and evidence-visible: each attempt is a separate audited event

Because there is no automatic retry, idempotency is a client responsibility: use natural keys, conditional writes, or unique constraints so an operator-driven retry cannot double-apply.

Read/write split

Safe reads go directly to PostgreSQL; protected writes go through AXIS. The split is intentional in the pilot integration: AXIS evidence covers the policy-controlled mutation path, not every read that bypasses the gate. Reads default ALLOW, writes default BLOCK, DDL REQUIRE_APPROVAL.

What AXIS does not provide

Distributed transactions or two-phase commit across approval boundaries.
Transaction-scoped policy decisions: there is no begin/evaluate/commit coupling; each request is evaluated independently.
Guaranteed "exactly once" execution: after an unknown state, verification is operator work.

Design writes to be retry-safe: a timed-out request may still have applied. Check the audit trail (execution_state) and the database before re-running.