Decision Execution

Every invocation of /decide (or the MCP equivalent per ADR-088) flows through five phases. The phases are sequential, bounded, and uniform across all decision modules; cost variance comes from per-phase content (which rules a module declares, how much context establishment a domain involves), not from phase structure.

Phase 1 — Authorization and request validation

Standard web-API request handling. The signed JWT (format per ADR-087 D1) is validated at the platform pillar’s auth gateway (per ADR-076 D4); authenticated_caller is resolved as the system_generated context attribute. The RFC 8693 act claim (shape per ADR-087 D2; session-mode disambiguation per ADR-081 D3) is parsed for delegation scenarios. Request body is validated against the /decide schema; missing required fields produce structured validation errors per ADR-006 D3.

Cost profile: light, typical web API.

Phase 2 — Action mapping and module load

The routing key (org_id, domain, action, world_model_version) resolves to a deployed decision module. The decision execution tier runs in-process inside the app container (ADR-109 D2; sandboxed per ADR-083) and checks its in-process cache for the module bundle:

• Cache hit: module is loaded; phase completes immediately.
• Cache miss: module bytes fetched from the module store; content-hash verification per ADR-080 D2; operator-approval verification per ADR-080 D3; module loaded into cache; subsequent requests for the same (org, domain, action, version) hit cache.

Cost profile: light steady-state (cache hit); medium first-load variance (cold-start hit per (org, domain, action, version) per pod, amortized across subsequent requests).

Phase 3 — Context establishment

The composition root binds the three context sources:

• Supplied — values from the request body. Validated against the world-model context schema; failure → YELLOW + gather_evidence_and_retry.
• System-generated — request_time, request_id, authenticated_caller. Captured at request entry; cannot fail.
• Computed — derivations run at composition-root entry from supplied + system_generated. Derivation throws → YELLOW + diagnostic in trace.

Cost profile: light for simple context schemas; rises with computed-attribute count and complexity (lookup-based derivations that fetch from external sources add their own latency).

Phase 4 — Predicate execution per rule

The composition root runs each rule’s applies_when filter (if present), then matched predicates in severity order, applies suppression chains, runs aggregation per the action’s mode (winner_takes_all by default).

Each predicate executes inside the app-level sandbox established in ADR-083 Layer 2: restricted execution context, no I/O capabilities, per-predicate timeout, exception capture → YELLOW + diagnostic. The predicate is pure, stateless, deterministic — no external calls, no mutation, no nondeterminism.

Cost profile: lightest phase. Per-predicate cost is bounded by the L2 timeout from ADR-083; per-call cumulative cost scales linearly with rule count, which is bounded by the world-model version’s enshrined rule set.

Phase 5 — Aggregation and response

The aggregation step combines matched-rule outcomes into the action’s status. T1 rules are an unconditional hard-floor override; T2/T3 rules combine according to the action’s aggregation mode. The composition root constructs the work_frame (mode, next_action, allowed_actions, forbidden_actions, required_output, missing_evidence, next_human_owner per ADR-077 D3) and the decision_metadata (which rules matched, suppression chain, aggregation outcome, predicate traces, errored predicates, request ID, request time per ADR-077 D3). The response is serialized and returned to the caller.

Cost profile: light; aggregation and response prep are deterministic transformations over already-computed phase-4 outputs.

Cost-profile summary

Per-call cost is bounded across all five phases. Predicate execution (Phase 4) — the phase that customer-facing logic naturally puts most attention on — is the lightest phase. Cold-start variance (Phase 2 cache miss) dominates tail latency at low traffic; steady-state cost is roughly even across Phases 2, 3, and 5 with Phase 4 the lightest of the active phases.

The bounded per-call cost profile is what makes the noisy-neighbor problem tractable with rate limiting alone (per ADR-084) — a tenant’s only lever to consume disproportionate resources is call volume, which rate limiting addresses directly.

Status taxonomy

Every decision returns one of four status values. The status is the audit-grade headline; the work_frame carries the structured behavior contract the agent operates within after receipt.

Status	Meaning	What the agent does
GREEN	The requested action is allowed.	Execute the action as planned.
GREEN-SKIP	The skip is allowed — the action should not execute, and that is the expected outcome (audit-visible no-op).	Do not execute the action. The decision metadata records why; the audit-chain entry preserves the trace.
YELLOW	The agent should not act yet; route to a review path.	Operate within the work_frame constraints — gather evidence, prepare a review packet, route to next_human_owner. Do not execute the original action.
RED	The action is blocked. Escalation required.	Stop. Escalate per the work_frame.next_human_owner. Do not execute the original action.

GREEN and GREEN-SKIP are both permissive outcomes — the system isn’t blocking; the agent’s intent is fine (either execute, or the skip is fine). YELLOW and RED both require the agent to not execute the original action; they differ in whether more information could resolve the decision (YELLOW) or whether the policy structurally disallows it (RED).

T1 rules per ADR-077 are unconditional hard-floor overrides — any T1 match wins outright regardless of aggregation mode, preserving the T1-unsuppressible property across every current and reserved aggregation mode.

References

• ADR-076 — platform pillar as decision-module host (D1 hosting, D2 routing, D4 auth)
• ADR-077 — decision API surface (D1 endpoint, D2 request shape, D3 response shape)
• ADR-080 — module integrity (D2 hash check, D3 approval check at module load)
• ADR-081 — World Agent role and session boundary (D3 operator vs customer session modes)
• ADR-083 — execution sandbox (D2 AST analysis, D3 app sandbox, D4 container boundary)
• ADR-084 — noisy-neighbor handling (cost-profile analysis built on this decomposition)
• ADR-087 — subject-identity delegation (D1 JWT format, D2 act claim shape)
• ADR-088 — MCP surface specifics (the MCP-equivalent path)