Standard Lifecycle

This lifecycle defines how OSERA remediation standards and standards packs move from early proposal to ratified material. It governs versioned publication and maintenance of the standards packs.

The standards group should approve this lifecycle before, or at the same time as, the first ratified standards pack.

Identifiers and versions

Standards use the existing OSERA identifier form:

<CATEGORY>-<NNN>

Examples include FORK-001, REL-003, and FORK-004.

The identifier is stable for the life of the standard. A standard also carries a separate standard-version value. The version changes when the standard text changes; the identifier does not.

Use a new version of the same identifier when the standard is still about the same requirement area:

FORK-004 v0.0.1  Pre-Draft
FORK-004 v0.1.0  Draft
FORK-004 v1.0.0  Ratified
FORK-004 v1.1.0  Revised

Do not create identifiers such as FORK-004.1. The dotted value belongs in standard-version, not in standard_id.

Package-ecosystem or package-manager profiles may extend a base standard by adding an uppercase suffix after the base identifier:

REL-003-JAVA
REL-003-PYTHON
REL-003-JS

Profiles use -PROFILE rather than .PROFILE because requirement and check IDs already use dots, for example REL-003-JAVA.REQ-001 and REL-003-JAVA.CHECK-001.

Profile extension and overrides

An extended standard inherits the checks of its parent standard unless it overrides them.

The check number is the override key:

• REL-003-JAVA.CHECK-001 overrides REL-003.CHECK-001 for the Java profile;
• REL-003-JAVA.CHECK-002 overrides REL-003.CHECK-002 for the Java profile;
• REL-003-JAVA.CHECK-003 adds a new Java-specific check.

Requirement numbers follow the same convention. A profile requirement with the same number specializes the parent requirement for that profile. A new number adds a profile-specific requirement.

Fitness results for a concrete profile should report the effective check set: inherited parent checks that were not overridden, profile checks that override same-number parent checks, and any additional profile-specific checks.

Profile pages expose a generated Relationship to parent section for requirements and checks. It identifies inherited items, same-number overrides, and added items before the profile’s own requirements. Each override carries an override-explanation describing the specialization and preserved parent obligations. The standards-as-code format defines the source fields, generated catalog mapping, and validation rules.

When to create a new standard ID

Create a new standard ID when the proposed material defines a distinct requirement area that implementers could satisfy independently.

Use a new ID when:

• the requirement has a different category or compliance surface;
• the change would be clearer as a separate checklist item in a fitness result;
• the old and new requirements may be included in different standards packs;
• the new requirement can be deferred while the existing standard remains stable.

Do not create a new ID when:

• the change clarifies wording without changing the requirement area;
• the change adds examples, rationale, or evidence fields to the same requirement;
• the change tightens or relaxes the same requirement after implementation feedback;
• the change corrects an error in the current text.

When a new standard replaces an older one, keep the older standard addressable and mark the relationship with supersedes and superseded-by metadata.

Standard statuses

Standards packs

A standards pack records a named set of standard versions. The pack, not an individual standard, is what implementers target for alignment.

Standards packs use the existing OSERA pack naming form:

OSERA-SP-<VERSION>

For example, OSERA-SP-0.1.0 can include FORK-001 v0.1.0, REL-003 v0.1.0, and other specific standard versions.

Ratifying a pack freezes the list of included standard versions for that pack. If FORK-001 later changes to v0.2.0, OSERA-SP-0.1.0 still refers to FORK-001 v0.1.0. A later pack can include the revised version.

Pack patch versions and approved producers

Standards-pack versions use SemVer.

Patch-level pack versions MAY update administrative pack metadata, such as an approved-producer registry, when the standard text, standard versions, check IDs, and check semantics do not change.

For example, OSERA-SP-0.1.1 MAY update the approved-producer registry for the same gate rules as OSERA-SP-0.1.0.

Minor or major pack versions SHOULD be used when standards text, blocking check semantics, or included standard versions change.

When to create a standards pack

Create a standards pack when the working group wants implementers to target a coherent set of requirements together.

Common reasons include:

• establishing an initial acceptance gate;
• publishing a new group of requirements after implementation feedback;
• replacing a prior pack with revised standard versions;
• separating required checks from advisory or deferred material.

A pack should identify:

• pack ID and status;
• proposed date and ratified date, if any;
• target decision date for candidate packs;
• exact included standard IDs and versions;
• deferred standards and rationale;
• issue or meeting record for the decision;
• expected fitness-function checks.
• approved-producer registry or binding, if official signed artifacts depend on producer approval.

Ratification effect

Ratifying a standards pack does not automatically ratify future edits to its included standards.

Ratification means the standards group has approved a specific pack record and the exact standard versions named in that record. Later revisions need their own review and inclusion in a later pack.

Fitness function relationship

The fitness function should report the standards pack tested, the exact standard versions tested, and the result for each check.

For v0.1.0, repositories should claim standards-pack alignment only against a named ratified pack. Certification language should wait until the working group approves a certification or accreditation process.