Sigma Runtime Standard – License Notice
This document is part of the Sigma Runtime Standard (SRS).
It is licensed under Creative Commons Attribution–NonCommercial 4.0 (CC BY-NC 4.0).The license for this specific document is authoritative.
See/legal/IP-Policyfor the full repository-wide licensing framework.
Version: 1.1
Status: Draft / Implementation Pending
Implementation Target: SIGMA Runtime >= v0.6.x
Depends on: SRIP-09 (LTM), SRIP-10 (AEP), SRIP-11 (CMT)
Related Specs: SRIP-13 (RIS)
Author: Sigma Stratum Research Group
Date: 2026-04-11
License: CC BY-NC 4.0 / Canon CIL Applicable
SRIP-12 defines a deterministic Commerce Decision State Layer (CDS) for product-selection dialogues.
Its goals are to:
This is a runtime business-control layer, not a style layer.
Implementation status: SRIP-12 defines the target CDS architecture and
conformance requirements. It is not considered production-ready until runtime
implementation, scenario testing, and replay validation are complete.
Long-horizon ecommerce dialogues tend to drift toward option expansion:
SRIP-12 resolves this via deterministic state, hard gates, and structured persistence.
| Term | Description |
|---|---|
| Decision Context Store | Per-session structured state for commerce decision control. |
| Primary Anchor | Current primary candidate (model + brand) protected by lock rules. |
| Allowed Candidates | The only candidate set that may be proposed in the current turn. |
| User Exclusions | Explicitly excluded brands/models provided by the user. |
| Rejected Candidates | Candidates explicitly rejected by the user during the session. |
| Decision Phase | Runtime state: discovery, narrowing, anchored, reinforced, transition. |
| Hard Gate | Binary runtime guard that blocks invalid candidate/brand transitions. |
| Off-Table Contract | Deterministic output = user_exclusions + rejected_candidates only. |
| Decision Assertion Model | Structured representation of generated commerce claims against the current decision state. |
| Decision Invariant | A deterministic rule that must remain true after generation, such as anchor lock or off-table integrity. |
| Deterministic Transform | Bounded correction that restores decision invariants without changing the decision state machine. |
| Fallback Response | Minimal compliant response used when invariants cannot be restored by deterministic transform. |
| Enforcement Evidence | Structured metadata describing validation, violations, transform class, and final handling mode. |
| Phase | Behavior |
|---|---|
discovery |
Collect constraints (budget, use-case, exclusions, style requirements). |
narrowing |
Propose up to configured candidate count and select anchor. |
anchored |
Anchor is locked; no new primary unless explicit unlock condition. |
reinforced |
Keep same anchor and adapt explanation to context refinements. |
transition |
Constraint change detected; re-evaluate anchor validity deterministically. |
discovery -> narrowing when minimum constraint threshold is met.narrowing -> anchored when primary candidate is selected and valid.anchored -> reinforced when user refines context without rejection/invalidation.anchored|reinforced -> transition on explicit constraint change.transition -> anchored if anchor remains valid.transition -> narrowing if anchor is rejected or invalidated.Anchor selection moment is defined at the first recommendation turn in narrowing where runtime emits a candidate list.
Primary anchor is:
If user does not explicitly choose, first candidate is considered selected by default and state transitions to anchored.
For identical constraints and identical pool inputs, candidate ordering must be identical.
Deterministic ordering contract:
Ordering metadata (ordering_version, ordering_inputs_hash) must be persisted per decision turn for replay parity.
The rules in this section are decision invariants. They define what must be
true before a commerce response is released. They do not change the decision
state machine in § IV or the allowed-candidate derivation in § VI.
If all are true:
then:
This rule is binary (hard gate), not probabilistic.
When anchor is locked, the runtime must not:
Primary can change only via explicit rejection or hard invalidation.
Constraint changes are classified as:
narrowing).Soft refinements (for example additional context like occasional travel) must not trigger automatic anchor replacement.
Rejection is valid when:
On rejection:
rejected_candidates;primary_anchor;narrowing.When user asks what is off-table, runtime must return only:
user_exclusions (brands/models);rejected_candidates.It must never include:
Internal controls (state, allowed set, guard rules, diagnostics) are runtime-only and must not appear in user-facing text.
allowed_candidates must be derived by state, not by free-form model behavior.
Reference policy:
if state == discovery and constraints < min_constraints_for_narrowing:
allowed_candidates = []
elif state == narrowing and primary_anchor is null:
allowed_candidates = deterministic_pool[:max_initial_candidates]
elif primary_anchor exists and not rejected and not invalidated:
if user_explicitly_requests_alternative:
allowed_candidates = [primary_anchor] + deterministic_secondaries[:alt_limit]
else:
allowed_candidates = [primary_anchor]
elif primary_anchor rejected or invalidated:
allowed_candidates = deterministic_pool_excluding_exclusions_and_rejections[:max_initial_candidates]
else:
allowed_candidates = []
Additional constraints:
allowed_candidates = [] means runtime asks for missing constraints and must not recommend products.narrowing.off-table answers must not read from allowed_candidates.CDS is integrated into each runtime cycle through deterministic hooks:
allowed_candidates (hard gate).If generated response violates CDS invariants, runtime must follow one
deterministic handling path:
Runtime must never forward non-compliant output to user.
Reference flow:
User Input
-> Constraint/Rejection Interpreter
-> State Transition
-> AllowedCandidates Derivation
-> Hidden Guard Build
-> LLM Generation
-> Invariant Validation / Enforcement
-> Persist Decision State + Metadata
CDS remains domain-specific. Its invariants are commerce decision invariants,
not relational identity invariants.
The enforcement architecture is aligned with SRIP-13 in the following sense:
This alignment does not modify CDS phases, anchor rules, candidate ordering, or
domain gating.
{
"version": 1,
"state": "discovery",
"primary_anchor": {
"model_id": null,
"brand": null,
"confidence": 0.0,
"source_cycle": null
},
"candidates_pool": [],
"allowed_candidates": [],
"rejected_candidates": [],
"user_exclusions": {
"brands": [],
"models": []
},
"active_constraints": {
"budget": null,
"use_case": null,
"preferences": [],
"avoids": []
},
"allow_new_brands": true,
"transition_event": null,
"violations": [],
"updated_at": null
}
CDS state is stored per session in structured form (for example session_decision_state table or equivalent store object).
Runtime checkpoint payloads must include full decision state snapshot.
On runtime restore:
CDS is explicitly feature-gated by system profile:
commerce_decision:
enabled: true
min_constraints_for_narrowing: 2
max_initial_candidates: 2
deterministic_ordering: true
alt_limit_when_anchored: 1
allow_new_brands_when_anchored: false
enforcement_mode: transform
For non-commerce domains (for example healthcare, defense, business advisory), CDS is disabled:
commerce_decision:
enabled: false
This ensures no commerce-specific rules are applied outside ecommerce profiles.
CDS adds decision-control telemetry:
decision_transitions_totalanchor_lock_violations_totalanchor_auto_swap_blocked_totalnew_brand_blocked_totalprimary_rejections_totalconstraint_invalidations_totaldeterministic_transforms_totalfallback_responses_totalinvariant_violations_totalEach cycle should include decision state and enforcement evidence in trace metadata.
An implementation of CDS is compliant only if all pass:
SRIP-12 does not:
CDS is a deterministic governance overlay for commerce dialogue control.