Session Execution Layer

Orchestration Lifecycle

Every session that enters QUORUM is a controlled execution unit. The orchestration layer manages session state across the nine-stage decision pipeline, enforces sequencing guarantees, handles concurrent session isolation, and ensures that every stage transition is logged before the next stage begins.

01
Nine-Stage Pipeline Sequence

Sessions transit nine discrete stages in strict sequence. Stage skipping is not permitted. Each stage records its entry and exit timestamps before handing off to the next stage. The cumulative latency budget from INTAKE to COMMIT is 50ms under normal operating conditions.

#
Stage
Function
Budget
Failure Posture
01
INTAKE
Receives raw event payload, validates schema, assigns session ID and intake timestamp.
2ms
Reject malformed
02
NORMALIZE
Maps event payload to canonical signal schema, fills missing optional fields with sensor defaults, validates field ranges.
3ms
Fill defaults
03
ENGINE
Runs behavioral analysis, computes entropy vectors, variance vectors, and session-to-entity deviation scores.
8ms
Degrade to heuristic
04
SCORE
Runs three-tier AI scoring across sentinel, inquiry, and adversarial validation tiers. Produces a composite risk score 0–100.
15ms
Sentinel-only fallback
05
ARBITRATE
Applies the rule precedence stack. Evaluates whitelist, blocklist, and heuristic rules in sequence against the score and signal vector.
5ms
Safe block
06
DISPATCH
Routes the session to the appropriate enforcement tier based on arbitration result and composite score band.
1ms
Default block
07
EVALUATE
Second-pass evaluation by the consensus engine. Reviews arbitration output against entity history and current session context.
5ms
Accept prior score
08
CONSENSUS
Multi-model quorum check for borderline decisions (composite score 35–65). Requires agreement across model ensemble before verdict is issued.
8ms
Accept prior score
09
COMMIT
Writes the finalized verdict and full event block to the audit ledger. Signs with FROST(Ed25519). Enqueues RFC 3161 TSA timestamp request.
3ms
Retry 3x then alert

Total pipeline budget: 50ms p50. TSA request is asynchronous and does not block session completion.

02
Session Isolation Model

Each session is assigned a unique session_id at INTAKE. Sessions share no mutable state. The rule engine evaluates each session against a read-only snapshot of the current rule set — no session can modify rule state. Model weights are never mutated during a session.

Signal Isolation

No session can observe another session's signal vector, score, or evaluation state. Sessions are evaluated in independent execution contexts with no shared mutable memory.

Scoring Isolation

Concurrent sessions cannot interfere with each other's scoring. The model inference layer is stateless per invocation — session A's score cannot influence session B's inference path.

Lifecycle Isolation

Session state is garbage collected after COMMIT completes. Ephemeral session data does not persist beyond the COMMIT stage. Only the audit ledger entry and verdict record are retained.

session {
  id:             uuid_v4()          // assigned at INTAKE, immutable
  rule_snapshot:  rule_set_ref       // read-only snapshot, never written
  model_version:  weight_hash        // immutable reference, never swapped mid-session
  signal_vector:  encrypted_blob     // isolated to session context
  state:          RECEIVED → FINALIZED
  gc_after:       COMMIT.complete    // ephemeral state cleared on commit
}
03
Concurrency Architecture

Pipeline stages run in strict sequential order within a session. Across sessions, the concurrency model is differentiated by stage: early pipeline stages parallelize freely; arbitration and consensus stages are serialized per-entity to prevent race conditions on entity state.

Parallelizable Stages
INTAKE — up to 10,000 concurrent
NORMALIZE — up to 10,000 concurrent
ENGINE — up to 5,000 concurrent
SCORE — up to 5,000 concurrent
Serialized Per-Entity Stages
ARBITRATE — serialized per entity_id
CONSENSUS — serialized per entity_id
COMMIT — serialized to ledger writer (Postgres WAL)
DISPATCH — stateless, parallelizes freely
Measurement Point
Throughput Target
Notes
INTAKE ingestion
10,000 sessions/sec
Schema validation parallelized
CONSENSUS throughput
2,000 sessions/sec
Only borderline decisions (35–65 score range)
Ledger commits
5,000 commits/sec
WAL-serialized; batching enabled at 500ms windows
04
Failure and Degradation Model

Each stage has a defined failure posture. Critical path stages halt on failure and return a safe-block verdict. Non-critical stages degrade gracefully, falling back to a simpler evaluation path. All degradation events are written to the audit ledger and are visible in the governance dashboard.

Critical Path Stages — Halt on Failure
INTAKE— malformed payload halts session, returns rejection
ARBITRATE— rule evaluation failure triggers safe block
COMMIT— ledger write failure retries 3x, then alerts on-call and halts
Non-Critical Stages — Graceful Degradation
ENGINE— behavioral analysis failure degrades to heuristic scoring
SCORE— full scoring failure degrades to sentinel-only tier
CONSENSUS— quorum unavailable accepts prior EVALUATE result
Degradation Hierarchy
FULL
All 9 stages active
HEURISTIC_ONLY
ENGINE unavailable
SENTINEL_ONLY
SCORE degraded
SAFE_BLOCK
Critical failure

All degradation transitions are logged to the audit ledger with the triggering condition, affected stage, and degradation tier entered.

05
Session Lifecycle State Machine

Every session progresses through a defined state machine. Error states are terminal — a session that enters an error state does not continue to subsequent stages. The error state, its triggering stage, and the error classification are recorded in the audit ledger before session termination.

RECEIVED
VALIDATING
PROCESSING
ARBITRATING
DECIDING
COMMITTING
FINALIZED
Error States
ERROR_VALIDATION — triggered from VALIDATING. Schema invalid or session_id collision.
ERROR_ARBITRATION — triggered from ARBITRATING. Rule engine unavailable. Verdict: safe block.
ERROR_COMMIT — triggered from COMMITTING. Ledger write failure after 3 retries. Alert escalated.