> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parmanasystems.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/concepts/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](/security/overview) 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](/concepts/policies-and-the-decision) and [Security](/security/overview) 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](/concepts/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](/replay/overview) |
## 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](/concepts/the-gateway) for the mechanism and [Quickstart](/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](/security/overview) 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](/guides/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).