schema-version: 0.1.0
pack:
  schema-version: 0.1.0
  id: OSERA-SP-0.1.0
  title: OSERA Remediation Standards Pack 0.1.0
  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
  issue: https://github.com/finos-osera/remediation-standards/issues/12
  agenda_issue: https://github.com/finos-osera/remediation-standards/issues/24
  standards_as_code_issue: https://github.com/finos-osera/remediation-standards/issues/23
  branch: codex/issue-23-standards-as-code-sp010
  summary: 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.
  release_metadata:
    official_token: osera-patch.NNN
    official_example: 5.3.39+osera-patch.001
    legacy_token: backpatch.NNN
    legacy_posture: Existing +backpatch.NNN releases are treated as legacy/proof-of-concept
      evidence and are not the proposed official signed-artifact naming for OSERA-SP-0.1.0.
  approved_producers:
    registry: docs/_data/approved_producers.yml
    lifecycle_policy: Producer registry updates that do not change standard text or
      check semantics may be handled as patch-level standards-pack updates.
  evidence_summary:
  - 60 public finos-osera/backpatch-* repositories observed on 2026-08-25.
  - 59 legacy/proof-of-concept baseline tags observed in the form `v<VERSION>+backpatch.baseline`
    across 59 repositories.
  - 61 legacy/proof-of-concept release tags observed in the form `v<VERSION>+backpatch.NNN`
    across 55 repositories.
  - Issue 13 discussion favored visible OSERA branding in release metadata for SCA,
    inventory, and audit workflows.
  - Issue 23 proposed Markdown plus structured YAML front matter, schema validation,
    and generated catalog artifacts as the standards-as-code model.
  included_standards:
  - id: STD-001
    version: 0.1.0
    role: Required check
    rationale: The standards group needs a machine-readable source format before ratifying
      a pack that acceptance gates can consume.
    checks:
    - STD-001.CHECK-001
    - STD-001.CHECK-002
  - id: FORK-001
    version: 0.1.0
    role: Required check
    rationale: Repository naming and canonical finos-osera location remain the simplest
      v0.1.0 provenance model; new standardized repositories use patch-*.
    checks:
    - FORK-001.CHECK-001
    - FORK-001.CHECK-002
  - id: FORK-002
    version: 0.1.0
    role: Required check
    rationale: Version-scoped patch branches are simple to create and necessary for
      multiple supported lines.
    checks:
    - FORK-002.CHECK-001
  - id: FORK-003
    version: 0.1.0
    role: Required check
    rationale: Baseline tags are essential for source comparison and audit evidence;
      new standardized baseline tags use +patch.baseline.
    checks:
    - FORK-003.CHECK-001
  - id: SRC-002
    version: 0.1.0
    role: Required evidence
    rationale: Provenance links are central to reviewability and auditability.
    checks:
    - SRC-002.CHECK-001
  - id: SRC-003
    version: 0.1.0
    role: Required check
    rationale: License-header consistency can be enforced where the local convention
      is determinable, with a not-applicable result when no convention exists.
    checks:
    - SRC-003.CHECK-001
  - id: REL-001
    version: 0.1.0
    role: Required evidence
    rationale: 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.
    checks:
    - REL-001.CHECK-001
  - id: REL-002
    version: 0.1.0
    role: Required check
    rationale: Runtime compatibility is a high-impact recipient concern and can be
      measured at publication time.
    checks:
    - REL-002.CHECK-001
  - id: REL-003
    version: 0.1.0
    role: Required check
    rationale: Official signed artifacts should use branded OSERA release metadata
      visible in package coordinates and scanner output.
    checks:
    - REL-003.CHECK-001
    - REL-003.CHECK-002
  - id: REL-004
    version: 0.1.0
    role: Required check
    rationale: The gate needs an approved-producer allow list so official artifacts
      come from a known participant.
    checks:
    - REL-004.CHECK-001
    - REL-004.CHECK-002
  - id: REL-005
    version: 0.1.0
    role: Required check
    rationale: Package metadata and checksum hygiene are practical for the September
      20 gate and necessary for reliable consumption.
    checks:
    - REL-005.CHECK-001
    - REL-005.CHECK-002
  - id: FEED-001
    version: 0.1.0
    role: Required evidence
    rationale: Feeds are necessary for enterprise consumption, and the gate can verify
      exact purl coverage for official artifacts.
    checks:
    - FEED-001.CHECK-001
    - FEED-001.CHECK-002
  advisory_standards: []
  observe_standards:
  - id: FORK-004
    version: 0.0.1
    role: Observe-only check
    rationale: Public source, same-license release, and official-fork hosting are
      important to recipient trust, but exact evidence rules need v0.2.0 work.
    checks:
    - FORK-004.CHECK-001
    - FORK-004.CHECK-002
    - FORK-004.CHECK-003
  - id: SRC-001
    version: 0.0.1
    role: Observe-only check
    rationale: Consumers need patch-basis classification, but the working group needs
      a controlled vocabulary and minimum wording before it can be enforced.
    checks:
    - SRC-001.CHECK-001
  - id: REL-006
    version: 0.0.1
    role: Observe-only check
    rationale: Patch request or backlog authorization is useful, but public/private
      sponsorship policy is not ready to enforce.
    checks:
    - REL-006.CHECK-001
  - id: REL-007
    version: 0.0.1
    role: Observe-only check
    rationale: 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.
    checks:
    - REL-007.CHECK-001
    - REL-007.CHECK-002
  - id: REL-008
    version: 0.0.1
    role: Observe-only check
    rationale: Build-security scanning is important, but the working group needs evidence
      about practical scanner coverage across ecosystems before making it enforceable.
    checks:
    - REL-008.CHECK-001
    - REL-008.CHECK-002
  - id: EVD-001
    version: 0.0.1
    role: Observe-only check
    rationale: Recipient guidance is valuable for routing testing, but the expected
      format needs v0.2.0 refinement before it can become advisory or required.
    checks:
    - EVD-001.CHECK-001
  - id: APP-001
    version: 0.0.1
    role: Observe-only check
    rationale: Estate-wide automated application depends on downstream tooling and
      recipient operating models that are not proven enough for the first gate.
    checks:
    - APP-001.CHECK-001
  deferred_standards:
  - id: FORK-004
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode for OSERA-SP-0.1.0 and expected to be reconsidered
      for OSERA-SP-0.2.0.
  - id: SRC-001
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until patch-basis vocabulary and provider wording
      are defined.
  - id: REL-006
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until the backlog and private sponsorship model
      is settled.
  - id: REL-007
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until producer signed build provenance is specified
      and implemented.
  - id: REL-008
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until package ecosystem scanning expectations
      and evidence formats are defined.
  - id: EVD-001
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until the recipient guidance format is better
      defined.
  - id: APP-001
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until estate-wide application workflows are
      proven.
  discussion_topics:
  - Whether the standards-as-code schema is sufficient for the September 3 decision
    and September 20 gate or needs narrower scope.
  - Whether official OSERA signed artifacts should use SemVer build metadata, Maven-style
    qualifiers, or ecosystem-specific profiles for `+osera-patch.NNN`-style release
    identifiers.
  - Whether new standardized repositories and source branches should use `patch-*`
    and `patch/`, while historical `backpatch-*` repositories remain legacy/proof-of-concept
    evidence.
  - How the approved-producer registry is approved, updated, signed, and bound to
    pack patch versions.
  - Which build-security scanning expectations are realistic across legacy package
    ecosystems and should be considered for OSERA-SP-0.2.0 after the member tooling
    survey.
  - Which v0.2.0 observe-mode checks should be promoted after the first gate.
  - Whether generated catalog artifacts should also be published as signed GitHub
    releases or OCI artifacts after ratification.
