Remediation Standards
Active Evaluation FINOS Labs This material is provisional and has not been published as a formal FINOS standard.
Home / Standard Packs

Standard Packs

Standard packs collect individually versioned remediation standards into a release candidate or ratified set. A pack version is the thing an implementer targets; each included standard keeps its own version so the working group can revise one standard and include the revision in a later pack.

Standard lifecycle status and standards-pack membership are separate. Ratifying OSERA-SP-0.1.0 should record the exact standard versions included in that pack and set their pack relationship to ratified for that release set. It should not erase later draft work or imply that every future revision of those standards is automatically part of OSERA-SP-0.1.0.

In the catalog, the primary pill shows the standard lifecycle status. The pack pill shows whether that version is a candidate, deferred item, or eventually ratified member of a standards pack.

See the standard lifecycle for guidance on standard identifiers, versions, ratification, and pack creation.

Release history

Pack Status Proposed Target decision Gate target Ratified
OSERA-SP-0.1.0 Revised candidate for discussion 2026-08-27 2026-09-03 2026-09-20 Not ratified

OSERA-SP-0.1.0: OSERA Remediation Standards Pack 0.1.0

Revised candidate pack for the September 3 ratification decision and September 20 gate, using standards-as-code metadata, branded OSERA release identifiers, approved producers, and observe-mode checks for v0.2.0 candidates.

Field Value
Status Revised candidate for discussion
Proposed date 2026-08-27
Target decision date 2026-09-03
Target gate date 2026-09-20
Ratified date Not ratified
GitHub issue Issue #12
Agenda issue Agenda
Standards-as-code issue Issue #23
Proposal branch codex/issue-23-standards-as-code-sp010
Machine-readable YAML / JSON

Release metadata posture

Official OSERA signed artifacts proposed for this pack use +osera-patch.NNN, for example 5.3.39+osera-patch.001.

Existing +backpatch.NNN releases are legacy/proof-of-concept evidence and are not the proposed official signed-artifact naming for this pack.

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.

Observed evidence

Blocking 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 check Official signed artifacts should use branded OSERA release metadata visible in package coordinates and scanner output.
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

No advisory standards are proposed for this pack. 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. They should not block official OSERA-SP-0.1.0 publication unless the working group explicitly promotes them before ratification.

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.

Discussion agenda