Remediation Standards
Home / Standard Packs

Standard Packs

OSERA-SP-0.1.0 was ratified on Thursday, September 10, 2026. It defines the first set of standards that will gate OSERA patch releases. Seven additional standards are tracked in observe mode for OSERA-SP-0.2.0.

Each pack fixes the exact versions of its included standards. Later revisions do not change an existing pack. The catalog shows each standard’s lifecycle status and pack membership separately.

See the standard lifecycle for identifiers, versions, and pack maintenance.

Release history

Pack Status Proposed Gate target Ratified
OSERA-SP-0.1.0 Ratified 2026-08-27 2026-09-20 2026-09-10

OSERA-SP-0.1.0: OSERA Remediation Standards Pack 0.1.0

OSERA-SP-0.1.0 was ratified on Thursday, September 10, 2026. It defines the first set of standards that will gate OSERA patch releases, with seven additional standards in observe mode for OSERA-SP-0.2.0.

Field Value
Status Ratified
Proposed date 2026-08-27
Target gate date 2026-09-20
Ratification 2026-09-10 — agenda
Machine-readable YAML / JSON

Release metadata posture

REL-003 defines the generic consumer outcome and default form where no concrete ecosystem profile exists. Java artifacts use REL-003-JAVA. Source branches and baseline tags are defined separately by FORK-002 and FORK-003.

The generic default form is +osera-patch.NNN, for example 5.3.39+osera-patch.001, where no concrete ecosystem profile exists. Java artifacts follow the REL-003-JAVA profile.

Java in this pack adopts Maven CARE-style versioning with osera in place of care, as agreed in #33. The recorded non-OSGi example is 5.3.39.1-osera-00001. Qualified bases use the CARE alternate-suffix approach; OSGi packaging must respect its three numeric components and optional qualifier. See REL-003-JAVA scenarios for numeric, qualified, and OSGi examples. The generic SemVer default does not apply to Java artifacts.

Approved producers

The approved-producer registry is docs/_data/approved_producers.yml.

Producer registry updates that do not change standard text or check semantics may be handled as patch-level standards-pack updates.

Required standards in v0.1.0

Standard Version Fitness role Rationale
STD-001 0.1.0 Required check The standards group needs a machine-readable source format before ratifying a pack that acceptance gates can consume.
FORK-001 0.1.0 Required check Repository naming and canonical finos-osera location remain the simplest v0.1.0 provenance model; new standardized repositories use patch-*.
FORK-002 0.1.0 Required check Version-scoped patch branches are simple to create and necessary for multiple supported lines.
FORK-003 0.1.0 Required check Baseline tags are essential for source comparison and audit evidence; new standardized baseline tags use +patch.baseline.
SRC-002 0.1.0 Required evidence Provenance links are central to reviewability and auditability.
SRC-003 0.1.0 Required check License-header consistency can be enforced where the local convention is determinable, with a not-applicable result when no convention exists.
REL-001 0.1.0 Required evidence Test provenance stays in scope for v0.1.0 as a published unit-test report artifact, while build provenance and signed source-to-binary proof move to REL-007 observe mode.
REL-002 0.1.0 Required check Runtime compatibility is a high-impact recipient concern and can be measured at publication time.
REL-003 0.1.0 Required base requirement Official signed artifacts should use package-ecosystem patch version naming profiles that optimize recipient tooling outcomes before choosing a concrete syntax.
REL-003-JAVA 0.1.0 Required Java profile check Java artifacts use the ratified CARE-style OSERA naming convention, with compatibility evidence for the relevant packaging, resolvers, dependency-update tools, and feeds.
REL-004 0.1.0 Required check The gate needs an approved-producer allow list so official artifacts come from a known participant.
REL-005 0.1.0 Required check Package metadata and checksum hygiene are practical for the September 20 gate and necessary for reliable consumption.
FEED-001 0.1.0 Required evidence Feeds are necessary for enterprise consumption, and the gate can verify exact purl coverage for official artifacts.

Advisory in v0.1.0

This pack has no advisory standards. Items that need more implementation evidence are tracked in observe mode for v0.2.0 consideration.

Observe mode for v0.2.0

Observe-mode checks run during the v0.1.0 gate to collect evidence and implementation feedback. Their results do not block OSERA-SP-0.1.0 alignment. Promotion requires inclusion in a later ratified pack.

Standard Version Fitness role Rationale
FORK-004 0.0.1 Observe-only check Public source, same-license release, and official-fork hosting are important to recipient trust, but exact evidence rules need v0.2.0 work.
SRC-001 0.0.1 Observe-only check Consumers need patch-basis classification, but the working group needs a controlled vocabulary and minimum wording before it can be enforced.
REL-006 0.0.1 Observe-only check Patch request or backlog authorization is useful, but public/private sponsorship policy is not ready to enforce.
REL-007 0.0.1 Observe-only check Build provenance and signed attestation should be the first v0.2.0 track while the v0.1.0 gate focuses on source provenance, test provenance, and publication hygiene.
REL-008 0.0.1 Observe-only check Build-security scanning is important, but the working group needs evidence about practical scanner coverage across ecosystems before making it enforceable.
EVD-001 0.0.1 Observe-only check Recipient guidance is valuable for routing testing, but the expected format needs v0.2.0 refinement before it can become advisory or required.
APP-001 0.0.1 Observe-only check Estate-wide automated application depends on downstream tooling and recipient operating models that are not proven enough for the first gate.