Sigma Stratum Documentation – License Notice
This document is part of the Sigma Runtime Standard (SRS) and the
Sigma Stratum Documentation Set (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 SRIP Process defines how the Sigma Runtime Standard (SRS) evolves through transparent, peer-reviewed contributions under the governance of the Sigma Stratum Research Group (SSRG).
Each SRIP represents a proposed modification, extension, or clarification of the Sigma Runtime architecture.
All accepted SRIPs are versioned, archived, and integrated into the canonical SRS specification, while all revisions and historical proposals are tracked in the SRIP Registry.
| Stage | Description |
|---|---|
| 0. Candidate | Intake proposal before public numbering or public draft acceptance. Used for external or early architectural proposals that still require boundary, scope, and related-spec review. |
| 1. Formation Draft v0.1 | Initial specification authored by contributor(s). Must follow the SRIP template and include motivation, rationale, technical description, and required traceability data. |
| 2. Public Draft v0.2+ | Public-review-ready draft with normalized metadata, public boundary classification, non-goals, conformance scope, and truthful SRD synchronization state. |
| 3. Implementation-Ready Architecture | Public draft mature enough to guide implementation planning. Requires layer boundary, contracts, conformance expectations, risk boundaries, and acceptance criteria. It does not claim that implementation already exists. |
| 4. Active Proposal | Steering Committee accepts the SRIP as an active normative proposal. |
| 5. Partial Implementation | One or more implementations satisfy a bounded subset of the SRIP while full conformance remains open. |
| 6. Aligned | Public SRS/SRD synchronization is complete or truthfully declared as aligned for the approved release state. |
| 7. Superseded / Deprecated | Historical state for proposals replaced or retired by later SRIPs while preserving persistent references. |
The SRIP draft pipeline separates private or editorial formation from a public
registry draft.
Draft v0.1 is the formation stage. It may exist as an authoring draft,
editorial intake, or registry candidate, but it is not yet a public-review-ready
SRIP.
Before advancement, the draft must pass:
Open or Derived-Public;SRS-only, SRD-only, or Mixed SRS+SRD;If these fields are missing or not truthful, the draft must remain at v0.1.
Public Draft v0.2 is the first public-review-ready version.
To advance from v0.1 to Public Draft v0.2, editors must ensure that:
Canonical metadata checklist for Public Draft v0.2+:
| Field | Required Meaning |
|---|---|
| SRIP | immutable proposal identifier |
| Title | public title |
| Version | public draft or accepted version |
| Status | lifecycle status from this process |
| Date | ISO date of the current public revision |
| Authors / Contributors | public authorship and contributor attribution |
| Owning Layer | standards layer or architecture domain |
| Parent Specs | normative dependencies |
| Related Specs | non-parent related specifications |
| License | documentation license plus implementation covenant applicability |
| Information Class | Open or Derived-Public |
| Change Class | SRS-only, SRD-only, or Mixed SRS+SRD |
| Normative Status | what the document binds, if anything |
| Conformance Level | maturity or conformance level |
| SRD Synchronization Action | completed, deferred with target, or not applicable |
| Release Alignment Status | truthful release or public-documentation alignment claim |
Wiki frontmatter may remain for the publishing platform, but it does not
replace the public SRIP metadata table.
After Public Draft v0.2, later draft versions may refine terminology,
conformance, examples, or synchronization evidence, but they must not remove the
traceability fields.
Publication rule:
v0.1 draft may be discussed or reviewed internally;Public Draft v0.2+ draft may be cited as a public SRIP draft;Active SRIP still requires the normal approval and integration stages.SRIP-01, SRIP-02, etc.).SRIP-00 defines foundational and procedural rules.SRIP numbers are immutable proposal identifiers.
Numbering rules:
This means a later-numbered SRIP may logically precede an earlier-numbered SRIP in a particular architecture stack. The number records proposal history; the reading-order index records conceptual navigation.
All SRIPs beginning with SRIP-09 and later are tracked through the
Sigma Stratum SRIP Registry, located under /srs/registry/ in the
sigmastratum/documentation repository.
This ensures that:
Publicly relevant active, draft, and implementation-ready proposals are listed in the /srs/active-srips.md index, while the Registry contains the complete historical record.
Publication gate:
Each SRIP should declare or be classified by:
Track: foundational, runtime-control, memory-retrieval, commerce, multi-agent, observability, safety, privacy, governance, or another named track;Architecture Layer: business, data, application, runtime, control, integration, telemetry, or governance;Extends: SRIPs whose contract is extended;Amends: SRIPs whose normative contract is changed;Supersedes: SRIPs replaced by the proposal;Parent Specs: mandatory normative dependencies;Related Specs: relevant but non-parent specifications.Architecture reading order is maintained separately from numerical order.
Recommended public navigation views:
For example, a commerce implementation may be easier to read as:
This does not require renumbering any SRIP.
SRIPs may function as architecture design artifacts when they define:
The SRIP process is open-standard-first and framework-independent.
TOGAF or similar enterprise-architecture methods may be used as a non-normative review lens. They are not binding dependencies for writing, reviewing, citing, or implementing SRIPs.
Architecture-impacting SRIPs should be reviewable across:
This compatibility discipline helps reviewers identify gaps without making the Sigma Runtime Standard dependent on TOGAF terminology, certification, or process.
Every SRIP proposal must include the following minimum traceability data:
Open or Derived-PublicSRS-only, SRD-only, or Mixed SRS+SRDAllowed release alignment status values:
alignedaligned with deferred SRD syncno public-doc impactIf a proposal cannot truthfully declare these fields, it is not ready for review.
Use these terms consistently in public SRIPs:
| Term | Meaning |
|---|---|
Conceptual |
Defines vocabulary, theory, or framing only. |
Public Draft |
Suitable for public review, not implementation authority by itself. |
Implementation-Ready Architecture |
Mature enough to guide implementation planning without claiming production deployment. |
Bounded Implementation |
A partial implementation satisfies a named subset of the SRIP. |
Partial Conformance |
Implementation covers a bounded subset of normative requirements. |
Minimum Conformance |
Implementation satisfies the minimum public contract. |
Full Conformance |
Implementation satisfies the full normative contract. |
Production-Claimed |
A named implementation claims production conformance and must provide evidence. |
Avoid using Production Ready as a document status unless it is tied to a
specific implementation conformance claim and evidence record.
Public SRIPs must clearly separate:
Provider-specific examples, code snippets, deployment topology, and runtime
implementation details are non-normative unless the SRIP explicitly defines a
public protocol or schema.
To submit a new SRIP:
sigmastratum/documentation repository.srip-XX-your-title./templates/SRIP-TEMPLATE.md.SRIP Proposal.Upon approval, the SRIP will be merged and tagged for the next release cycle,
and an archival copy will be stored in the /srs/registry/ directory.
All SRIPs are reviewed by:
The Editorial Board must also verify:
Each accepted SRIP is:
/srs/);/srd/);/srs/registry/);This two-tier archival system (Active + Registry) ensures that the canonical runtime
remains lightweight, while the Registry preserves a full evolutionary record
of all proposals, drafts, and superseded versions.
The documentation repository is human-write-controlled.
Therefore:
This rule applies to SRIP proposals the same way it applies to any other public document.
The SRIP process ensures:
For general inquiries or submissions:
contact@sigmastratum.org
Summary:
The SRIP Process provides a structured path for the evolution of the Sigma Runtime Standard — ensuring every architectural change is transparent, reviewed, archived, and permanently recorded in the Sigma Stratum Registry as part of the open standard framework.