---
title: Declared Reflective Runtime Protocol
url: https://www.emergentmind.com/topics/declared-reflective-runtime-protocol
type: topic
---

# Declared Reflective Runtime Protocol

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 [2604.07236], a reflective runtime for self-healing agents built as a state-gated maintenance pipeline [2512.07094], a category-theoretic runtime reflection protocol based on first-class implementations and generalized safe points [2606.04034], and a declared reflective methodology that compiles verified protocol specifications into flat C monitors [2604.03886]. 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 language model loop, which makes it difficult to determine which part of competence comes from the LLM and which part comes from explicit structure [2604.07236]. "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 [2512.07094].

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 [2606.04034]. 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 [2604.03886]. 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 \(t=0,1,2,\dots\), and at each turn maintains a snapshot \(S_t\) comprising a world-model belief state \(W_t\), prediction records \(\mathcal{P}_t\), two exponential-moving-average error trackers, a low-confidence streak counter \(\ell_t\), a cooldown counter \(c_t\), policy parameters \(\Theta_t\), and revision presets and flags [2604.07236]. From this snapshot the runtime computes declarative signals such as
\[
e^{\mathrm{pred}}_{t}
= \alpha\;\bigl|\hat o_{t} - o_{t}\bigr|
+(1-\alpha)\;e^{\mathrm{pred}}_{t-1},
\]
and
\[
c\!f_t \;=\; 1 \;-\; \frac{e^{\mathrm{pred}}_t + e^{\mathrm{cal}}_t}{2}\quad\in[0,1].
\]
These in turn define predicates such as \(\mathrm{confident}_t\), \(\mathrm{needRev}_t\), \(\mathrm{canRev}_t\), \(\mathrm{sustained}_t\), \(\mathrm{revReq}_t\), and \(\mathrm{shouldRev}_t\), all of which are externalized in the runtime and can be queried at any point [2604.07236].

