Verun Runtime Semantics for Deterministic Service Execution
This paper defines operational semantics for Verun and shows how VDB + VI provide a composable, inspectable foundation for generated services.
Verun Runtime Semantics for Deterministic Service Execution
Abstract
Verun provides two connected runtime surfaces: VI for Versa evaluation and VDB for persistence, VQL execution, sessions, and RBAC/TUMI controls. This paper defines deterministic execution semantics for workloads where generated services and control-plane actions must produce repeatable outcomes under the same inputs and authority context.
The main claim is that determinism is not a language-only or database-only property. It emerges from coordinated behavior across parsing, execution, session context, permission checks, transport boundaries, and response envelope structure.
Runtime Semantics Scope
Reference architecture documentation identifies clear responsibilities:
- VI handles lexical analysis, parsing, AST evaluation, runtime context, and native-module execution.
- VDB handles document persistence, indexing, query planning/execution, sessions, and role-aware command authorization.
- Integration surfaces (console/HTTP/socket and generated APIs) carry caller intent into runtime components.
Determinism requires each layer to avoid implicit fallback behavior and hidden state mutation.
flowchart TD
A[Client or Operator Request] --> B{Execution Path}
B -->|VQL CRUD or query| C[VDB request dispatcher]
B -->|Versa script| D[VI runtime evaluator]
D --> C
C --> E[Session + RBAC enforcement]
E --> F[Storage and index updates]
F --> G[Deterministic response envelope]
Determinism Requirements
- Stable command contracts: operation shape and semantics must be consistent across interfaces.
- Explicit auth context: role and session identity must be present for every protected operation.
- No hidden mutation channels: state transitions must occur only through declared execution paths.
- Replayable outputs: envelopes should allow operators to reason about what was evaluated and why.
Authority and Session Behavior
RBAC outcomes in VDB are runtime preconditions, not optional policy metadata. A request accepted over one interface and denied over another for the same session context indicates semantic instability. For that reason, generated APIs, backend proxies, and direct interfaces should converge on the same authorization model and fail closed when identity context is incomplete.
Failure Modes and Mitigation
Common runtime drift risks include:
- schema/index changes that invalidate assumed query behavior
- script paths that bypass expected role checks
- inconsistent transport-level session propagation
- non-canonical error envelopes that hide root causes
Mitigation patterns:
- centralize auth and session resolution
- keep VQL and script execution contracts explicit
- enforce validation before persistence mutations
- retain operational traces for replay and diagnosis
Reference Basis
This paper is grounded in:
liwiro-context/verun/architecture.mdliwiro-context/integration/system-description.mdliwiro-context/verun/vdb/README.mdliwiro-context/verun/versa/runtime-cli-repl.md
Conclusion
Verun can provide deterministic service execution when VI, VDB, and transport surfaces preserve strict context continuity. The practical rule is straightforward: explicit contracts, explicit authority, explicit state transitions.