The Execution Pipeline

Stage by stage: what runs on every request through the default server today, updated to reflect the gateway now being wired unconditionally.

This page previously said the gateway and connector-enforcement stages are not invoked by the default server. That was true through commit 4740aee (2026-07-08). As of 651497a (2026-07-11), they run on every request — stages 7-8 in the current numbering below. See The gateway for the current mechanism and its one real caveat: only one connector is registered.

Stage numbering changed on 2026-07-28. Signal/Intent binding (now stage 3) is a new stage, added by the G-24 fix — every later stage’s number shifted up by one from what older captures of this page show. See Security for what this stage closed.

Stage-by-stage status

Stage	What it does	Status	Evidence
1. Accept Business Transaction	Validates trust-chain invariants (IDs match across the chain, policy/action present)	[AVAILABLE]	BusinessTransactionValidator, packages/runtime/src/validators/BusinessTransactionValidator.ts
2. Policy load	Loads the exact referenced policy (name+version)	[AVAILABLE]	PolicyRouter, CLAIMS.md 2.2
3. Signal/Intent binding	For every boundSignals entry the loaded policy declares, checks the declared signal equals the value at its intent dot-path — before any rule evaluates. A violation is built into an ordinary REJECT Decision; no rule runs, no authorization is ever generated. See Policies and the decision and Security for the bypass this closed	[AVAILABLE]	SignalIntentBinder, packages/runtime/src/RuntimeEngine.ts
4. Policy evaluation	Evaluates signals against the loaded policy’s sequential rules, first match wins	[AVAILABLE]	PolicyEngine, CLAIMS.md 2.3
5. Execution gate	Refuses to execute when the Decision is not APPROVED or required trust artifacts are missing	[AVAILABLE]	ExecutionGate, TrustChainValidationComponent, CLAIMS.md 2.4
6. Signed Execution Authorization	Signs a payload scoped to one Decision, bound to a single-use nonce, valid only within a bounded window, only after the gate approves	[AVAILABLE]	RuntimeAuthorizationSigner, CLAIMS.md 2.8/2.12
7. Execution Gateway (content-binding)	Recomputes the executable-content hash, compares to the authorization’s businessTransactionHash, rejects a mismatch before consuming the nonce	[AVAILABLE], wired into the default server unconditionally	ExecutionGateway.ts:141-195; see The gateway
8. Credential Isolation / Connector Enforcement	Resolves a credential handle inside the Gateway boundary, then forwards verified content to the target system through a capability-checked Connector	[AVAILABLE] for the two registered connectors (razorpay, hubspot); reaching a third connector requires a bootstrap code change	packages/connector-sdk/src/{HttpConnector,MockConnector,SdkConnectorExecutor}.ts, packages/api/src/bootstrap/createConnectorRegistry.ts
9. Execution Trust Record	Assembles the immutable record: transaction, executions, overrides, verifications, receipts, canonical hash, signature	[AVAILABLE]	BusinessTrustRecordBuilder, CLAIMS.md 2.5
10. Verification	Recomputes hash, verifies signature, checks authorization binding on every APPROVED execution	[AVAILABLE], exactly 3 checks	VerificationService, CLAIMS.md 2.15
11. Replay	Genuinely re-evaluates the recorded policy decision, scoped to one execution, disconnected from the API	[PARTIAL]	See Replay

What actually runs when you call POST /execute today

All eleven stages run, in order, on every request. Stage 8’s connector enforcement is real only for the payments:execute action, the one connector wired into createConnectorRegistry.ts, an action with no matching connector fails closed with “No connector registered for action,” it does not silently skip stages 7-8, see The gateway for the mechanism and Quickstart for a verified live run through the full pipeline. Stage 3 (signal/intent binding) is the one stage that can reject a transaction before stage 4 (policy evaluation) ever runs a single rule — see Security for why that ordering matters.

Fail-closed properties that do hold today

• A rejected Decision never produces a Signed Execution Authorization, authorization signing happens only after executionGate.enforce() approves (packages/runtime/src/RuntimeEngine.ts, CLAIMS.md 2.12, packages/runtime/test/execution-authorization-wiring.test.ts, “rejected transaction produces no authorization”). It throws rather than returning a rejected result, see Write your first policy.
• Signing or verifying with the wrong key type (e.g. an Ed25519 key against an ML-DSA-65 provider) fails closed with a named error rather than silently dispatching on the key’s own type (assertKeyType, CLAIMS.md 2.13).
• The Trust Record’s authorizationId is part of the canonically-hashed content, not attached alongside it, tampering with it changes the recomputed hash (CLAIMS.md 2.11).