VARUX AXIS Deterministic PostgreSQL Write-Path Control
v0.6 · Pilot Readiness
AXIS Documentation / Core Concepts / Request Lifecycle

Request Lifecycle

VerifiedPOST /query

Every request reaching POST /query follows the same deterministic pipeline: validate, parse, classify, evaluate policy, write evidence, decide. The decision is made before any execution-sensitive outcome.

The pipeline

1. Request to POST /query actor · app · tenant · role · host · env · sql 2. Validate request + limits schema · size · rate limit · optional JWT context 3. Parse SQL (PG dialect) fail-closed: parser errors → controlled rejection 4. Classify + extract signals operation · target · scope · fingerprint · risk signals 5. Evaluate active policy operating mode · policy_version · deterministic 6. Write decision evidence WAL · event_hash · previous_hash 7. Decide ALLOW REQUIRE_APPROVAL BLOCK 200 — execute via DB adapter decision evidence committed first → result evidence 202 — approval record + approval_id no execution · resolve · explicit retry 403 — structured error no database execution (BLOCK box shown at right)
Enforcement returns one of: 200 ALLOW, 403 BLOCK, 202 REQUIRE_APPROVAL, or a controlled 4xx/5xx failure.

Decision paths

DecisionSequence
ALLOWWrite decision evidence → execute through the PostgreSQL path → record execution result evidence → return response (200)
BLOCKWrite block evidence → no database execution → return controlled error (403)
REQUIRE_APPROVALCreate approval record → write approval evidence → no execution until valid resolution → return approval_id (202)

Validation failures reject the request with structured errors (invalid_json, empty_sql, multi_statement_rejected, parser_error, unsupported_sql_shape, ...). Multiple statements are rejected: the default policy blocks multi-statement payloads rather than evaluating them individually.

Prepared statement branch

AXIS handles prepared statements at the HTTP layer with a session_id-scoped in-memory session store — it does not blindly forward database-side PREPARE:

CommandBehavior
PREPARERequires session_id; classifies the inner SQL for risk context; registers AXIS-side metadata; writes audit evidence; does not forward database-side PREPARE
EXECUTERequires session_id; resolves the stored original SQL in that session; evaluates the original SQL through policy; fails closed when unresolved (cross-session, missing session, or after restart)
DEALLOCATE / DEALLOCATE ALLRequire session_id; remove AXIS-side metadata; write audit evidence

Allowed prepared EXECUTE is not blindly forwarded as raw PostgreSQL EXECUTE, because HTTP sessions do not guarantee pooled backend connection affinity.

Fail-closed points

Related: SQL Classification · Policy Engine · Audit & Evidence