10. Runtime Execution
The runtime is a domain-neutral interpreter. It resolves qualified Blueprint identities; it never branches on names such as area, batch, or pharma.
A request either produces an allowed change or returns an explanation of why it cannot proceed.
Build a protocol request
import 'package:vyuh_blueprint_protocol/'
'vyuh_blueprint_protocol.dart' as protocol;
import 'package:vyuh_blueprint_server/'
'vyuh_blueprint_server.dart';
final request = protocol.ActionRequest(
id: 'request-001',
source: protocol.RequestSource.ui,
context: protocol.RequestContext(
actorId: 'user-42',
actorRoles: const ['quality_reviewer'],
actorSource: 'directory',
tenantId: 'tenant-1',
siteId: 'hyderabad',
reasonCode: 'AREA_READY',
justification: 'Qualification review completed.',
occurredAt: DateTime.now().toUtc(),
correlationId: 'change-control-107',
),
resume: const protocol.ActionResumePolicy(
idempotencyKey: 'activate:area-201:revision-7',
),
commands: const [
protocol.ActionCommand(
module: 'ops',
entity: 'area',
facet: 'governance',
action: 'activate',
entityId: 'area-201',
idempotencyKey: 'activate:area-201:revision-7',
),
],
);One request can carry multiple commands. RequestLineage and ExecutionLimits bound recursive effects and workflows.
Idempotency and concurrency are language-independent
- A stable idempotency key deduplicates retries.
- Expected versions and locks prevent lost updates.
- A committed request can return the prior record.
- An incomplete request can resume pending work according to
ActionResumePolicy. - Recursion depth, command count, and effect count are bounded by
ExecutionLimits.
These are runtime laws, not Ops-specific rules.
BlueprintRuntimeEngine builds manifests, capabilities, deterministic plans, preflight records, decisions, events, evidence, snapshots, and explanations. BlueprintProtocolDbExecutor supplies locked row state, applies the plan's database mutations, and persists the runtime ledger in one transaction. OutboxRunner and OutboxDispatcher process committed delivery work using the effect idempotency and attempt state stored by that transaction.
Try it in your application
Submit an action with a permitted account, then check the returned result and updated record. If access or validation fails, show the returned explanation without discarding the user’s input.
Next: Evidence and audit.