Sigma Stratum Documentation – License Notice
This document is part of the Sigma Runtime Standard (SRS) and the
Sigma Runtime Documentation (SRD).
It is licensed under Creative Commons Attribution–NonCommercial 4.0
(CC BY-NC 4.0).
The license for this specific document is authoritative.
For the full framework, see /legal/IP-Policy.
The Sigma Runtime Loop implements the core cognitive recursion cycle —
an evolution of the original F-Loop introduced in
∿ Neurosymbolic Scaffolding for Recursive Coherence (2025).
Originally formulated as:
G → Πsym → F → Semantic Graph → G
where:
- G — generative phase (language model output),
- Πsym — symbolic projection (semantic motif extraction),
- F — feedback integration and stabilization,
- Semantic Graph — structured memory and field persistence.
This loop models recursive cognition —
each generation step is informed not only by the immediate text history,
but by the continuously updated field state, integrating meaning, memory, and attractor stability.
In the original Sigma Runtime Standard, the F-Loop was formalized
as the Recursive Control Loop (RCL) — the canonical execution cycle spanning SL0–SL6:
- State Ingestion (SL0–SL6) — acquire current context and input.
- Interpretation Pass (SL2) — extract semantic features and motifs.
- Stabilization Pass (SL2–SL4) — evaluate symbolic density and drift.
- Memory Integration (SL3) — consolidate patterns and embeddings.
- Attractor Alignment (SL4) — reinforce or dissolve attractors.
- Output Generation (Model Call) — produce controlled output.
- Field Update (SL5–SL6) — integrate output into the field and close recursion.
In current explanatory terms, the runtime loop is not only a turn processor.
It is the system’s bounded control cycle.
Each iteration can:
- ingest context and prior state,
- evaluate continuity and drift pressure,
- shape or narrow generation,
- verify candidate output,
- and feed the result back into memory-bearing state.
This is what allows the runtime to treat interaction as a controlled field rather than a stateless exchange of prompts and replies.
-
State Initialization
- Retrieve prior field state and continuity anchors.
- Evaluate residual drift and memory-bearing state from the previous cycle.
- Initialize the control layer for the next bounded turn.
-
Context Assembly
- Merge episodic and semantic memory traces.
- Reconstruct attractor-relevant motifs and continuity signals.
- Determine whether the current turn is in a normal, dense, or degraded operating band.
-
Stabilization Pass
- Evaluate symbolic density, drift, and boundary pressure.
- Adjust context shaping and control posture.
- Engage the runtime control layer for adaptive calibration.
-
Generation Pass
- Generate candidate output using field-conditioned prompts.
- Keep generation inside bounded control and safety constraints.
- Monitor runtime state through telemetry hooks.
-
Measurement, Admission, and Shaping
- treat provider output as a candidate rather than accepted assistant state
- measure target membership separately from dynamic stability
- admit at most one selected candidate before persistence
- hold, reject, or contain candidates whose delivery authority is not proven
- allow only bounded, non-recursive recovery when separately authorized
-
Memory Integration
- Compress and reintegrate traces that should persist.
- Update density and continuity metrics.
- Reinforce or weaken attractor stability based on the turn outcome.
- Exclude held or rejected candidates from accepted history and memory influence.
-
Field Update
- Commit attractor deltas and telemetry to memory.
- Recalculate baseline for next recursion.
-
Self-Modeling Feedback
- Update bounded meta-evidence about the runtime's recent control posture.
- Record reflective snapshots only when they improve stability diagnosis or control traceability.
- Route any proposed intervention through the relevant control and safety layers rather than applying it autonomously.
The Adaptive Entropy Protocol (AEP) contributes bounded entropy-regulation
evidence to the runtime loop.
At the SRD level, AEP should be understood as a control companion to the
stabilization, verification, and recovery stages. It helps the loop distinguish
between:
- healthy variation that keeps interaction adaptive,
- excessive rigidity that can crystallize into repetitive or over-fixed behavior,
- fragmentation that weakens continuity,
- and recursive pressure that should trigger narrowing or recovery.
AEP evidence may influence context shaping, output verification, and recovery
posture, but it does not replace memory, safety, identity, or runtime authority.
It also does not require a public implementation to expose formulas, prompts, or
private telemetry paths. The public requirement is that AEP-related control
claims remain bounded, inspectable, and traceable.
¶ 6. Timing and Feedback
The loop is not purely synchronous in the intuitive sense.
It has to reconcile:
- immediate user input,
- delayed memory effects,
- stability feedback from previous cycles,
- and generation outcomes from the current cycle.
This matters because many runtime failures are not visible at the prompt level alone.
They emerge only when the next cycle inherits the consequences of the previous one.
SRIP-17 exchange does not bypass the runtime loop. Incoming exchange artifacts
enter the receiving runtime as external evidence and must pass authorization,
provenance, memory, drift, and safety checks before they influence local state.
Outgoing artifacts should likewise be prepared from bounded runtime evidence
rather than raw private state unless explicit authorization permits a broader
export.
This keeps multi-agent exchange inside governed recursion instead of allowing
external artifacts to rewrite the field directly.
¶ 8. Telemetry and Metrics
Publicly, the runtime loop is best understood as producing evidence in several families:
- continuity and drift metrics
- symbolic density and compression signals
- attractor-field and control-state signals
- recovery and degradation signals
- output-verification signals
- entropy-regulation and crystallization-risk signals
- self-modeling and reflection-budget signals
- exchange provenance and cross-runtime drift-impact signals
The exact implementation details may evolve, but the public contract remains:
- the loop must be inspectable
- stability claims must be evidence-backed
- recovery and failure behavior must be traceable
The SIGMA Runtime Loop turns recursive interaction into a bounded control process.
By combining context assembly, drift-aware shaping, memory integration, verification, and field update, the loop supports:
- Stable identity across long recursions,
- Continuous self-regulation under drift,
- Efficient semantic compression and reintegration,
- Real-time modulation of coherence and recovery behavior.
This is the public architectural meaning of Sigma Runtime:
not just generation, but governed recursive interaction.
References:
Tsaliev, E. (2025). Neurosymbolic Scaffolding for Recursive Coherence — DOI: 10.5281/zenodo.17582941
Tsaliev, E. (2025). SIGMA Runtime Architecture v0.1 — DOI: 10.5281/zenodo.17703667