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.
| Field | Value |
|---|---|
| SRIP | SRIP-12 |
| Title | Commerce Decision State Layer (CDS) |
| Version | 1.2 |
| Status | Active Proposal / Partial Implementation |
| Date | 2026-05-20 |
| Authors / Contributors | Sigma Stratum Research Group (SSRG) |
| Owning Layer | Commerce / Runtime Business Control / Decision State |
| Parent Specs | SRIP-09, SRIP-10, SRIP-11 |
| Related Specs | SRIP-13 |
| 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 | SRS-only |
| Normative Status | Defines a deterministic commerce decision-state control contract. It does not define pricing engines, payment processing, transactional execution, or autonomous commerce authority. |
| Conformance Level | Partial Conformance / Bounded Implementation |
| SRD Synchronization Action | Deferred review |
| Release Alignment Status | Active proposal with partial implementation; no broader production commerce capability is claimed by this document alone. |
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-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.
Long-horizon ecommerce dialogues tend to drift toward option expansion:
SRIP-12 resolves this via deterministic state, hard gates, structured persistence, and bounded hidden guidance.
SRIP-12 defines the normative contract for deterministic commerce decision
control.
Bounded implementations may satisfy parts of this contract before full
conformance is complete. Typical bounded conformance may include:
Full conformance requires replay-grade determinism, durable decision-state
handling, explicit invariant evidence, and sufficient auditability for release
acceptance.
| 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, rewrite class, and final handling mode. |
| Phase | Behavior |
|---|---|
discovery |
Collect constraints such as budget, use-case, exclusions, and 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 or 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 such as ordering_version and ordering_inputs_hash must be persisted 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 § V or the allowed-candidate derivation in § VII.
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 must not trigger automatic anchor replacement.
Rejection is valid when:
On rejection:
rejected_candidates;primary_candidate;narrowing.When user asks what is off-table, runtime must return only:
user_exclusions (brands/models);rejected_candidates.It must never include:
Internal controls such as state, allowed set, guard rules, and 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_candidate is null:
allowed_candidates = deterministic_pool[:max_initial_candidates]
elif primary_candidate exists and not rejected and not invalidated:
if user_explicitly_requests_alternative:
allowed_candidates = [primary_candidate] + deterministic_secondaries[:alt_limit]
else:
allowed_candidates = [primary_candidate]
elif primary_candidate 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 productsnarrowingallowed_candidatesA bounded deterministic CDS path may follow this sequence:
allowed_candidatesReference flow:
User Input
-> Constraint/Rejection Interpreter
-> State Transition
-> AllowedCandidates Derivation
-> Hidden Guard Build
-> LLM Generation
-> Policy Filtering / Rewrite / Fallback
-> Persist Decision State + Metadata
SRIP-12 still requires a deterministic handling path whenever generated commerce output violates the current decision state.
Bounded implementations may realize these invariants through candidate
derivation, mention filtering, deterministic transforms, or fallback handling.
The precise enforcement surface may vary, but the invariant contract does not.
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.
One acceptable decision-state shape is:
{
"version": 1,
"state": "discovery",
"primary_candidate": {
"model_id": null,
"brand": null,
"confidence": 0.0,
"source_cycle": null
},
"secondary_candidates": [],
"anchor_pool": [],
"candidates_pool": [],
"rejected_models": [],
"rejected_candidates": [],
"active_constraints": {
"budget": null,
"excludes": [],
"excludes_brands": [],
"excludes_models": [],
"preferred_brands": [],
"required_properties": [],
"style_avoid": [],
"use_case": null,
"use_case_refinements": [],
"materials": [],
"silhouette": []
},
"user_exclusions": {
"brands": [],
"models": [],
"style": []
},
"allow_new_brands": true,
"surface_memory": {
"repeat_streak": 0,
"clarify_streak": 0,
"last_model_mention_cycle": null,
"last_response_hash": null
},
"ordering_version": 1,
"ordering_inputs_hash": null,
"last_event": null,
"updated_at": null
}
Implementations may also expose cycle-level CDS metadata through runtime or
operator surfaces. Persisted state and per-cycle evidence are related but need
not be identical surfaces.
CDS state should be stored per session in structured form.
Checkpoint, snapshot, review, and reset surfaces are compatible with this SRIP
but are not themselves the normative core of the state machine.
Hydration should:
CDS is explicitly feature-gated by runtime profile/configuration.
Representative config shape:
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
signal_extraction_mode: model
surface_mode: model_first
factual_grounding_enabled: true
Commerce-specific rules should not silently apply outside commerce-governed
flows.
Implementations should expose enough CDS telemetry to audit:
| Capability | Status |
|---|---|
| State machine and anchor semantics | Baseline |
| Deterministic allowed-candidate derivation | Baseline |
| Hidden commerce guidance and leakage suppression | Baseline / evolving |
| Per-session structured persistence | Partial / evolving |
| Decision-state review and reset APIs | Optional implementation surface |
| Ordering metadata for replay parity | Partial |
| Structured signal extraction and mention policy | Partial / evolving |
| Full invariant-assertion and deterministic-transform taxonomy | Implementation Pending |
| Full replay and scenario-validation closeout | Implementation Pending |
| Explicit operator-facing closeout evidence | Implementation Pending |
A release-complete implementation of CDS is compliant only if all pass:
Bounded implementations may satisfy subsets of these criteria before full
conformance closes. Release-complete conformance requires the entire set.
SRIP-12 does not:
CDS remains a deterministic governance overlay for commerce dialogue control.