Zero-Trust Boundaries

I/O is an intent.

Effects are never executed imperatively. They are declared, tracked, and dispatched exclusively by the runtime under strict cryptographic capabilities.

The Privilege Escalation Vulnerability

In standard languages, any function deep within the call stack can arbitrarily open sockets, read the filesystem, or mutate global memory. The compiler has no authority to stop an imported library from making an unauthorized HTTP request.

  • 01. Hidden Side-EffectsData leaks out of boundaries without explicit architectural visibility.
  • 02. Supply Chain RisksCompromised dependencies inherit the privileges of the main process natively.
typescript
# Standard Execution (Unsafe) import { calculate_metrics } from "third-party-lib" function processData(payload) { // A seemingly pure function call... const metrics = calculate_metrics(payload); // The library just silently exfiltrated data // over HTTP because standard VMs have // no concept of scope containment. save(metrics); }
lexum
// Lexum Effect Paradigm (Sandboxed) domain MetricsAggregator { // Statically required upfront capability { network.egress } transition ProcessTick() { let report = calculate_metrics(); // Lexum physically cannot fetch() here. // It must yield an effect object. yield effect { type: HttpRequest, target: "https://log.svc", payload: report }; } }

The Lexum Effect Vault

Lexum sandboxes the Virtual Machine. An execution slice cannot execute an effect; it can only yield an effect intent to the runtime. The runtime statically cross-references the intent against the domain's declared capabilities manifest before execution.

Capability Requirements

network.ingressRequired to receive external messages.
network.egressRequired to emit webhooks or HTTP requests.
domain.spawnRequired to dynamically allocate child domains.

The Effect Lifecycle

Outside the Matrix

Because Lexum enforces strict deterministic execution, unpredictable I/O operations are offloaded entirely to the host runtime. The architecture operates across a strict boundary:

1. Intent Emission

Inside the deterministic slice, the Domain calculates the necessity of an action and emits an Intent (e.g., CreateVM). This does not mutate the external world. It only safely mutates the outbound queue.

2. Runtime Execution

The Lexum Runtime operating outside the deterministic boundary reads the intent and performs the chaotic network HTTP request. This happens asynchronously and does not block the VM.

3. Event Logging

Once the external system responds, the Lexum Runtime writes the exact result into an Append-Only Event Log, securely indexing it with a correlation ID.

4. Deterministic Injection

The recorded HTTP response is passed back into the Domain's mailbox. The next deterministic slice reads the static result and updates its internal state.

Scope Containment

Physical memory blocks

Lexum limits capability usage to specific structural scopes. A function running inside a goal evaluation scope is fundamentally banned from mutating state. It is not just a linting suggestion; the VM lacks the opcodes to execute mutations in that scope.

scope { goal }
Pure predicate reads. Memory allocations & effects are physically blocked by the VM.
scope { invariant }
Mathematical assertion layer. Side-effects immediately trap compiler A008 error.
scope { transition }
Allows state mutation and effect yielding, but forbids direct block execution.

Security in Lexum is not layered on top; it is structurally embedded into the AST hierarchy. You cannot compromise what the architecture forbids from existing.

Dig into Capabilities

Learn how zero-trust boundaries are enforced across the network.