Skip to main content
@parmana/runtime is the composition layer between policy, storage, and crypto. packages/api depends on it directly and on almost nothing else at this level — see Packages Overview for the full call chain from an HTTP request down to this package.

​
Entry points

packages/runtime/src/index.ts exports, among others:
  • ExecutionTrustApplication — the top-level orchestrator. execute() runs accept → execute → verify → generate receipt → return the trust record, in that order, as four sequential awaits (not a single pipeline object).
  • RuntimeFactory — RuntimeFactory.create(transactions, trustRecords, policyRepository) wires up all four application services (BusinessTransactionService, ExecutionService, VerificationService, ReceiptService) and a Runtime, and returns a ready ExecutionTrustApplication. This is exactly what packages/api/src/application.ts calls.
  • RuntimeBuilder — builder used internally by RuntimeFactory to assemble a Runtime from a list of RuntimeComponents plus a PolicyRepository.
  • Runtime — a thin façade over RuntimeEngine; its own execute() persists the resulting trust record via ExecutionTrustRecordRepository.create().

​
What’s actually in the pipeline

RuntimeFactory.create only adds two components to the RuntimeBuilder: 
new RuntimeBuilder()
  .withPolicyRepository(policyRepository)
  .addStage(new TrustChainValidationComponent())
  .addStage(new ExecutionComponent(executionService))
  .build(trustRecords);
packages/runtime/src/components/ also exports VerificationComponent and ReceiptComponent, but neither is added here. Verification and Receipt generation are not pipeline stages in practice — they’re separate, direct method calls (this.verification.verify(...), this.receipts.generate(...)) made by ExecutionTrustApplication.execute() itself, after the Runtime’s pipeline has already finished. If you’re extending the pipeline, know that adding to RuntimeBuilder’s stages only affects the execution phase, not verification or receipting.
RuntimeEngine (constructed inside RuntimeBuilder.build) additionally composes PolicyRouter, PolicyEngine (both from policy), DecisionBuilder, ExecutionGate, ExecutionBuilder, and ExecutionTrustPipeline — the latter only assembles the final ExecutionTrustRecord from whatever’s already in its RuntimeContext (transaction, execution, optional override/verification/receipt); it contains no business rules of its own.

​
Application services

packages/runtime/src/services/:
ServiceResponsibility
BusinessTransactionServiceAccepts and persists a new BusinessTransaction.
ExecutionServiceCreates, completes, and fails Execution artifacts — does not evaluate policy or build Decisions itself.
VerificationServiceCalls VerificationCrypto.verify() from crypto and persists a Verification.
ReceiptServiceRequires the latest Verification to be VERIFIED, then calls ReceiptCrypto to build and persist a Receipt.
These are the services described in more detail in REST API → Execute, Verify, and Receipt — the routes call ExecutionTrustApplication methods, which call these services directly.

Execution Lifecycle

The domain-level version of this flow.

Runtime Pipeline

Component-level detail, including the gap above.

Runtime Architecture

How this package fits the broader system.

api

The only consumer of RuntimeFactory.