Declared Reflective Runtime Protocol
- Declared reflective runtime protocol is a runtime architecture that exposes adaptation elements like state, signals, and transition rules as explicit, inspectable structures.
- It employs formal models such as finite-state machines and guarded-action calculus to ensure safe, verified reflection and runtime repair across diverse applications.
- This protocol bridges high-level abstract semantics with low-level implementations, enabling efficient adaptive behaviors in autonomous and self-healing systems.
Searching arXiv for the specified papers and closely related work on declared reflective/runtime reflection protocols. arXiv search query: "Declared Reflective Runtime Protocol runtime reflection reflective runtime protocol VIGIL semantic tower Platum Battleship" A declared reflective runtime protocol is a runtime architecture in which the objects of adaptation are made explicit rather than latent: state variables, derived signals, safe points, guards, transition rules, and, in some systems, repair proposals or implementation mappings are represented as inspectable runtime structure instead of being buried inside an opaque control loop. In recent work, this idea appears in several adjacent forms: a declarative agent runtime with externalized confidence and revision signals (Jung et al., 8 Apr 2026), a reflective runtime for self-healing agents built as a state-gated maintenance pipeline (Cruz, 8 Dec 2025), a category-theoretic runtime reflection protocol based on first-class implementations and generalized safe points (Rideau, 1 Jun 2026), and a declared reflective methodology that compiles verified protocol specifications into flat C monitors (Amorim et al., 4 Apr 2026). Taken together, these works define a research program in which reflection is not treated as informal introspection, but as a typed, guarded, and often formally delimited runtime mechanism.
1. Historical and conceptual setting
Several of these systems begin from the same diagnosis: deployed autonomy is often structurally under-specified. "How Much LLM Does a Self-Revising Agent Actually Need?" observes that recent LLM-based agents often place world modeling, planning, and reflection inside a single LLM loop, which makes it difficult to determine which part of competence comes from the LLM and which part comes from explicit structure (Jung et al., 8 Apr 2026). "VIGIL: A Reflective Runtime for Self-Healing Agents" makes a closely related claim at the systems level: agentic LLM frameworks promise autonomous behavior via task decomposition, tool use, and iterative planning, but most deployed systems remain brittle, lack runtime introspection, cannot diagnose their own failure modes, and do not improve over time without human intervention (Cruz, 8 Dec 2025).
A different but compatible motivation comes from runtime semantics. "Climbing Up the Semantic Tower -- at Runtime" argues that software exists at multiple levels of abstraction and that first-class implementations furnish a reflection protocol to navigate this tower at runtime, including changing the underlying implementation of a computation while it is running (Rideau, 1 Jun 2026). In that formulation, reflection is not merely a debugging convenience; it is a way of relating concrete execution to abstract semantics through safe points and implementation witnesses.
Platum extends the same general orientation to runtime enforcement. "From High-Level Types to Low-Level Monitors: Synthesizing Verified Runtime Checkers for MAVLink" describes a pipeline in which high-level declarations are checked by reflection and then compiled into allocation-free runtime monitors, thereby separating specification from verification while preserving executable enforcement (Amorim et al., 4 Apr 2026). A plausible implication is that the phrase "declared reflective runtime protocol" now denotes not one single formalism, but a family of designs sharing two commitments: declaration of runtime-relevant structure at the surface level, and reflection over that structure at execution time.
2. Formal models of declaration and reflection
The most direct formalization of the term appears in the Battleship runtime. There the agent operates in discrete turns , and at each turn maintains a snapshot comprising a world-model belief state , prediction records , two exponential-moving-average error trackers, a low-confidence streak counter , a cooldown counter , policy parameters , and revision presets and flags (Jung et al., 8 Apr 2026). From this snapshot the runtime computes declarative signals such as
and
These in turn define predicates such as , 0, 1, 2, 3, and 4, all of which are externalized in the runtime and can be queried at any point (Jung et al., 8 Apr 2026).
VIGIL expresses reflection through a different formal object: a deterministic finite-state machine
5
with
6
stage-completion events 7, initial state 8, and unique final state 9 (Cruz, 8 Dec 2025). The transition function is partial: valid stage completions advance the runtime only if the corresponding guard predicate succeeds, while 0 sends any non-error state to 1. All other 2 pairs are undefined and raise an explicit StageOutOfOrder error rather than allowing the LLM to improvise (Cruz, 8 Dec 2025).
Rideau’s runtime reflection protocol lifts the formal level again. An implementation of a source language 3 by a concrete language or machine 4 is defined as a triple 5, where 6 is a full subcategory of observable or safe-point states and 7 is a functor (Rideau, 1 Jun 2026). Runtime reflection then consists in operations that move between the concrete and abstract levels, notably observe, control, and advance. In that setting, declaration takes the form of explicit implementation witnesses, while reflection consists of navigating the semantic tower through those witnesses.
3. Safe points, guarded actions, and transition discipline
Across these systems, reflection is constrained by explicit admissibility conditions. In the semantic-tower formulation, the central notion is the generalized safe point. A concrete fragment 8 may be observed only if one can continue to a state 9 by a continuation 0 such that 1 and the composed concrete behavior corresponds to an abstract step 2 under 3 (Rideau, 1 Jun 2026). The extracted API method
4
encodes this obligation operationally. The primitives climb, descend, and advance therefore presuppose proof-bearing observability, completeness, and liveness conditions rather than unconstrained introspection (Rideau, 1 Jun 2026).
The Battleship runtime uses a declarative guarded-action calculus. Actions are defined in the form action A available when CONDITION: EFFECTS, and hypothetical transitions are supplied by
5
which returns the predicted next snapshot if action 6 were executed without committing to it (Jung et al., 8 Apr 2026). Planning, prediction, execution, reconciliation, and reflection are therefore kept in a single runtime loop while remaining explicitly separable. The reference implementation exposes interfaces such as predict(Snapshot s, Action a) → Snapshot s', observe(Snapshot s, Action a, Outcome o) → Snapshot s_plus, and applyRevision(Snapshot s, Revision r) → Snapshot s_rev (Jung et al., 8 Apr 2026).
VIGIL is stricter still. It functions as a state-gated pipeline in which appraise, diagnose, prompt-patch generation, and code-diff generation are separate stages. Illegal stage transitions raise StageOutOfOrder; prompt-update attempts that touch CORE_IDENTITY raise GuardViolation; and schema mismatches or runtime errors inside diagnose_rbt() are caught as InternalSchemaConflict (Cruz, 8 Dec 2025). A recurring theme is that runtime reflection is permitted only at explicitly delimited points and under explicit guards.
4. Declared structure, verification, and synthesis
Platum gives the clearest example of declaration preceding reflection and code generation. Its deep-embedded DSL for global session types uses a grammar with end, internally selected choice, recursive binders, and recursive calls: 7
Each interaction carries exactly five semantic components: sender, receiver, label, payload variable, and refinement predicate (Amorim et al., 4 Apr 2026).
Reflection occurs in Meta-F*, where the AST is traversed to check four boolean invariants 8: label uniqueness, guarded recursion, global progress, and session fidelity. The well-formedness check is
9
Once these checks succeed, the AST is reflectively extracted into an IR graph 0 and then translated to a flat, allocation-free C switch-based FSM (Amorim et al., 4 Apr 2026). At runtime, monitor_step decodes an incoming packet, inspects msgid, evaluates the compiled C guard, updates monitor context and state on success, and flags a protocol violation on failure or no matching branch. Proof terms and logical refinements exist only at compile time; at extraction time they are erased and reified into ordinary boolean C expressions (Amorim et al., 4 Apr 2026).
VIGIL applies an analogous discipline to prompt adaptation. Its prompt template is split into immutable BEGIN_CORE_IDENTITY ... END_CORE_IDENTITY and mutable BEGIN_ADAPTIVE_SECTION ... END_ADAPTIVE_SECTION blocks. Before a patch is applied, checksums 1 and 2 of the core block are compared, and if they differ the runtime aborts with GuardViolation: 3
The patch generator may rewrite only the adaptive section, preserving identity semantics by disallowing insertions, deletions, or token replacements outside those delimiters (Cruz, 8 Dec 2025). This suggests a common architectural pattern: declared regions delimit what reflection may inspect or rewrite, and guards make violations explicit.
5. Reflective diagnosis, self-repair, and revision
VIGIL is a reflective runtime for self-healing agents rather than task execution. It supervises a sibling agent, ingests behavioral logs, appraises each event into a structured emotional representation, maintains a persistent EmoBank with decay and contextual policies, and derives an RBT diagnosis that sorts recent behavior into strengths, opportunities, and failures (Cruz, 8 Dec 2025). Its deterministic appraisal function maps an event 4 to 5, where emotion lies in 6, valence 7, intensity 8, and cause 9. The decayed intensity read from EmoBank is
0
with default 1 hours (Cruz, 8 Dec 2025).
The same system defines policy rules for storage and diagnosis. A new appraisal is stored iff 2 or the sign of its valence differs from the previous one; near-duplicate entries within 3 minutes are coalesced with 4; and if a positive-valence event follows a negative-valence one within 5 minutes, a synthetic determination entry with 6 and 7 is appended (Cruz, 8 Dec 2025). The RBT partition then classifies high-intensity positive emotions as Roses, curiosity or positive cues as Buds, and frustration or anxiety above threshold as Thorns (Cruz, 8 Dec 2025). From this diagnosis, VIGIL generates guarded prompt updates and read-only code proposals through a strategy engine that scans repository hotspots and emits unified diffs without mutating the working tree (Cruz, 8 Dec 2025).
The Battleship runtime instantiates reflection differently: as symbolic in-episode revision and sparse LLM-based revision. The four layers are belief tracking only, explicit world-model planning (WMA), symbolic in-episode reflection (MRA), and sparse LLM-based revision (MRA-LLM) (Jung et al., 8 Apr 2026). Because all state and signals are declared, these layers can be toggled independently. In the reported evaluation over 54 games, explicit world-model planning improves substantially over a greedy posterior-following baseline by 8 percentage points in win rate and 9 in 0; symbolic reflection operates as a real runtime mechanism with prediction tracking, confidence gating, and guarded revision actions, even though its current revision presets are not yet net-positive in aggregate; and adding conditional LLM revision at about 1 of turns yields a small and non-monotonic change, with average 2 rising slightly by 3 while win rate drops from 4 to 5 wins out of 6 (Jung et al., 8 Apr 2026). The runtime therefore makes it possible to study revision as an explicit mechanism rather than as an inseparable property of one language-model loop.
6. Implementations, applications, and points of distinction
The principal implementations differ in domain but share the same reflective discipline.
| Work | Declared object | Runtime consequence |
|---|---|---|
| VIGIL (Cruz, 8 Dec 2025) | stage-gated maintenance pipeline | prompt patches and read-only code proposals |
| Semantic tower protocol (Rideau, 1 Jun 2026) | first-class implementation 7 | climb, descend, advance, simulate, perform |
| Platum (Amorim et al., 4 Apr 2026) | global session type DSL | flat, allocation-free C FSM monitor |
| Battleship runtime (Jung et al., 8 Apr 2026) | snapshot, signals, guarded actions | inspectable planning and revision loop |
The application scenarios are correspondingly heterogeneous. VIGIL reports a reminder latency case study in which elevated lag was identified, prompt and code repairs were proposed, and an internal diagnostic-tool failure caused by a schema conflict was itself surfaced, followed by a fallback diagnosis and repair plan (Cruz, 8 Dec 2025). Rideau’s semantic-tower protocol uses thread migration between two Scheme virtual machines as a motivating example: one climbs from a live thread state in 8 to an abstract step in 9, then descends into 0, with observability and completeness ensuring preservation of high-level behavior (Rideau, 1 Jun 2026). Platum targets centralized proxy monitors at the GCS/UAV communication boundary for MAVLink, and evaluates monitor latency and memory overhead in ArduPilot SITL, reporting 1 total latency and 2 logic delta for Platum, versus 3 total latency and 4 logic delta for DATUM, with Platum’s RSS delta at 5 MB and DATUM’s at 6 MB (Amorim et al., 4 Apr 2026).
Several common misconceptions are directly addressed by this literature. First, a declared reflective runtime protocol is not synonymous with unrestricted self-modification: VIGIL permits only guarded prompt patches inside an adaptive section and emits code diffs under read-only rules, while Rideau’s protocol allows reflection only through safe points and implementation witnesses (Cruz, 8 Dec 2025, Rideau, 1 Jun 2026). Second, it is not equivalent to embedding reflection in an LLM prompt. The Battleship system explicitly externalizes confidence signals, hypothetical transitions, and revision conditions, and shows that symbolic reflection can run without any LLM calls, while sparse LLM revision is invoked only when its guards fire (Jung et al., 8 Apr 2026). Third, it is not limited to agent planning. The same architectural idea appears in verified network monitors and in runtime movement across abstraction levels in a semantic tower (Amorim et al., 4 Apr 2026, Rideau, 1 Jun 2026).
A plausible implication is that declared reflective runtime protocols are best understood as a unifying systems idiom rather than a single algorithm: declaration fixes the surface structure over which the runtime may reason, and reflection supplies the mechanisms—observation, verification, guarded adaptation, or repair—by which that structure is used during execution.