Substrate Recursion: Convergence on a Single Evaluator
Abstract
We describe a pattern we call substrate recursion: when a platform’s substrate is a queryable knowledge graph with a programmable, temporally-extended evaluator, control-plane mechanisms that the literature treats as separate engineering projects fall out as use-cases of the substrate.
We document the pattern through four architectural inversions in WunderOS, an enterprise agentic operating system: runtime defense mechanisms invert into teaching mechanisms with no infrastructure change; behavioral contract DSLs collapse into the platform’s existing query language; external solver verification reduces to in-process evaluator queries; and bespoke compensation trigger languages reduce to Datalog with metric temporal operators. Three platform decision records converge on a single evaluator semantics shared across all four. The customer-facing payoff is operational: agents inherit the substrate’s durability, audit, and certification properties without modification. The architectural payoff is engineering: what reads as a research program in published work becomes assembly work in WunderOS.
The architectural pattern of designing the platform substrate as the universal control-plane DSL is the contribution; the four inversions are evidence the pattern is already paying off.
1. Introduction
The past 24 months have produced a remarkable cluster of papers on agentic AI safety, behavioral verification, structured-DSL teaching, and durable workflow execution. Each cluster solves a real problem; each cluster’s solution is published as if independent. They are not.
We describe WunderOS, an enterprise agentic operating system built in Gleam (BEAM control plane) and Zig (cognitive plane), shipping in 2026 to enterprise customers with enterprise-class compliance posture. WunderOS’s substrate is a hyperdimensional knowledge graph (the Pentad: Subject, Predicate, Object, Context, Lineage), exposed to customers via a Datalog-shaped DSL called Wunderlog and evaluated by a Datalog engine called Gleamalog. The substrate supports recursion, stratified negation, aggregation, and metric temporal operators (DatalogMTL per Pollaci 2026).
During the design of three internal architecture decision records, for runtime executor architecture, social-memory uncertainty calculus, and customer-agent onboarding/certification, we discovered that each decision record’s design problem maps cleanly onto the existing substrate, in a way that none of the published baselines realized was possible. The mapping is not metaphorical. Contracts are programs that run on the existing evaluator. Triggers are continuous queries against the substrate. Audit logs are facts in the same graph. Runtime defense mechanisms invert into runtime teaching mechanisms with no infrastructure change. We call this substrate recursion: the substrate is the language is the verifier is the audit graph is the trigger evaluator is the contract DSL.
The pattern is reproducible on any platform whose substrate satisfies the prerequisites (queryable knowledge graph, programmable evaluator, temporal extension). Our specific instance happens to absorb four published research lines; we expect more as the platform develops. The four inversions below are evidence that the pattern is already paying off; the meta-pattern itself is the contribution.
2. Background — WunderOS’s substrate
2.1 Pentad-shaped facts
WunderOS’s atomic data unit is the Pentad: (Subject, Predicate, Object,
Context, Lineage). The structural invariant is SPO[C,L]. SPO defines the
graph topology (who connects to whom via what relation; ordered,
non-commutative). C is scope context (under what circumstances this edge holds).
L is provenance (where this edge came from).
2.2 Wunderlog as DSL; Gleamalog as evaluator
Wunderlog is a Datalog-shaped query language over Pentads: rules with body-bound variables, recursion, stratified negation, aggregation. Gleamalog is its evaluator and the sole query entry-point for the WunderOS system. Internal substrate dispatch is hidden; the public surface is Wunderlog.
Gleamalog uses Approximation Fixpoint Theory
three-valued semantics over {true, undef, false} per Pollaci 2026, with a
provenance semiring that is ordered,
ω-continuous, and undef-as-zero. DatalogMTL extends Gleamalog with metric
temporal operators, anchored on a bi-temporal interval primitive
(transaction-time + valid-time per the platform’s ULID envelope).
2.3 RIARC always-on tracer
Every hop in the WunderOS system emits structured trace events to a tracer-actor (RIARC, after Aceto et al. 2024). Provenance hashes are stored side-table; trace events are themselves append-only Pentads. The platform produces a complete provenance graph at zero marginal cost in operator effort, with cryptographic anchoring via Merkle chains and Ed25519 chain-head signing per PLRN-002.
2.4 The substrate’s role in this paper
The four inversions all reduce to recursion onto these substrate properties. Pentads are the universal storage shape; Wunderlog is the universal query language; Gleamalog is the universal evaluator; RIARC is the universal trace; AFT three-valued logic is the universal truth-value space. Each inversion replaces an external mechanism (YAML DSL, external solver, bespoke trigger language, defense-only runtime hook) with a use-case of the substrate.
3. The four inversions
3.1 Inversion 1 — Defense becomes teaching
The 2025–2026 literature on host-owns-runtime mechanisms is uniformly framed as defense and containment. Privilege-tier isolation, policy-gatekeeper middleware, semantic ISA with taint tracking, audit-first provenance, transactional rollback: all assume the host owns the agent’s runtime in order to block unsafe actions, reject tainted outputs, rollback violating actions, and quarantine drifting agents.
The same mechanisms invert cleanly into teaching and shaping with no infrastructure change. Block becomes redirect to a teaching example. Reject becomes reframe with a curated counter-example. Rollback becomes scaffolded retry with corrective context. Quarantine becomes return to onboarding curriculum. The inversion is structural, not metaphorical: a policy-gatekeeper middleware that rejects invalid tool calls in defense mode emits a redirect-and-substitute event in teaching mode; the underlying interception, audit, and supervisor-tree mechanisms are identical.
The runtime mediation infrastructure already exists, since it has to, for compliance. Enterprise customers require the defense use case independently. The teaching use case is not an addition; it is a different harvest mode of the same machinery.
In WunderOS, Customer Agents (CAs), written in an arbitrary language and wrapping frontier LLM APIs, execute inside WunderOS-owned micro-VM sandboxes. The host intercepts every CA tool call, message send, and state mutation. In defense mode, the host applies the platform’s behavioral contract layer (§3.2) to allow, modify, or abort. In teaching mode, the same contract layer fires modify rules, substituting tool responses with curated teaching examples, redirecting calls to mined plan dispatches, scaffolding errors into retry loops with feedback. The CA, written in any language without WunderOS-awareness, perceives only what the host shows it.
3.2 Inversion 2 — Contract DSL becomes the query DSL
Behavioral contract literature assumes contracts are written in a separate YAML DSL with field-equality predicates over JSON-RPC tool calls. Existing systems report 88–100% hard-constraint compliance with sub-10ms enforcement overhead. The published shape is sound for REST function-call agents. It does not generalize to graph-shaped query agents. A pre-condition like “query result must contain at least N entities of canonical type T” is not naturally expressed as field-equality on JSON. A post-condition like “no fact authored by tenant T was retracted by this action” requires recursive lineage traversal.
Pre/post conditions on agent actions are Datalog rules over the substrate. Wunderlog is the contract DSL.
% pre-condition: query target must be canonical
contract_pre(verify_inventory) :-
target(?o), tier1_axiom(?o).
% post-condition: no customer-authored facts retracted
contract_post(create_order) :-
not (exists ?f : retracted(?f), authored_by(?f, customer(_))).
% multi-hop assertion: result depth respects tenant policy
contract_pre(deep_query) :-
depth(?n), tenant_max_depth(?max), ?n =< ?max.
Contracts are programs that already run on Gleamalog. Pre/post evaluation is just another Wunderlog query. Cert artifacts are Pentads. Audit logs are Pentads. Probes are Wunderlog programs. The contract architecture executes inside the platform’s existing query engine.
The published systems pay for a YAML parser, a separate DSL evaluator, a separate audit logger, and a separate provenance graph. WunderOS’s contract layer pays nothing; every component already exists for substrate queries. New contract types are new Wunderlog rules; they are tested with the same machinery as queries; they audit themselves into the same provenance graph.
CA blessing state (which version of which plan a CA is certified for) lives as Pentads. Audit lineage is a Wunderlog query. Cert flow status is a Wunderlog query. The cert protocol is itself a Wunderlog program. The platform stores certification evidence in the platform.
3.3 Inversion 3 — Substrate becomes the verifier
Neuro-symbolic teaching literature describes a verifier loop: the LLM generates a logic program (Datalog or ASP), an external solver (Clingo, Z3, Scallop’s Datalog engine) verifies it, errors feed back to the LLM for repair. LLM-ARC reaches 88.32% on FOLIO; Scallop reaches 99.4% on PacMan-Maze and improves CLUTRR by 25 percentage points. The verifier is treated as infrastructure, with substantial engineering committed to solver integration: process boundaries, error-message translation, repair-loop orchestration, deterministic-replay considerations.
WunderOS already has the solver: Gleamalog. LLM emits Wunderlog, Gleamalog evaluates, errors feed back with Pentad-level RIARC provenance. The closed loop the papers want exists natively.
The published systems’ weakest link, error message quality from external solvers, becomes WunderOS’s strongest feature. Clingo errors are typically string-formatted descriptions of constraint violations. WunderOS’s errors carry structured provenance: “your rule failed at evaluator step 17 because predicate :in_stock expected type :product_sku in argument position 2 but received type :tenant_id; see the violating fact at hash 0xa7f3... and the rule at hash 0x3c91....” The repair loop receives substantially richer signal than the baseline.
The published systems pay for solver process management, IPC, error translation, and replay coordination. WunderOS pays for none of these: Gleamalog is already in-process, errors are already structured, and replay is already deterministic per PLRN-002. The closed loop is not engineered; it is configured.
3.4 Inversion 4 — Trigger DSL becomes Wunderlog with metric temporal operators
Saga workflow engines use bespoke trigger languages for compensation timers and state-condition predicates. Triggers are typically time-deadlines plus state-checks expressed in the engine’s native API. Each engine ships its own DSL. These trigger languages compose poorly: time logic, state logic, and probabilistic logic are typically in separate sub-languages or require custom code.
WunderOS’s evaluator already runs DatalogMTL: Datalog with metric temporal operators. Triggers are Wunderlog programs:
% time-only deadline
fire_cancellation_compensation(?p) :-
not(plan_resolved(?p)), elapsed(?p, [7d, ∞]).
% state condition (multiple plans, joint state)
fire_emergency_rollback(?p) :-
plan_state(?p, in_progress),
order_state(?a, failed), order_state(?b, failed),
plan_uses_order(?p, ?a), plan_uses_order(?p, ?b).
% event-based (cancel-message arrival)
fire_cancellation(?p) :-
received(?msg, type=cancel, plan=?p, [now-1s, now]).
Triggers compose with WunderOS’s Subjective Logic / AFT-three-valued bridge: a trigger that depends on an uncertain proposition returns an SL opinion, which projects to AFT three-valued at the evaluator boundary, firing on a state transition through threshold. Probabilistic triggers compose with deterministic triggers in the same language.
The published engines’ trigger languages handle their canonical case (time + state) but fail on probabilistic or graph-shaped predicates. WunderOS’s trigger evaluation is a continuous DatalogMTL query, push-based via RIARC change-event subscription rather than poll-based, with load proportional to fact-stream events times subscription matches. Compensation registration is one subscription added to the same evaluator that runs queries, contracts, and verification.
Triggers themselves are Pentads. Trigger evaluation produces audit Pentads. The compensation chain is itself a Wunderlog program (or a plan reference, which is a Pentad in the substrate’s plan tier). The trigger architecture is fully self-hosted in the substrate.
4. The meta-pattern — substrate recursion
The four inversions share a structural form. In each case: the published baseline introduces an external mechanism (YAML DSL, external solver, bespoke trigger language, dedicated runtime defense); the WunderOS substrate already provides that mechanism’s function as a use-case of the substrate’s existing capability; recursion onto the substrate is cleaner: fewer moving parts, richer provenance, native auditability, and composition with the substrate’s other use-cases.
The pattern is generalizable. A platform whose substrate is a queryable knowledge graph with a temporal extension and a programmable evaluator can absorb any control-plane mechanism that can be expressed as queries, rules, or temporal predicates. WunderOS’s specific instance happens to absorb four; we expect more.
The recursion is not metaphor. It is concrete: contract DSL is the same Datalog as the query DSL, evaluated on the same evaluator, audited into the same provenance graph, written by the same compiler. There is no translation layer. There is no external solver process. There is no separate audit pipeline.
The customer-facing payoff is operational: agents inherit the substrate’s properties for free. This includes BEAM-class fault tolerance (process isolation, persistent state, fail-fast safety, bounded blast radius), formal-method-grade auditability (every action a Pentad, every Pentad in the provenance graph), deterministic replay (per PLRN-002), and continuous certification (Layer-2 contracts run as Wunderlog programs).
The architectural payoff is engineering: what reads as a research program in published work becomes assembly work in WunderOS. Customer-agent onboarding, certification, runtime shaping, durable execution, saga compensation, and probabilistic uncertainty composition are not separate engineering projects; they share an evaluator, a DSL, an audit graph, and a deployment.
5. Customer-facing claim — work survives agent death
The most concrete operational consequence of substrate recursion is the inversion of the customer-agent durability story. We elaborate it because it is the strongest single competitive differentiator.
In standard agent runtimes, the runtime owns state. Agent crash means state loss without explicit checkpointing. The customer must implement durability at the application layer.
In WunderOS, the customer agent is a transient perspective over a durable substrate. Per-CA always-on BEAM actors hold conversational thread context, plan continuation pointers, persona state, and capability bindings. The platform’s plan executor holds in-flight plan state; workers hibernate between events and survive arbitrary CA restart cycles. The write-ahead log holds the state of record; supervisor crashes restart from WAL replay.
CAs come and go (deploy, redeploy, OOM, datacenter migration); the platform-side actors and plan workers persist. CA reconnect via stable identity yields a continuation envelope: “you were at step 17 of plan P; last result was X; next legal step is Y.” The customer perceives “my agent picks up where it left off.” The mechanism is BEAM supervision plus substrate-recorded continuation, not application-layer checkpointing.
The load-bearing claim is work survives agent death. The mechanisms that deliver it: process isolation via per-CA supervisors structurally bounds blast radius; persistent state lives outside the CA process in platform-side actors and the WAL; committed state is preserved across CA crash, with no orphaned state and no zombie locks; the boundary is operationally clear at the WunderOS interface, with everything crossing the interface durable and everything in CA-only memory not. The CA can be written in any language without WunderOS-awareness; what survives is what the platform recorded, audited, and committed.
Two limits, both honest. Customer-internal state (input held in CA memory mid-keystroke, intermediate values not yet committed) is not covered. WunderOS only protects state committed via the WunderOS interface. CA semantic correctness on resume is the customer’s responsibility; the platform hands back a continuation envelope, and the CA must correctly resume from it. These limits are tight. The claim that CAs inherit substrate durability without being written in Erlang holds within them.
The intercept-and-inject extension generalizes the pitch further. Even legacy CAs that have no WunderOS-awareness can be uplifted via runtime interception. A CA calls some external API; WunderOS’s micro-VM intercepts the call; the contract layer recognizes the call shape and redirects it to a WunderOS-mined plan; the CA receives results that look like the API’s responses but were actuated by the platform with full WunderOS durability and audit. No SDK migration, no rewrite; the CA inherits WunderOS’s properties without code changes. This is the value proposition.
6. What we will measure
Several empirical surfaces will harden the framework as the platform deploys.
Engineering cost. The architectural claim that what reads as a research program in published work becomes assembly work in WunderOS is measurable. Engineer-month tally across the four inversions, with comparison to cumulative reproduction estimate from re-implementing the published systems, is the relevant data. Total LOC for the contract layer, trigger layer, and runtime mediation layer, with per-component breakdown, is the ground truth.
Performance under each inversion. Contract evaluation latency (WunderOS versus the published <10ms baseline), trigger evaluation overhead (WunderOS’s continuous-query subscription model versus per-key partition log), verification repair-loop iteration count (WunderOS-Pentad-provenance versus Clingo error messages on representative Wunderlog programs), and runtime mediation overhead are the bench surfaces. Each maps directly to a published number we can compare against.
Work-survives-agent-death under chaos. Kill CA repeatedly mid-plan; verify zero work loss; verify continuation correctness on reconnect. The intercept-and-inject case adds a legacy-uplift dimension: a CA that does not know WunderOS exists, deployed against a real-world API contract, with measurement of durability properties before and after platform interception.
Convergence validation across the three platform decision records. The structural claim is that the contracts, triggers, queries, and audits across the three records all evaluate on the same Gleamalog instance, in the same Wunderlog dialect, into the same Pentad provenance graph, with no translation layer and no bridge code. A cross-record audit table verifies this.
These are the measurements that will harden the pitch from architectural claim to validated framework. The framing crystallized in the design sessions and we publish it now because the structure is robust enough that empirical fill-in will sharpen rather than reshape it.
7. Related work
We position against three near-competitors and the four published research lines the inversions invert.
Letta owns agent state in its runtime; agent crash means state loss without explicit checkpointing. WunderOS wins on durability: state lives in the substrate, not the runtime.
Restate is the closest real competitor. BEAM-flavored architecturally (per-key ordering, durable promises, virtual objects). Differentiators: Restate’s trigger language is bespoke; Restate has no knowledge-graph substrate; Restate has no agent-aware framing. WunderOS’s pitch against Restate is the four-fold convergence: all of Restate’s good ideas plus three more.
Temporal offers child-workflow plus activity-idempotency with strong durable execution. Closer to WunderOS than most, but lacks substrate-as-language recursion (Temporal’s workflow definition language is bespoke), lacks a knowledge-graph substrate, and lacks the agent-aware framing.
The published research lines the inversions invert are cited in §8.
8. References
Aceto, Attard, Francalanza, Ingólfsdóttir. RIARC: A Decentralized Instrumentation Algorithm for Synchronous Outline Runtime Verification. 2024.
Agent Behavioral Contracts: Formal Specification and Runtime Enforcement. 2026. arxiv:2602.22302.
AgentSpec. Customizable Runtime Enforcement for Safe and Reliable LLM Agents. 2025. arxiv:2503.18666.
Qin et al. Harnessing Embodied Agents: Runtime Governance for Policy-Constrained Execution. 2026. arxiv:2604.07833.
Agent-Sentry: Bounding LLM Agents via Execution Provenance. 2026. arxiv:2603.22868.
LLM-ARC. Enhancing LLMs with an Automated Reasoning Critic. 2024. arxiv:2406.17663.
Scallop. A Language for Neurosymbolic Programming. 2023. arxiv:2304.04812.
Pollaci. Fixpoint Semantics for DatalogMTL with Negation. 2026. arxiv:2601.03841.
Zhao et al. Evaluating Datalog over Semirings: A Grounding-based Approach. 2024. arxiv:2403.12436.
Pentad Labs Research Note 002. Composing Deterministic-Simulation Testing Across Heterogeneous Substrates. 2026.
9. Limitations
The pattern requires a substrate. Substrate recursion only works when the platform has a queryable knowledge graph with a programmable evaluator. Not every system does. A platform built around a key-value store, a relational database without recursion, or a vector database alone would not absorb the four inversions. The pattern is general but the prerequisite is real.
The substrate must support the temporal extension. Inversion 4 specifically requires metric temporal operators. DatalogMTL is one realization; LTL+ is another. A platform whose substrate is plain Datalog or plain SPARQL would have to extend the substrate to absorb compensation triggers. The extension is well-understood, but it is not free.
The convergence is platform-specific. We claim the four inversions are reproducible on any platform with the right substrate prerequisites. We do not claim every platform should converge on this design. Platforms with different substrates (vector DBs, BPMN engines, microservice meshes) will have different recursion patterns, or none. Our specific instance is a sufficient condition; we do not claim necessity.
10. Conclusion
We have described four architectural inversions in an enterprise agentic memory platform: defense mechanisms inverted to teaching, contract DSL recursed onto the query DSL, external solver collapsed into the platform’s own evaluator, and bespoke trigger languages replaced by Datalog with metric temporal operators. The four inversions converge on a single evaluator semantics shared across three platform decision records.
The pattern we name substrate recursion is general: when a platform’s substrate is a queryable knowledge graph with a programmable, temporally-extended evaluator, control-plane mechanisms that the literature treats as separate engineering projects fall out as use-cases of the substrate. The customer-facing consequence is operational: agents inherit the substrate’s durability, audit, and certification properties without modification. The architectural consequence is engineering: what reads as a research program becomes assembly work. The publication-track consequence is that no single existing paper combines all four inversions; the integration is the novel artifact.
The architectural pattern of designing the platform substrate as the universal control-plane DSL is itself the contribution, and the resulting platform is materially stronger than the sum of the published parts. The pattern is reproducible on any platform with the right substrate prerequisites. Our specific instance is one realization. We expect more.
11. On how this note came together
The substrate-recursion observation did not arrive top-down. It emerged during a design session for the platform’s executor architecture decision record on 29 April 2026. Three of the four inversions, defense becoming teaching, contract DSL recursing onto the query DSL, substrate becoming the verifier, surfaced earlier in the same session during work on the customer-agent onboarding and certification record. The fourth inversion surfaced during the trigger-DSL discussion, when the question of how to express compensation predicates produced the observation: we have MTL+ which might do nicely here. Within ten minutes of that observation, the three-fold convergence became four-fold and the meta-pattern was visible.
The convergence was recognized rather than engineered. None of the three decision records was designed with substrate recursion in mind; each was solving its own problem with its own mechanisms. The pattern emerged from noticing that the mechanisms kept reducing to the same evaluator, the same DSL, and the same provenance graph. This is itself evidence for the substrate-recursion claim: a platform whose substrate is the right shape will produce convergent designs across independent design problems, even when no one is trying to make them converge.
The note itself was filed before the empirical work that will eventually validate it. We capture the framing now because the structure is robust enough that empirical fill-in will sharpen rather than reshape it, and because frames decay if not captured while fresh. Substrate recursion all the way down: even the writing process recursed onto the platform’s habit of saving framing artifacts before deployment.
A note on method
Drafted in conversation with Claude Opus 4.7 (Anthropic) as structured interlocutor and prose editor. The framework, claims, architectural commitments, and the substrate-recursion meta-pattern are mine. Claude converted internal design-note material into research-note register, pushed back on framing where the load-bearing claim was not foregrounded, and tightened prose. The draft derives from internal design notes filed during the BFS interview session of 2026-04-29. Transcripts available on request.
Kendall Clark · k@pentad.ai
—Great Falls, Virginia
May 2026
Pentad Labs · pentad.ai