Sigma Stratum Documentation – License Notice
This document is part of the Sigma Runtime Documentation (SRD).
It is licensed under Creative Commons Attribution–NonCommercial 4.0
(CC BY-NC 4.0).This guide is descriptive, not normative. It does not introduce, modify,
or replace requirements of the Sigma Runtime Standard (SRS) or any Sigma
Runtime Improvement Proposal (SRIP).
This guide describes the public SRS/SRIP architecture. It does not imply that every described mechanism is implemented, enabled, or verified in a particular Sigma Runtime release.
The Sigma Runtime Standard describes a bounded runtime architecture for long-horizon interaction, continuity, memory, drift management, recovery, external interaction, and evidence-bearing control.
This guide provides a governance-facing reading of those concepts for stakeholders who may not work directly with the underlying cognitive or runtime architecture, including:
Its purpose is not to simplify away the technical vocabulary or redefine the SRS.
Instead, it connects technical concepts to a second set of operational questions:
This guide should therefore be read alongside the relevant SRS and SRD material rather than as a replacement for it.
A useful governance reading of Sigma Runtime begins with a distinction:
The runtime is not only producing output. It is managing the conditions under which long-running interaction remains bounded, continuous, inspectable, and recoverable.
The Runtime Loop, for example, describes a bounded control cycle involving context assembly, stability evaluation, generation, verification, admission, memory integration, and field update.
For a governance stakeholder, that creates questions beyond whether an answer was generated successfully:
This distinction is important because task success and governance success are not necessarily the same thing.
A system may complete an action while leaving unresolved questions about authority, evidence, scope, provenance, memory influence, or accountability.
The following map does not replace the formal definitions in SRS or SRD. It provides an operational interpretation that may help cross-functional stakeholders connect the concepts to familiar governance questions.
| Sigma Runtime concept | Operational governance reading | Governance question |
|---|---|---|
| Recursive Control Loop / Runtime Loop | Governed lifecycle through which context, control signals, candidate output, verification, memory, and state are processed | What controls operated between input and accepted output or action? |
| Interaction Field | Bounded domain in which context, memory, runtime control, and model output interact over time | What information and constraints define the current operating context? |
| Attractor | Stabilized pattern that helps preserve continuity, intent, or behavioral orientation across turns | Is the recurring pattern supporting legitimate continuity, or becoming overly rigid, displaced, or destabilizing? |
| Drift | Progressive loss of coherence, continuity, or bounded control | How would the organization detect that behavior is moving away from the intended operating envelope? |
| Symbolic Density | Signal describing how tightly meaning-bearing structures remain connected within the active field | Is the interaction retaining interpretable structure, or becoming fragmented, overloaded, or excessively compressed? |
| Semantic Compression Ratio (SCR) | Explanatory measure of how efficiently meaning is preserved without unnecessary expansion or fragmentation | Is compression preserving relevant meaning, or obscuring information required for control or review? |
| Persistent State | Continuity-bearing state that survives individual runtime cycles | What information persists, why does it persist, and under what authority can it influence later behavior? |
| Memory | Selective continuity and recall layer rather than automatic replay of all prior history | What information was admitted to memory, what may influence current behavior, and what should remain isolated, stale, private, or non-authoritative? |
| Runtime Self-Model / Self-Modeling Trace | Bounded meta-observability concerning runtime control posture and stability | What diagnostic evidence is being recorded, and how is it prevented from becoming independent authority or unbounded self-reference? |
| Meta-Vector | Structured snapshot of reflective runtime evidence | What runtime conditions or pressures were visible when a control decision was made? |
| Fail-Safe Envelope | Boundary conditions governing narrowing, containment, verification, and recovery | What happens when normal operating tolerances are exceeded? |
| Recovery | Bounded return toward stable operation after degradation or instability | What condition triggered recovery, what was preserved or excluded, and how was successful recovery determined? |
| Containment / Quarantine | Isolation of unstable, unauthorized, or insufficiently trusted material or behavior | What was prevented from influencing normal continuation, and why? |
| Environment Interface Layer (EIL) | Governed boundary between runtime activity and external systems, tools, users, agents, files, or environments | Is external contact permitted, scoped, evidenced, and contestable? |
| Interaction Event Model (IEM) | Semantic description of evidence-bearing contact between the runtime and its environment | What event occurred, in which direction, under what authority, and with what surviving evidence? |
| Observation Event | Information entering the runtime boundary | What was observed, from what source, with what provenance, and does observation actually confer truth or authority? |
| Effect Event | Runtime-originated event capable of changing external state | What was changed, who or what authorized it, and can the effect be audited or contested? |
| Conformance | Evidence-backed statement about an implementation's relationship to public SRS requirements | What version, scope, requirements, deviations, and evidence support the claim? |
One way to make the architecture more accessible across functions is to pair technical questions with governance questions.
Technical reading:
Is the active field moving outside its intended coherence envelope?
Governance reading:
What signal indicates loss of control, what response follows, and what evidence shows whether recovery succeeded?
Technical reading:
Has a recurring configuration stabilized within the interaction field?
Governance reading:
Is that persistence still serving the intended operating purpose, or has a stable pattern become displaced, excessively rigid, or inappropriate for the current scope?
Technical reading:
What state should be recalled or reintegrated?
Governance reading:
Does this information have authority to influence the current interaction, or is it stale, private, externally sourced, scoped to another context, or preserved only for audit?
Technical reading:
What crossed the environment boundary?
Governance reading:
Was the event an observation or an effect? What authority applied? What evidence remains? Can the event later be reconstructed or contested?
Technical reading:
Can the runtime return to a stable operating envelope?
Governance reading:
What triggered the recovery posture, what was contained or preserved, and how was recovery verified?
Operational governance depends not only on whether a control exists, but on whether its operation can later be demonstrated.
Across the public Sigma Runtime architecture, several forms of evidence may be relevant depending on the applicable SRIP and implementation scope, including:
A governance stakeholder may therefore ask:
The exact evidence implementation may vary.
The durable governance principle is that claims about stability, control, recovery, authorization, or conformance should be supportable by evidence appropriate to the claim.
The distinction between observation and authority is particularly important for operational governance.
Sigma's Environment Interaction and Events documentation distinguishes incoming observations from outward effects.
That distinction produces several governance rules of thumb:
Observation is not truth.
Retrieval is not currentness.
Availability is not authority.
Capability is not permission.
Persistence is not permission to influence.
Task completion is not necessarily governance success.
For example, a retrieved document may enter the runtime as an observation.
That does not automatically mean:
Similarly, the existence of a tool or effect surface does not itself authorize its use.
This separation is useful for governance, compliance, privacy, audit, and enterprise control because it prevents information access, behavioral authority, and consequential action from collapsing into a single concept.
The public architecture describes bounded responses to instability, including narrowing, verification, containment, quarantine, reset, dissolution, and recovery.
Those runtime responses do not necessarily determine an organization's complete governance, escalation, or incident process.
A governance reader should therefore ask:
The answers will vary by organization and use case. This guide does not prescribe a mandatory escalation framework, RACI, incident taxonomy, threshold model, or regulatory workflow.
The important distinction is that runtime control does not eliminate organizational accountability.
A governance-facing Reader Guide should preserve the formal SRS conformance vocabulary rather than creating competing certification language.
The current public conformance model is described in SRS Conformance Levels.
An implementation cites, discusses, or uses concepts from SRS/SRIP without claiming technical conformance.
Governance interpretation:
The relationship is informational or conceptual.
A reader may colloquially think of this as being "SRS-informed," but SRS-Referenced is the formal public vocabulary.
Evidence includes attribution and version reference.
Sigma approval is not required.
An implementation intentionally follows selected public SRS/SRIP concepts or requirements without claiming complete conformance.
Governance interpretation:
The organization has made a deliberate alignment claim and should be able to identify what is supported, what is unsupported, and where deviations exist.
Evidence includes:
A truthful self-declaration does not require Sigma approval.
Official certification or badge use does.
These are distinct evidence-backed conformance claims tied to a declared version and scope:
Governance interpretation:
The stronger the claim, the stronger the requirement for version-pinned scope, requirement mapping, evidence artifacts, deviations, and reproducibility.
These levels may be self-declared where permitted by the conformance policy.
They should not be presented as official Sigma certification unless Sigma has actually reviewed and approved the implementation for that certification.
Sigma-Certified means an implementation has completed an official Sigma certification review for the stated version, scope, and level.
Governance interpretation:
Certification is not implied by reference, alignment, or self-declared conformance.
A certification claim should correspond to an official review, defined version and scope, approved evidence, registry listing, and authorized badge use where applicable.
Sigma-Certified Enterprise adds enterprise deployment, support, governance, and operational requirements to technical conformance review.
Governance interpretation:
Enterprise certification is an explicitly reviewed status, not a marketing synonym for enterprise readiness.
Before making a public SRS-related claim, an organization should be able to answer:
A useful governance principle is:
The public claim should never be stronger than the evidence behind it.
For governance, risk, compliance, legal, product, business, and audit readers who are new to Sigma Runtime, the following reading path may be useful.
Focus on:
Focus on:
Focus on:
Focus on:
Focus on:
Consider a long-running runtime interaction in which stability begins to degrade.
A governance-facing reconstruction might ask:
The technical architecture and the organizational governance process answer different parts of this scenario.
The purpose of operational governance is to make their relationship explicit.
This document does not establish:
Those conclusions require evidence and scope appropriate to the claim.
This guide is intended only to help readers translate public Sigma Runtime concepts into operational governance questions without changing their normative meaning.
For non-engineering stakeholders, the central governance question around Sigma Runtime is not only:
What does the runtime do?
It is also:
What is being governed, what evidence remains, what authority applies, what happens when control degrades, who owns the organizational response, and what can later be demonstrated?
The public SRS/SRD corpus already contains concepts that support those questions:
The purpose of this Reader Guide is to make those connections easier to navigate across engineering, product, governance, risk, compliance, legal, audit, operations, and business teams while preserving the technical precision and public/proprietary boundaries of the Sigma Runtime Standard.