VIGIL expresses reflection through a different formal object: a deterministic finite-state machine
\[
\mathcal{M} = (S,\Sigma,\delta,s_0,S_F),
\]
with
\[
S = \{\texttt{start},\texttt{eb\_updated},\texttt{diagnosed},\texttt{prompt\_done},\texttt{diff\_done},\texttt{error}\},
\]
stage-completion events \(\Sigma=\{\alpha,\beta,\gamma,\delta',\varepsilon\}\), initial state \(\texttt{start}\), and unique final state \(\texttt{diff\_done}\) [2512.07094]. The transition function is partial: valid stage completions advance the runtime only if the corresponding guard predicate succeeds, while \(\varepsilon=\texttt{illegal\_action}\) sends any non-error state to \(\texttt{error}\). All other \((s,e)\) pairs are undefined and raise an explicit `StageOutOfOrder` error rather than allowing the LLM to improvise [2512.07094].

Rideau’s runtime reflection protocol lifts the formal level again. An implementation of a source language \(A\) by a concrete language or machine \(C\) is defined as a triple \((O\hookrightarrow C,\Phi)\), where \(O\) is a full subcategory of observable or safe-point states and \(\Phi:O\to A\) is a functor [2606.04034]. 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 \(f : C.\!\Rightarrow\,c\,c'\) may be observed only if one can continue to a state \(c''\in C.\mathrm{o}\) by a continuation \(g\) such that \(\textsf{safe}_{C}(g)\) and the composed concrete behavior corresponds to an abstract step \(h\) under \(\Phi\) [2606.04034]. The extracted API method
\[
\texttt{observe} : (f : C.Step) \to (g : C.Step, aStep : A.Step)
\]
encodes this obligation operationally. The primitives `climb`, `descend`, and `advance` therefore presuppose proof-bearing observability, completeness, and liveness conditions rather than unconstrained introspection [2606.04034].

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
\[
\mathrm{sim.next}(S,a)\;\longrightarrow\;S',
\]
which returns the predicted next snapshot if action \(a\) were executed without committing to it [2604.07236]. 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` [2604.07236].

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` [2512.07094]. 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:
\[
\begin{array}{rcl}
G &::=& \mathit{end}\\
&\mid& p_i \to p_j:\{\,l_k\,(x_k:\tau_k\{\phi_k(x_k)\})\to G_k\}_{k\in K}\\
&\mid& \mu\,X\,(v:\tau\{\phi(v)\}) .\,G\\
&\mid& X(e).
\end{array}
\]
Each interaction carries exactly five semantic components: sender, receiver, label, payload variable, and refinement predicate [2604.03886].

Reflection occurs in Meta-F*, where the AST is traversed to check four boolean invariants \(A_1,\dots,A_4\): label uniqueness, guarded recursion, global progress, and session fidelity. The well-formedness check is
\[
\texttt{assert}(A_1(G)\,\wedge\,A_2(G)\,\wedge\,A_3(G)\,\wedge\,A_4(G)).
\]
Once these checks succeed, the AST is reflectively extracted into an IR graph \(P=(S,T)\) and then translated to a flat, allocation-free C `switch`-based FSM [2604.03886]. 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 [2604.03886].

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 \(\sigma_{\rm before}\) and \(\sigma_{\rm after}\) of the core block are compared, and if they differ the runtime aborts with `GuardViolation`:
\[
\text{if }\sigma_{\rm before}\ne\sigma_{\rm after}
\quad\Longrightarrow\quad \text{abort with GuardViolation error.}
\]
The patch generator may rewrite only the adaptive section, preserving identity semantics by disallowing insertions, deletions, or token replacements outside those delimiters [2512.07094]. 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 [2512.07094]. Its deterministic appraisal function maps an event \(e\in E\) to \((\mathit{emotion},v,i,c)\), where emotion lies in \(\{\mathit{frustration,pride,relief,curiosity,\dots}\}\), valence \(v\in\{-1,0,+1\}\), intensity \(i\in[0,1]\), and cause \(c\in\mathrm{String}\). The decayed intensity read from EmoBank is
\[
i_{\mathrm{decayed}} = i\;\times\;0.5^{\frac{t' - t}{h}},
\]
with default \(h=12\) hours [2512.07094].

The same system defines policy rules for storage and diagnosis. A new appraisal is stored iff \(i\ge 0.25\) or the sign of its valence differs from the previous one; near-duplicate entries within \(\Delta t<5\) minutes are coalesced with \(i_{\mathrm{boost}}\le 0.1\); and if a positive-valence event follows a negative-valence one within \(\Delta t<10\) minutes, a synthetic `determination` entry with \(v=+0.4\) and \(i\in[0.3,0.4]\) is appended [2512.07094]. 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 [2512.07094]. 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 [2512.07094].

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) [2604.07236]. 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 \(+24.1\) percentage points in win rate and \(+0.017\) in \(F_1\); 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 \(4.3\%\) of turns yields a small and non-monotonic change, with average \(F_1\) rising slightly by \(+0.005\) while win rate drops from \(31\) to \(29\) wins out of \(54\) [2604.07236]. 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 [2512.07094] | stage-gated maintenance pipeline | prompt patches and read-only code proposals |
| Semantic tower protocol [2606.04034] | first-class implementation \((O,\Phi)\) | climb, descend, advance, simulate, perform |
| Platum [2604.03886] | global session type DSL | flat, allocation-free C FSM monitor |
| Battleship runtime [2604.07236] | 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 [2512.07094]. 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 \(C_A\) to an abstract step in \(A\), then descends into \(C_B\), with observability and completeness ensuring preservation of high-level behavior [2606.04034]. Platum targets centralized proxy monitors at the GCS/UAV communication boundary for MAVLink, and evaluates monitor latency and memory overhead in ArduPilot SITL, reporting \(13.33\ \mu s\) total latency and \(4.22\ \mu s\) logic delta for Platum, versus \(56.74\ \mu s\) total latency and \(27.14\ \mu s\) logic delta for DATUM, with Platum’s RSS delta at \(8.39\) MB and DATUM’s at \(13.72\) MB [2604.03886].

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 [2512.07094; 2606.04034]. 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 [2604.07236]. 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 [2604.03886; 2606.04034].

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.

Source: https://www.emergentmind.com/topics/declared-reflective-runtime-protocol