Sigma Runtime Standard - Public Specification Notice
This document is part of the Sigma Runtime Standard (SRS) public specification layer.Specification License: CC BY 4.0.
Implementation Safe Harbor: independent implementation permitted under public SRS/SRIP terms.
Machine-readable artifacts: Apache License 2.0 where explicitly marked.
Marks / Certification: governed by Sigma Marks and Certification Policy.
Proprietary Runtime Assets: not licensed by this SRIP.Independent implementations of public SRS/SRIP normative requirements are welcome under the public specification terms.
Product assets, protected Sigma marks, official certification, compatibility badges, CC BY-NC commercial use, and patent commitments use the relevant policy or explicit covenant. Independent implementation, attribution, or citation does not imply certification, endorsement, partnership, official compatibility, or permission to use Sigma marks as product identity.
Bounded Commerce Semantic Retrieval, Runtime Bundles, and Operationally Grounded AI Context
| Field | Value |
|---|---|
| SRIP | SRIP-18 |
| Title | Commerce Semantic Integration Layer (CSI) |
| Version | Public Draft v0.3 |
| Status | Public Draft / Implementation-Ready Architecture |
| Date | 2026-05-20 |
| Authors / Contributors | Vladimir Ryabinskiy; Sigma Stratum Research Group (SSRG) |
| Owning Layer | Commerce / Semantic Integration / Memory-Retrieval Boundary |
| Parent Specs | SRIP-09, SRIP-11, SRIP-14 |
| Related Specs | SRIP-03, SRIP-06, SRIP-07, SRIP-10, SRIP-12, SRIP-13, SRIP-15, SRIP-16, SRIP-17 |
| Specification License | CC BY 4.0 |
| Implementation Safe Harbor | Independent implementation permitted under public SRS/SRIP terms |
| Machine-Readable Artifacts | Apache 2.0 where explicitly marked |
| Marks / Certification | Governed by Sigma Marks and Certification Policy |
| Proprietary Runtime Assets | Not licensed by this SRIP |
| Independent Implementation | Permitted under the public specification terms |
| Commercial Runtime Boundary | Relevant policy or explicit covenant for protected Sigma marks, official certification, managed deployment, white-label, resale, CC BY-NC commercial use, and patent commitments |
| Information Class | Open |
| Change Class | Mixed SRS+SRD |
| Normative Status | Defines a bounded semantic integration layer and implementation-ready architecture contract for commerce-oriented runtime retrieval. It does not define commerce decision authority, pricing engines, transactional execution, or unrestricted reasoning governance. |
| Conformance Level | Implementation-Ready Architecture |
| SRD Synchronization Action | Deferred follow-up synchronization for retrieval architecture, runtime bundle documentation, and deployment topology explanation. |
| Release Alignment Status | Implementation-ready public draft; no production deployment, synchronization, freshness, or runtime enablement guarantee is claimed. |
Independent implementations of the public normative requirements in this SRIP are welcome under the applicable public specification terms.
No Sigma commercial runtime license is needed solely because an independent implementation follows those public normative requirements.
Product assets, protected Sigma marks, official certification, compatibility badges, CC BY-NC commercial use, and patent commitments use the relevant policy or explicit covenant. Independent implementation, attribution, or citation does not imply certification, endorsement, partnership, official compatibility, or permission to use Sigma marks as product identity.
SRIP-18 defines the Commerce Semantic Integration Layer (CSI) for Sigma Runtime.
CSI transforms operational commerce data into bounded, runtime-governed semantic material suitable for retrieval, memory integration, and constrained runtime context assembly.
CSI introduces:
CSI is not a commerce authority layer. It is a semantic integration layer positioned between operational commerce systems and the runtime retrieval surfaces governed by SRIP-14.
Operational commerce systems are optimized for:
AI runtime systems require:
Direct SQL-to-prompt architectures create severe failure modes:
Commerce cognition therefore requires a dedicated semantic integration boundary.
CSI does not define:
CSI is not a second ERP system or hidden operational backend.
A conformant CSI implementation must:
Prototype conformance does not require:
Full implementation readiness requires:
| Concept | Description |
|---|---|
| Runtime Bundle Layer | Semantic-ready commerce snapshots derived from operational storage. |
| Runtime Bundle Store | Implementation-neutral storage for runtime bundles. A document database is one possible implementation, not a conformance requirement. |
| Base Semantic Record | Stable semantic representation of an operational commerce entity. |
| Dynamic Overlay | Runtime-applied semantic delta such as pricing, stock, visibility, promotion, or delivery state. |
| Scope Resolution Layer (SRL) | Runtime layer that resolves tenant, policy, visibility, language, currency, and capability context before retrieval. |
| Semantic Budget | Bounded cognition constraints limiting runtime semantic load. |
| Semantic Assembler | Runtime component responsible for bounded semantic composition. |
| Cognitive Telemetry | Traceability and observability layer for runtime semantic retrieval. |
| Operational Semantic Grounding | Requirement that semantic records remain operationally supported rather than interpretively embellished. |
| Authority Boundary | Rule that CSI may provide grounded retrieval context but must not become the source of transactional or decision authority. |
| Freshness Class | Declared currency of semantic material, such as static, snapshot, near-current, or live-bound. |
| Grounded Claim | A statement that can be traced to a source field, derived bundle field, overlay, or accepted semantic transformation. |
| Semantic Projection | Runtime-assembled view composed from a base record, overlays, scope, and semantic budget. |
CSI sits between operational commerce systems and runtime retrieval layers.
Operational Commerce Systems
->
Bundle Builder
->
Runtime Bundle Store
->
CSI Semantic Compression
->
RMI-Compatible Semantic Store
->
RMI Retrieval
->
Semantic Assembler
->
Bounded AI Context
->
Runtime Generation Layer
CSI is therefore:
Storage choices such as document databases, vector databases, graph stores, or hybrid stores are implementation details unless a later SRIP explicitly standardizes one of them.
CSI is tightly coupled to SRIP-14 and SRIP-12, but it does not replace either layer.
SRIP-14 defines retrieval and memory integration governance. CSI supplies commerce-specific semantic material that can be consumed by RMI-compatible retrieval.
CSI must remain subordinate to RMI constraints for:
CSI must not allow raw retrieved commerce data to bypass RMI governance.
SRIP-12 defines deterministic commerce decision state, including anchors, allowed candidates, rejection handling, and invariant enforcement.
CSI may provide operationally grounded commerce facts or candidate records to a CDS-enabled flow, but CSI must not:
When both layers are present, CSI supplies bounded semantic context and CDS governs decision authority.
CSI introduces the:
Runtime Commerce Bundle Layer
Runtime bundles are semantic-ready snapshots optimized for retrieval and semantic transformation.
A prototype implementation may use a document-store collection such as:
runtime_product_bundles
This storage shape is illustrative, not normative.
Example bundle:
{
"canonical_entity_id": "product:demo-bath-170",
"sku": "BATH-170-WH",
"brand": {
"name": "Example Home"
},
"title": "Example Home 170 x 70 cm acrylic bathtub",
"parameters": {
"length_cm": 170,
"width_cm": 70,
"anti_slip": true,
"legs_included": false
},
"stock_summary": {
"available": 10
},
"source_updated_at": "2026-05-14T00:00:00Z"
}
Runtime bundles are semantic-ready snapshots, not source-of-truth systems.
A CSI runtime bundle must preserve the following categories, even if an implementation uses different physical storage:
| Category | Requirement |
|---|---|
| Identity | Stable canonical entity identifier and source system reference. |
| Source provenance | Source table, API, feed, or upstream record reference sufficient for audit. |
| Semantic payload | Normalized semantic fields that may be used for retrieval or assembly. |
| Operational facts | Facts that remain supported by upstream commerce data. |
| Overlay hooks | References or keys that allow dynamic overlays to be applied without multiplying base records. |
| Freshness metadata | Timestamp, version, or freshness class for the semantic snapshot. |
| Scope metadata | Tenant, storefront, visibility, role, language, or region applicability where relevant. |
Minimum illustrative shape:
{
"bundle_id": "bundle:product:demo-bath-170:v1",
"entity": {
"type": "product",
"canonical_entity_id": "product:demo-bath-170",
"source_ref": "catalog.products:demo-bath-170"
},
"semantic_payload": {
"title": "Example Home 170 x 70 cm acrylic bathtub",
"category": "bathroom_fixture",
"attributes": {
"length_cm": 170,
"width_cm": 70,
"anti_slip": true
}
},
"overlay_keys": [
"price",
"stock",
"visibility"
],
"scope": {
"tenant_id": "tenant:demo",
"storefront_id": "storefront:primary",
"language": "en",
"currency": "USD"
},
"freshness": {
"class": "snapshot",
"source_updated_at": "2026-05-14T00:00:00Z",
"bundle_created_at": "2026-05-14T00:05:00Z"
},
"provenance": {
"builder_version": "csi-bundle-builder:v1",
"source_hash": "sha256:example-source",
"bundle_hash": "sha256:example-bundle"
}
}
A bundle is invalid for retrieval if:
Invalid bundles must be excluded from runtime retrieval or quarantined for operator review.
CSI must not treat all semantic material as equally current.
Minimum freshness classes:
| Freshness class | Meaning | User-facing constraint |
|---|---|---|
static |
Stable descriptive data unlikely to change frequently, such as dimensions or category. | May be used for stable factual description. |
snapshot |
Point-in-time semantic snapshot derived from operational data. | Must not be presented as live price, stock, or availability. |
near_current |
Recently refreshed data within a declared synchronization window. | May support time-bounded claims if the freshness window is disclosed or internally verified. |
live_bound |
Data fetched or validated through an authoritative live operational surface. | May support current transactional claims only within the validated scope. |
unknown |
Freshness cannot be proven. | Must not support freshness-sensitive commerce claims. |
Synchronization models are implementation-specific, but the selected model must declare:
The following pattern is prohibited for general runtime materialization:
product
x partner
x warehouse
x promotion
x role
x currency
x language
CSI must instead separate:
Base Semantic Record
+
Dynamic Overlays
+
Runtime Projection Assembly
Overlay examples include:
Principle:
Dynamic context must be layered, not multiplied.
Retrieval layers must consume resolved runtime scopes.
Architecture:
User Request
->
Scope Resolution Layer
->
Resolved Scope
->
RMI Retrieval
Operational policy complexity must not be duplicated inside retrieval layers.
Example resolved scope:
{
"resolved_scope_id": "scope_8821",
"tenant_id": "tenant:demo",
"storefront_id": "storefront:primary",
"currency": "USD",
"language": "en",
"capabilities": [
"commerce:catalog.retrieve"
],
"visibility_scope": [
"public_catalog",
"in_stock"
],
"issued_at": "2026-05-14T00:10:00Z",
"expires_at": "2026-05-14T00:20:00Z"
}
Currency identifiers should use ISO 4217 codes. Language identifiers should use BCP 47 tags. Local examples may be used only when the SRIP explicitly concerns localization behavior.
A resolved scope must be computed before CSI retrieval and must include enough information to prevent accidental cross-scope retrieval.
Minimum scope fields:
| Field | Requirement |
|---|---|
resolved_scope_id |
Stable identifier for the current resolved scope. |
tenant_id |
Required for multi-tenant or tenant-aware deployments. |
storefront_id |
Required when commerce surfaces differ by storefront. |
capabilities |
Allowed retrieval capabilities for the current request. |
visibility_scope |
Explicit visibility envelope such as public catalog, authenticated account, partner view, or internal-only view. |
language |
Declared runtime language or localization target. |
currency |
Declared currency context when commerce values may be displayed or ranked. |
issued_at |
Time when scope was resolved. |
expires_at |
Optional expiration time for short-lived scopes. |
If tenant, storefront, visibility, capability, language, or currency scope cannot be resolved safely, CSI retrieval must fail closed.
Fail-closed behavior may:
It must not guess scope, reuse a stale scope silently, or retrieve from a broader scope than the current request authorizes.
AI runtime context is treated as:
bounded cognition surface
rather than unrestricted data export.
Example semantic budget:
{
"max_records": 5,
"max_facts": 20,
"max_constraints": 10,
"max_tokens": 1200,
"max_overlay_depth": 3
}
Pipeline:
Retrieval
->
Semantic Assembler
->
Bounded AI Context
Assembler responsibilities may include:
The semantic assembler must produce a bounded context package rather than an unrestricted export.
Minimum output categories:
Illustrative assembly envelope:
{
"assembly_id": "assembly_20260514_001",
"scope_id": "scope_8821",
"budget": {
"max_records": 5,
"max_facts": 20,
"max_tokens": 1200
},
"records": [
{
"bundle_id": "bundle:product:demo-bath-170:v1",
"facts": [
"170 x 70 cm acrylic bathtub",
"anti-slip surface",
"legs not included"
],
"freshness_class": "snapshot",
"source_refs": [
"catalog.products:demo-bath-170"
]
}
],
"omissions": [],
"grounding_refs": [
"sha256:example-bundle"
]
}
When CSI, RMI, and CDS are all present, a bounded implementation should follow this sequence:
CSI does not select the final recommendation by itself. It supplies grounded semantic material into layers that retain their own authority.
Prototype implementations may optionally support:
Retrieval Ranking Layer (RRL)
Potential ranking factors include:
RRL remains optional for SRIP-18 v0.3 conformance.
RRL must not become a hidden decision engine. Ranking may order candidate semantic records for retrieval, but it must not claim commercial authority, override CDS allowed-candidate derivation, or silently promote unsupported products.
CSI semantic compression must preserve operational semantics.
Allowed transformations:
extract
normalize
compress
summarize
structure
Forbidden transformations:
marketing embellishment
unsupported quality claims
invented positioning
emotional interpretation
Allowed example:
"A 170 x 70 cm acrylic bathtub with an anti-slip surface."
Forbidden example unless operationally supported:
"A premium comfort bathtub for luxury living."
Principle:
CSI describes what commerce data supports.
CSI does not invent what commerce data implies.
A generated commerce statement is grounded only when it can be traced to at least one of:
User-facing commerce claims must not be produced from:
If a response depends on stale, snapshot, or incomplete commerce data, the runtime should either:
CSI must never present semantic snapshot data as live transactional truth unless the integration has a live-bound freshness class and supporting operational authority.
CSI implementations are not expected to materialize all operational commerce data into semantic memory.
Implementations may selectively materialize:
based on runtime usefulness.
Principle:
Operational completeness
!=
semantic usefulness
Conformant CSI implementations must declare their runtime language and localization strategy.
A bounded prototype may operate in one declared runtime language. This does not make that language normative for SRIP-18.
Public examples in this SRIP use English. Currency examples use ISO 4217 codes such as USD.
Canonical commercial identity markers may remain in original form:
CONTINENTAL
Bosch
Grohe
because they are operational identity markers rather than localized semantic runtime content.
Mixed-language retrieval and localization-aware semantic ranking are optional for SRIP-18 v0.3 and must not compromise grounding, provenance, or scope traceability when introduced.
Localization support is implementation-ready only when:
If these conditions are not met, implementation may remain single-language while declaring that limitation explicitly.
Traceability is treated as:
Cognitive Telemetry Layer
rather than debug-only logging.
Example trace:
{
"trace_id": "trace_20260514_001",
"scope_id": "scope_8821",
"retrieved_entities": [
"product:demo-bath-170"
],
"semantic_records": [
"bundle:product:demo-bath-170:v1"
],
"overlays": [
"stock:current"
],
"constraints_applied": [
"tenant_scope",
"visibility_scope",
"semantic_budget"
],
"context_hash": "sha256:example-context",
"answer_hash": "sha256:example-answer"
}
Future telemetry systems may support:
SRIP-18 governs:
SRIP-18 does not define:
Existing runtime reasoning, attractor, safety, density, identity, and memory-governance constraints remain governed by their respective SRIPs. Future specifications may extend those constraints, but CSI must not redefine them by implication.
CSI deployments must enforce tenant and storefront isolation.
A dedicated single-tenant topology is a valid strong isolation pattern:
dedicated backend
dedicated operational store
dedicated runtime bundle store
dedicated CSI worker
dedicated semantic memory surface
dedicated RMI API surface
This topology is illustrative, not mandatory.
A multi-tenant implementation may be conformant only when it provides equivalent isolation guarantees, including:
Principle:
Cross-store retrieval must be impossible unless an explicit, governed scope authorizes it.
Isolation is treated as a security primitive rather than infrastructure style.
CSI must preserve:
CSI must not:
Incoming semantic retrieval context should always remain bounded, scoped, and operationally attributable.
If implemented within these boundaries, CSI should enable:
The intended outcome is bounded commerce cognition, not autonomous commerce authority.
CSI implementations must explicitly account for the following failure modes:
| Risk | Failure mode | Required mitigation |
|---|---|---|
| Scope leakage | Retrieval returns another tenant, storefront, role, or partner record. | Fail-closed scope resolution and auditable scope evidence. |
| Authority confusion | Semantic retrieval is treated as pricing, inventory, order, or recommendation authority. | Explicit authority boundary and CDS/RMI precedence. |
| Stale commerce claims | Snapshot data is presented as live price, stock, or availability. | Freshness classes and claim narrowing. |
| Projection explosion | Runtime materializes every product x role x warehouse x promotion variant. | Base record plus overlay composition. |
| Unsupported embellishment | Compression adds marketing or quality claims not present in source data. | Grounded claim contract and forbidden transformation rules. |
| Raw data flooding | Operational records are appended directly into prompts. | Semantic budget, assembler, and RMI-governed injection. |
| Provenance loss | Retrieved context cannot be traced to source bundle or operational record. | Bundle provenance, traceability evidence, and context hashes. |
| Localization drift | Translation changes product meaning, constraints, measurement, or scope. | Localization metadata and declared language boundaries. |
| Hidden decision override | Retrieval ranking silently changes CDS anchor or allowed candidates. | RRL non-authority rule and CDS boundary validation. |
High-risk implementations must include test coverage or operator evidence for scope leakage, stale claims, provenance loss, and authority confusion before release.
| Capability | v0.3 status |
|---|---|
| Architecture boundary | Baseline |
| Runtime bundle contract | Baseline |
| Resolved scope contract | Baseline |
| Freshness and synchronization classes | Baseline |
| Grounded claim contract | Baseline |
| CSI/RMI integration sequence | Baseline |
| CSI/CDS authority boundary | Baseline |
| Isolation-first deployment requirements | Baseline |
| Retrieval ranking layer | Optional |
| Localization-aware retrieval | Optional / deferred |
| Production freshness guarantees | Deferred |
| Production telemetry dashboards | Deferred |
| Versioned semantic index migration | Deferred |
| Full SRD explanatory synchronization | Deferred |
A future implementation may claim SRIP-18 v0.3 implementation readiness only if all baseline criteria pass:
Release-complete conformance requires additional production evidence for synchronization, freshness, observability, and recovery behavior. This v0.3 draft defines the architecture contract needed before such work begins.
SRIP-18 v0.3 is ready to guide future implementation work in the following sense:
It is not a claim that a conformant production implementation already exists.
Implementation planning should produce:
SRIP-18 is an implementation-ready public draft architecture proposal.
It does not claim production-grade synchronization, freshness guarantees, deployment topology finality, runtime enablement, or complete SRD synchronization.
It does not claim:
Future revisions may later define:
End of SRIP-18 Public Draft v0.3
Sigma Stratum Research Group - 2026