Skip to main content
[AVAILABLE]. packages/runtime. Wires together @parmana/policy, @parmana/crypto, @parmana/storage, and whichever ExecutionSystem you supply.

Purpose

Given a BusinessTransaction and an ExecutionSystem, runs the full pipeline: validate, evaluate policy, sign an authorization if approved, release execution, assemble and store the resulting Execution trust record.

Install

Not published to npm. This is an internal package of this repository, used from a clone of it: npm ci at the repository root links every workspace package. The packages published to npm are @parmana/sdk, @parmana/connector-sdk and @parmana/sign.

Key exports

Entry points, [AVAILABLE]

Advanced / lower-level, [AVAILABLE]

Services, [AVAILABLE]

business-transaction-service, execution-service, receipt-service (uses @parmana/crypto’s ReceiptCrypto; there is no separate receipt package), verification-service.

Errors, [AVAILABLE]

RuntimeError (base, carries status and code), BusinessTransactionValidationError, DuplicateBusinessTransactionError, VerificationFailedError, ReceiptGenerationError. packages/api/src/middleware/error-handler.ts checks these by instanceof to pick an HTTP status, verified per-route on Error handling, including two gaps where a raw, uncaught error bypasses this entirely, see the Error catalog.

Startup observability: which optional protections are active

RuntimeEngine’s constructor logs a single runtime_engine_constructed event noting whether signalStateVerifier, capabilityPolicyBinder, and refusal recording are configured for that instance. Each is an intentionally optional, capability-scoped dependency, and omitting one is valid, deliberate configuration, not a bug. Before this, an operator reading logs had no way to tell which protections a given deployment was actually running with. Construction-time only, not per-request: the configuration doesn’t change per transaction. See docs/CLAIMS.md §2.30.

A rejected decision throws, it does not return

ExecutionTrustApplication.execute() throws a RuntimeError when the policy decision is REJECTED, it does not return an object with outcome: "REJECTED". Verified live in Write your first policy: the thrown message is the matched rule’s rejection reason, status: 500, code: "RUNTIME_ERROR". A caller that wants to handle rejection gracefully needs a try/catch.

Minimal example

Next

Authorize and execute an action end to end

See RuntimeContext.authorization directly, something the REST API never exposes.

@parmana/execution-system

The one interface the fourth RuntimeFactory.create() argument must implement.