standards:
  included_standards:
  - id: STD-001
    version: 0.1.0
    role: Required check
    rationale: The standards group needs a machine-readable source format before ratifying
      a pack that acceptance gates can consume.
    url: "/standards/std-001-standards-as-code/"
    checks:
    - STD-001.CHECK-001
    - STD-001.CHECK-002
  - id: FORK-001
    version: 0.1.0
    role: Required check
    rationale: Repository naming and canonical finos-osera location remain the simplest
      v0.1.0 provenance model; new standardized repositories use patch-*.
    url: "/standards/fork-001-repository-naming/"
    checks:
    - FORK-001.CHECK-001
    - FORK-001.CHECK-002
  - id: FORK-002
    version: 0.1.0
    role: Required check
    rationale: Version-scoped patch branches are simple to create and necessary for
      multiple supported lines.
    url: "/standards/fork-002-patch-branches/"
    checks:
    - FORK-002.CHECK-001
  - id: FORK-003
    version: 0.1.0
    role: Required check
    rationale: Baseline tags are essential for source comparison and audit evidence;
      new standardized baseline tags use +patch.baseline.
    url: "/standards/fork-003-baseline-tags/"
    checks:
    - FORK-003.CHECK-001
  - id: SRC-002
    version: 0.1.0
    role: Required evidence
    rationale: Provenance links are central to reviewability and auditability.
    url: "/standards/src-002-provenance-links/"
    checks:
    - SRC-002.CHECK-001
  - id: SRC-003
    version: 0.1.0
    role: Required check
    rationale: License-header consistency can be enforced where the local convention
      is determinable, with a not-applicable result when no convention exists.
    url: "/standards/src-003-license-headers/"
    checks:
    - SRC-003.CHECK-001
  - id: REL-001
    version: 0.1.0
    role: Required evidence
    rationale: 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.
    url: "/standards/rel-001-test-provenance/"
    checks:
    - REL-001.CHECK-001
  - id: REL-002
    version: 0.1.0
    role: Required check
    rationale: Runtime compatibility is a high-impact recipient concern and can be
      measured at publication time.
    url: "/standards/rel-002-bytecode-compatibility/"
    checks:
    - REL-002.CHECK-001
  - id: REL-003
    version: 0.1.0
    role: Required check
    rationale: Official signed artifacts should use branded OSERA release metadata
      visible in package coordinates and scanner output.
    url: "/standards/rel-003-version-metadata/"
    checks:
    - REL-003.CHECK-001
    - REL-003.CHECK-002
  - id: REL-004
    version: 0.1.0
    role: Required check
    rationale: The gate needs an approved-producer allow list so official artifacts
      come from a known participant.
    url: "/standards/rel-004-approved-producers/"
    checks:
    - REL-004.CHECK-001
    - REL-004.CHECK-002
  - id: REL-005
    version: 0.1.0
    role: Required check
    rationale: Package metadata and checksum hygiene are practical for the September
      20 gate and necessary for reliable consumption.
    url: "/standards/rel-005-artifact-publication-hygiene/"
    checks:
    - REL-005.CHECK-001
    - REL-005.CHECK-002
  - id: FEED-001
    version: 0.1.0
    role: Required evidence
    rationale: Feeds are necessary for enterprise consumption, and the gate can verify
      exact purl coverage for official artifacts.
    url: "/standards/feed-001-openvex-cyclonedx/"
    checks:
    - FEED-001.CHECK-001
    - FEED-001.CHECK-002
  advisory_standards: []
  observe_standards:
  - id: FORK-004
    version: 0.0.1
    role: Observe-only check
    rationale: Public source, same-license release, and official-fork hosting are
      important to recipient trust, but exact evidence rules need v0.2.0 work.
    url: "/standards/fork-004-open-source-patch-publication/"
    checks:
    - FORK-004.CHECK-001
    - FORK-004.CHECK-002
    - FORK-004.CHECK-003
  - id: SRC-001
    version: 0.0.1
    role: Observe-only check
    rationale: Consumers need patch-basis classification, but the working group needs
      a controlled vocabulary and minimum wording before it can be enforced.
    url: "/standards/src-001-patch-basis/"
    checks:
    - SRC-001.CHECK-001
  - id: REL-006
    version: 0.0.1
    role: Observe-only check
    rationale: Patch request or backlog authorization is useful, but public/private
      sponsorship policy is not ready to enforce.
    url: "/standards/rel-006-patch-request-authorization/"
    checks:
    - REL-006.CHECK-001
  - id: REL-007
    version: 0.0.1
    role: Observe-only check
    rationale: 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.
    url: "/standards/rel-007-build-provenance-and-signed-attestation/"
    checks:
    - REL-007.CHECK-001
    - REL-007.CHECK-002
  - id: REL-008
    version: 0.0.1
    role: Observe-only check
    rationale: Build-security scanning is important, but the working group needs evidence
      about practical scanner coverage across ecosystems before making it enforceable.
    url: "/standards/rel-008-build-security-scanning/"
    checks:
    - REL-008.CHECK-001
    - REL-008.CHECK-002
  - id: EVD-001
    version: 0.0.1
    role: Observe-only check
    rationale: Recipient guidance is valuable for routing testing, but the expected
      format needs v0.2.0 refinement before it can become advisory or required.
    url: "/standards/evd-001-change-and-test-surface/"
    checks:
    - EVD-001.CHECK-001
  - id: APP-001
    version: 0.0.1
    role: Observe-only check
    rationale: Estate-wide automated application depends on downstream tooling and
      recipient operating models that are not proven enough for the first gate.
    url: "/standards/app-001-estate-application/"
    checks:
    - APP-001.CHECK-001
  deferred_standards:
  - id: FORK-004
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode for OSERA-SP-0.1.0 and expected to be reconsidered
      for OSERA-SP-0.2.0.
    url: "/standards/fork-004-open-source-patch-publication/"
    checks:
    - FORK-004.CHECK-001
    - FORK-004.CHECK-002
    - FORK-004.CHECK-003
  - id: SRC-001
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until patch-basis vocabulary and provider wording
      are defined.
    url: "/standards/src-001-patch-basis/"
    checks:
    - SRC-001.CHECK-001
  - id: REL-006
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until the backlog and private sponsorship model
      is settled.
    url: "/standards/rel-006-patch-request-authorization/"
    checks:
    - REL-006.CHECK-001
  - id: REL-007
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until producer signed build provenance is specified
      and implemented.
    url: "/standards/rel-007-build-provenance-and-signed-attestation/"
    checks:
    - REL-007.CHECK-001
    - REL-007.CHECK-002
  - id: REL-008
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until package ecosystem scanning expectations
      and evidence formats are defined.
    url: "/standards/rel-008-build-security-scanning/"
    checks:
    - REL-008.CHECK-001
    - REL-008.CHECK-002
  - id: EVD-001
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until the recipient guidance format is better
      defined.
    url: "/standards/evd-001-change-and-test-surface/"
    checks:
    - EVD-001.CHECK-001
  - id: APP-001
    version: 0.0.1
    role: Observe-only check
    rationale: Tracked in observe mode until estate-wide application workflows are
      proven.
    url: "/standards/app-001-estate-application/"
    checks:
    - APP-001.CHECK-001