schema-version: 0.1.0
source: docs/_standards
standards:
- schema-version: 0.1.0
  sequence: 10
  standard_id: FORK-001
  title: Repository Naming
  summary: Patched-source repositories use a consistent `patch-<reponame>` name in
    the finos-osera GitHub organization.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required check
  type: FORK
  category: Fork Management
  applies-to:
  - Patch providers
  - OSERA maintainers
  requirements:
  - id: FORK-001.REQ-001
    level: MUST
    text: Patched-source repositories must live in github.com/finos-osera unless the
      working group approves an exception.
    checkability: automated
    checks:
    - id: FORK-001.CHECK-001
      title: Repository is in the finos-osera organization
      type: repository
      severity: blocking
      implementation: osera-fitness.fork001.repository_owner
      evidence:
      - repository_url
  - id: FORK-001.REQ-002
    level: MUST
    text: Patched-source repositories must use the prefix patch- followed by the upstream
      repository or artifact name.
    checkability: automated
    checks:
    - id: FORK-001.CHECK-002
      title: Repository name uses the patch prefix
      type: repository
      severity: blocking
      implementation: osera-fitness.fork001.repository_name
      evidence:
      - repository_name
  source_path: docs/_standards/fork-001-repository-naming.md
  url: "/standards/fork-001-repository-naming/"
- schema-version: 0.1.0
  sequence: 20
  standard_id: FORK-002
  title: Patch Branches
  summary: Patch providers use `patch/<version>` source workflow branches for every
    supported major or minor line.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required check
  type: FORK
  category: Fork Management
  applies-to:
  - Patch providers
  - OSERA maintainers
  requirements:
  - id: FORK-002.REQ-001
    level: MUST
    text: Patch providers must create version-scoped source workflow branches using
      patch/<version>.
    checkability: automated
    checks:
    - id: FORK-002.CHECK-001
      title: Supported line has a patch version branch
      type: repository
      severity: blocking
      implementation: osera-fitness.fork002.patch_branch
      evidence:
      - branch_name
  source_path: docs/_standards/fork-002-patch-branches.md
  url: "/standards/fork-002-patch-branches/"
- schema-version: 0.1.0
  sequence: 30
  standard_id: FORK-003
  title: Baseline Tags
  summary: Every patch line identifies its unpatched starting source SHA with a `v<VERSION>+patch.baseline`
    tag.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required check
  type: FORK
  category: Fork Management
  applies-to:
  - Patch providers
  - Enterprise recipients
  requirements:
  - id: FORK-003.REQ-001
    level: MUST
    text: Patch providers must tag the unpatched baseline source commit using v<VERSION>+patch.baseline.
    checkability: automated
    checks:
    - id: FORK-003.CHECK-001
      title: Baseline tag exists and resolves to a commit
      type: repository
      severity: blocking
      implementation: osera-fitness.fork003.baseline_tag
      evidence:
      - baseline_tag
      - baseline_commit
  source_path: docs/_standards/fork-003-baseline-tags.md
  url: "/standards/fork-003-baseline-tags/"
- schema-version: 0.1.0
  sequence: 40
  standard_id: FORK-004
  title: Open Source Patch Publication
  summary: Patched-source repositories should be fully public, hosted in the appropriate
    official fork, and released under the same open-source license terms as the original
    code.
  doc-status: Pre-Draft
  standard-version: 0.0.1
  candidate-pack: OSERA-SP-0.2.0 observe
  ratified-in: Not ratified
  ratified-date: Not ratified
  fitness-role: Observe-only check
  type: FORK
  category: Fork Management
  applies-to:
  - Patch providers
  - OSERA maintainers
  - Enterprise recipients
  requirements:
  - id: FORK-004.REQ-001
    level: MUST
    text: Patched-source repositories must be fully public and publicly fetchable
      without private credentials.
    checkability: automated
    checks:
    - id: FORK-004.CHECK-001
      title: Repository is publicly fetchable
      type: repository
      severity: observe
      implementation: osera-fitness.fork004.public_fetch
      evidence:
      - repository_url
      - fetch_result
  - id: FORK-004.REQ-002
    level: MUST
    text: Patched-source repositories must preserve applicable upstream open-source
      license files and notices and release patched source under the same applicable
      license terms as the original source line.
    checkability: partially-automated
    checks:
    - id: FORK-004.CHECK-002
      title: Upstream license terms, files, and notices are preserved
      type: repository
      severity: observe
      implementation: osera-fitness.fork004.license_files
      evidence:
      - license_files
      - upstream_license_files
  - id: FORK-004.REQ-003
    level: MUST
    text: Patched-source repositories must be hosted in the appropriate official OSERA
      fork for the upstream project or artifact line.
    checkability: partially-automated
    checks:
    - id: FORK-004.CHECK-003
      title: Repository is the appropriate official OSERA fork
      type: repository
      severity: observe
      implementation: osera-fitness.fork004.official_fork
      evidence:
      - repository_url
      - upstream_repository_url
      - fork_relationship
  source_path: docs/_standards/fork-004-open-source-patch-publication.md
  url: "/standards/fork-004-open-source-patch-publication/"
- schema-version: 0.1.0
  sequence: 110
  standard_id: SRC-001
  title: Patch Basis Classification
  summary: Providers distinguish upstream backports from provider-developed fixes
    for each CVE or fix item carried by a patch release.
  doc-status: Pre-Draft
  standard-version: 0.0.1
  candidate-pack: OSERA-SP-0.2.0 observe
  ratified-in: Not ratified
  ratified-date: Not ratified
  fitness-role: Observe-only check
  type: SRC
  category: Source Changes
  applies-to:
  - Patch providers
  - Enterprise recipients
  - Feed maintainers
  requirements:
  - id: SRC-001.REQ-001
    level: SHOULD
    text: Patch providers should classify whether each CVE or fix item in a patch
      release is based on an upstream fix, an adapted upstream fix, or a provider-developed
      fix, using a vocabulary still to be defined by the working group.
    checkability: manual
    checks:
    - id: SRC-001.CHECK-001
      title: Patch basis classification is present
      type: release-evidence
      severity: observe
      implementation: osera-fitness.src001.patch_basis
      evidence:
      - fix_item
      - cve_id
      - patch_basis_by_fix
      - upstream_fix_reference
  source_path: docs/_standards/src-001-patch-basis.md
  url: "/standards/src-001-patch-basis/"
- schema-version: 0.1.0
  sequence: 120
  standard_id: SRC-002
  title: Upstream Provenance Links
  summary: Backports link to the upstream commit or advisory that introduced the fix
    being carried back.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required evidence
  type: SRC
  category: Source Changes
  applies-to:
  - Patch providers
  - Enterprise recipients
  requirements:
  - id: SRC-002.REQ-001
    level: MUST
    text: Backport evidence must link to the upstream commit, commit range, pull request,
      advisory, or release note defining the fix.
    checkability: partially-automated
    checks:
    - id: SRC-002.CHECK-001
      title: Upstream provenance link is present
      type: release-evidence
      severity: blocking
      implementation: osera-fitness.src002.upstream_provenance_link
      evidence:
      - upstream_fix_url
      - patch_commit_url
  - id: SRC-002.REQ-002
    level: SHOULD
    text: Backported commits carrying upstream-authored code should name the upstream
      commit and include a Co-authored-by trailer for the upstream author where applicable.
    checkability: manual
    checks:
    - id: SRC-002.CHECK-002
      title: Upstream authorship trailer is present where applicable
      type: source
      severity: advisory
      implementation: osera-fitness.src002.co_authored_by_trailer
      evidence:
      - upstream_commit_author
      - co_authored_by_trailer
      - not_applicable_rationale
  source_path: docs/_standards/src-002-provenance-links.md
  url: "/standards/src-002-provenance-links/"
- schema-version: 0.1.0
  sequence: 130
  standard_id: SRC-003
  title: License Headers for New Files
  summary: New source or test files match the prevailing license format of the surrounding
    project.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required check
  type: SRC
  category: Source Changes
  applies-to:
  - Patch providers
  requirements:
  - id: SRC-003.REQ-001
    level: MUST
    text: New source or test files added by a patch must follow the prevailing license-header
      convention of the surrounding project.
    checkability: partially-automated
    checks:
    - id: SRC-003.CHECK-001
      title: New files use the local license-header convention
      type: source
      severity: blocking
      implementation: osera-fitness.src003.license_headers
      evidence:
      - new_files
      - nearest_same_type_file
      - license_header_check
      - not_applicable_rationale
  source_path: docs/_standards/src-003-license-headers.md
  url: "/standards/src-003-license-headers/"
- schema-version: 0.1.0
  sequence: 210
  standard_id: REL-001
  title: Provider Test Provenance
  summary: Test execution methods are provider-dependent, but the provider publishes
    a unit-test report artifact for recipients to understand release validation.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required evidence
  type: REL
  category: Release Process
  applies-to:
  - Patch providers
  - Enterprise recipients
  requirements:
  - id: REL-001.REQ-001
    level: MUST
    text: Patch providers must publish test provenance for the patched artifact, including
      the tested commit, test command or suite, runtime when relevant, test report,
      and passing test result.
    checkability: automated
    checks:
    - id: REL-001.CHECK-001
      title: Test provenance is recorded
      type: release-evidence
      severity: blocking
      implementation: osera-fitness.rel001.test_provenance
      evidence:
      - tested_commit
      - runtime
      - test_command
      - test_result
      - test_report_artifact
      - no_failed_tests
  source_path: docs/_standards/rel-001-test-provenance.md
  url: "/standards/rel-001-test-provenance/"
- schema-version: 0.1.0
  sequence: 220
  standard_id: REL-002
  title: Bytecode Compatibility
  summary: Patched artifacts preserve the bytecode level of the last released artifact
    unless an explicit exception is approved.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required evidence
  type: REL
  category: Release Process
  applies-to:
  - Patch providers
  - Enterprise recipients
  requirements:
  - id: REL-002.REQ-001
    level: MUST
    text: Patched Java artifacts must preserve the bytecode level of the last released
      artifact unless an exception is approved.
    checkability: automated
    checks:
    - id: REL-002.CHECK-001
      title: Bytecode level matches the prior released artifact
      type: artifact
      severity: blocking
      implementation: osera-fitness.rel002.bytecode_level
      evidence:
      - artifact_digest
      - bytecode_level
      - reference_artifact
  source_path: docs/_standards/rel-002-bytecode-compatibility.md
  url: "/standards/rel-002-bytecode-compatibility/"
- schema-version: 0.1.0
  sequence: 230
  standard_id: REL-003
  title: Patch Version Naming
  summary: Patched releases use package-ecosystem-appropriate version naming profiles
    that optimize recipient tooling outcomes before choosing a concrete syntax.
  extended-by:
  - REL-003-JAVA
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required check
  type: REL
  category: Release Process
  applies-to:
  - Package patch providers
  - Enterprise recipients
  - Package ecosystem profile authors
  requirements:
  - id: REL-003.REQ-001
    level: MUST
    text: Official OSERA patched releases must use the applicable package-ecosystem
      patch version naming profile, or the default SemVer 2.0-compatible OSERA form
      where no concrete profile exists, so supported package resolver, dependency
      update, repository manager, SCA, feed, and policy tooling can identify the patched
      artifact as the latest applicable remediation on the same upstream version line.
    checkability: partially-automated
    checks:
    - id: REL-003.CHECK-001
      title: Applicable patch version naming profile is selected
      type: release
      severity: blocking
      implementation: osera-fitness.rel003.remediation_identifier
      evidence:
      - release_tag
      - artifact_version
      - applicable_profile
      - ecosystem_profile
      - resolver_test_result
  - id: REL-003.REQ-002
    level: MUST
    text: Release tags, artifact versions, vulnerability feeds, and release evidence
      must carry the same patched-release identifier.
    checkability: automated
    checks:
    - id: REL-003.CHECK-002
      title: Release identifier is consistent across source, artifact, and feeds
      type: release
      severity: blocking
      implementation: osera-fitness.rel003.identifier_consistency
      evidence:
      - release_tag
      - artifact_version
      - feed_purl
  source_path: docs/_standards/rel-003-version-metadata.md
  url: "/standards/rel-003-version-metadata/"
- schema-version: 0.1.0
  sequence: 231
  standard_id: REL-003-JAVA
  title: Java Patch Version Naming
  summary: Java patched releases use a version naming profile that optimizes Maven,
    Gradle, repository-manager, dependency-update, SCA, feed, and policy-tool behavior
    for the affected upstream version line.
  extends: REL-003
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required Java profile check
  type: REL
  category: Release Process
  applies-to:
  - Java package patch providers
  - Enterprise Java recipients
  - Java repository and dependency tooling
  requirements:
  - id: REL-003-JAVA.REQ-001
    override-explanation: Specializes the generic applicable-profile rule with a Java-specific
      version convention. The CARE-style convention uses the OSERA identifier; the
      parent obligations to identify the latest applicable remediation on the same
      upstream line and preserve baseline and OSERA identity remain.
    level: MUST
    text: Official OSERA Java patched releases must use the ratified Java patch CARE-style
      version naming convention with the OSERA identifier, so supported Java resolver,
      dependency update, repository manager, SCA, feed, and policy tooling treats
      the patched artifact as the latest applicable remediation on the same upstream
      version line.
    checkability: partially-automated
    checks:
    - id: REL-003-JAVA.CHECK-001
      override-explanation: Replaces generic profile-selection evidence with Java
        profile-decision, resolver, and dependency-update compatibility evidence.
        The parent consumer outcome remains the acceptance criterion; the naming convention
        is the CARE-style OSERA form described below.
      title: Java patch version pattern passes supported tooling compatibility tests
      type: release
      severity: blocking
      implementation: osera-fitness.rel003_java.version_pattern_compatibility
      evidence:
      - release_tag
      - artifact_version
      - java_profile_decision
      - resolver_test_result
      - dependency_update_test_result
  - id: REL-003-JAVA.REQ-002
    override-explanation: Specializes the parent identifier-consistency obligation
      for Java artifacts by explicitly including Maven package URLs. The same patched-release
      identity must still connect source tags, artifacts, feeds, and evidence.
    level: MUST
    text: Java release tags, artifact versions, Maven package URLs, vulnerability
      feeds, and release evidence must carry the same Java patch version identifier.
    checkability: automated
    checks:
    - id: REL-003-JAVA.CHECK-002
      override-explanation: Uses Maven package URL evidence for the parent consistency
        check while retaining release-tag, artifact-version, and feed identity matching.
      title: Java release identifier is consistent across source, artifact, and feeds
      type: release
      severity: blocking
      implementation: osera-fitness.rel003_java.identifier_consistency
      evidence:
      - release_tag
      - artifact_version
      - maven_purl
      - feed_purl
  source_path: docs/_standards/rel-003-java-patch-version-naming.md
  url: "/standards/rel-003-java-patch-version-naming/"
  parent_relationship:
    parent_standard: REL-003
    parent_version: 0.1.0
    requirements:
    - parent_item: REL-003.REQ-001
      treatment: Overrides
      effective_item: REL-003-JAVA.REQ-001
      explanation: Specializes the generic applicable-profile rule with a Java-specific
        version convention. The CARE-style convention uses the OSERA identifier; the
        parent obligations to identify the latest applicable remediation on the same
        upstream line and preserve baseline and OSERA identity remain.
    - parent_item: REL-003.REQ-002
      treatment: Overrides
      effective_item: REL-003-JAVA.REQ-002
      explanation: Specializes the parent identifier-consistency obligation for Java
        artifacts by explicitly including Maven package URLs. The same patched-release
        identity must still connect source tags, artifacts, feeds, and evidence.
    checks:
    - parent_item: REL-003.CHECK-001
      treatment: Overrides
      effective_item: REL-003-JAVA.CHECK-001
      explanation: Replaces generic profile-selection evidence with Java profile-decision,
        resolver, and dependency-update compatibility evidence. The parent consumer
        outcome remains the acceptance criterion; the naming convention is the CARE-style
        OSERA form described below.
    - parent_item: REL-003.CHECK-002
      treatment: Overrides
      effective_item: REL-003-JAVA.CHECK-002
      explanation: Uses Maven package URL evidence for the parent consistency check
        while retaining release-tag, artifact-version, and feed identity matching.
- schema-version: 0.1.0
  sequence: 240
  standard_id: REL-004
  title: Approved Producers
  summary: Official OSERA signed artifacts are produced only by producers approved
    for the targeted standards pack.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required check
  type: REL
  category: Release Process
  applies-to:
  - OSERA maintainers
  - Patch providers
  - Repository operators
  requirements:
  - id: REL-004.REQ-001
    level: MUST
    text: Official OSERA signed artifacts must identify a producer that appears in
      the approved-producer registry for the targeted standards pack. Each producer
      record must contain id, contact, github_users, and staging_account, with a unique
      id matching the producer identity in release evidence and fitness results.
    checkability: automated
    checks:
    - id: REL-004.CHECK-001
      title: Producer is approved for the targeted standards pack
      type: publication-gate
      severity: blocking
      implementation: osera-fitness.rel004.approved_producer
      evidence:
      - producer_identity
      - approved_producer_registry
  - id: REL-004.REQ-002
    level: MUST
    text: The producer identity used at publication time must be recorded in the fitness
      result and release evidence, as an exact-string match of the registry entry's
      id. The fitness result and the verdict must also record the registry entry's
      staging_account and github_users as copied from the registry, and separately
      the observed release-tag actor. The observed upload account may be null in the
      CI fitness result because the gate observes it at upload time; this null value
      does not fail the CI check. The gate must record the observed upload account
      in the verdict. In 0.1.0 a difference between the copied account metadata and
      the observed actors is recorded and does not block.
    checkability: partially-automated
    checks:
    - id: REL-004.CHECK-002
      title: Producer identity is recorded in release evidence
      type: release-evidence
      severity: blocking
      implementation: osera-fitness.rel004.producer_identity_evidence
      evidence:
      - producer_identity
      - fitness_result
      - release_evidence
      - registry_account_metadata
      - observed_tag_actor
      - observed_upload_account
  source_path: docs/_standards/rel-004-approved-producers.md
  url: "/standards/rel-004-approved-producers/"
- schema-version: 0.1.0
  sequence: 250
  standard_id: REL-005
  title: Artifact Publication Hygiene
  summary: Published OSERA artifacts include consistent package metadata, checksums,
    and repository evidence required by the publication gate.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required check
  type: REL
  category: Release Process
  applies-to:
  - Patch providers
  - Repository operators
  - Enterprise recipients
  requirements:
  - id: REL-005.REQ-001
    level: MUST
    text: Official OSERA artifacts must publish expected package files and checksums
      for the ecosystem being released.
    checkability: automated
    checks:
    - id: REL-005.CHECK-001
      title: Package files and checksums are present
      type: artifact
      severity: blocking
      implementation: osera-fitness.rel005.package_checksum_hygiene
      evidence:
      - artifact_files
      - checksums
  - id: REL-005.REQ-002
    level: MUST
    text: Published package metadata must identify the patched version consistently
      with REL-003.
    checkability: automated
    checks:
    - id: REL-005.CHECK-002
      title: Package metadata uses the approved patched version
      type: artifact
      severity: blocking
      implementation: osera-fitness.rel005.package_metadata_version
      evidence:
      - pom
      - artifact_version
      - release_tag
  source_path: docs/_standards/rel-005-artifact-publication-hygiene.md
  url: "/standards/rel-005-artifact-publication-hygiene/"
- schema-version: 0.1.0
  sequence: 260
  standard_id: REL-006
  title: Patch Request Authorization
  summary: Patch releases should trace to an approved backlog item, request, sponsor
    record, or equivalent authorization record.
  doc-status: Pre-Draft
  standard-version: 0.0.1
  candidate-pack: OSERA-SP-0.2.0 observe
  ratified-in: Not ratified
  ratified-date: Not ratified
  fitness-role: Observe-only check
  type: REL
  category: Release Process
  applies-to:
  - OSERA maintainers
  - Patch providers
  - Repository operators
  requirements:
  - id: REL-006.REQ-001
    level: SHOULD
    text: Patch releases should identify the backlog item, public request, sponsor
      record, or equivalent authorization record for the patched coordinate and line.
    checkability: manual
    checks:
    - id: REL-006.CHECK-001
      title: Patch request authorization evidence is present
      type: release-evidence
      severity: observe
      implementation: osera-fitness.rel006.patch_request_authorization
      evidence:
      - backlog_item
      - sponsor_record
      - coordinate_line
  source_path: docs/_standards/rel-006-patch-request-authorization.md
  url: "/standards/rel-006-patch-request-authorization/"
- schema-version: 0.1.0
  sequence: 270
  standard_id: REL-007
  title: Build Provenance and Signed Attestation
  summary: Producers should sign an attestation linking the published artifact digest
    to the source tag, build process, SBOM, VEX, test evidence, and license audit.
  doc-status: Pre-Draft
  standard-version: 0.0.1
  candidate-pack: OSERA-SP-0.2.0 observe
  ratified-in: Not ratified
  ratified-date: Not ratified
  fitness-role: Observe-only check
  type: REL
  category: Release Process
  applies-to:
  - Patch providers
  - Repository operators
  - Enterprise recipients
  requirements:
  - id: REL-007.REQ-001
    level: SHOULD
    text: Producers should sign an attestation linking the artifact digest to the
      source tag and build provenance.
    checkability: partially-automated
    checks:
    - id: REL-007.CHECK-001
      title: Signed build provenance attestation is present
      type: release-evidence
      severity: observe
      implementation: osera-fitness.rel007.signed_build_attestation
      evidence:
      - artifact_digest
      - source_tag
      - attestation_signature
  - id: REL-007.REQ-002
    level: SHOULD
    text: The attestation should reference SBOM, VEX, test evidence, and license audit
      material for the release.
    checkability: manual
    checks:
    - id: REL-007.CHECK-002
      title: Attestation references release evidence bundle
      type: release-evidence
      severity: observe
      implementation: osera-fitness.rel007.evidence_bundle_references
      evidence:
      - sbom
      - vex
      - test_evidence
      - license_audit
  source_path: docs/_standards/rel-007-build-provenance-and-signed-attestation.md
  url: "/standards/rel-007-build-provenance-and-signed-attestation/"
- schema-version: 0.1.0
  sequence: 280
  standard_id: REL-008
  title: Build Security Scanning
  summary: Patch release builds should be checked for build-tool, dependency, and
    pipeline-injection risks before publication.
  doc-status: Pre-Draft
  standard-version: 0.0.1
  candidate-pack: OSERA-SP-0.2.0 observe
  ratified-in: Not ratified
  ratified-date: Not ratified
  fitness-role: Observe-only check
  type: REL
  category: Release Process
  applies-to:
  - Patch providers
  - Repository operators
  - Enterprise recipients
  requirements:
  - id: REL-008.REQ-001
    level: SHOULD
    text: Patch providers should run build-security scanning appropriate to the package
      ecosystem before publishing an official patched artifact.
    checkability: partially-automated
    checks:
    - id: REL-008.CHECK-001
      title: Build-security scan evidence is present
      type: release-evidence
      severity: observe
      implementation: osera-fitness.rel008.build_security_scan
      evidence:
      - build_security_scan_tool
      - scan_scope
      - scan_result
  - id: REL-008.REQ-002
    level: SHOULD
    text: Build-security evidence should identify unresolved high-risk findings or
      explain why the selected tooling is not applicable to the patched project.
    checkability: manual
    checks:
    - id: REL-008.CHECK-002
      title: Build-security findings are dispositioned
      type: release-evidence
      severity: observe
      implementation: osera-fitness.rel008.finding_disposition
      evidence:
      - unresolved_findings
      - finding_disposition
      - not_applicable_rationale
  source_path: docs/_standards/rel-008-build-security-scanning.md
  url: "/standards/rel-008-build-security-scanning/"
- schema-version: 0.1.0
  sequence: 310
  standard_id: FEED-001
  title: OpenVEX and CycloneDX Feeds
  summary: OSERA-compatible providers contribute patch data to both OpenVEX and CycloneDX
    feed formats.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required evidence
  type: FEED
  category: Feeds and Advisories
  applies-to:
  - Patch providers
  - Feed maintainers
  - Enterprise recipients
  requirements:
  - id: FEED-001.REQ-001
    level: MUST
    text: OSERA-compatible releases must be represented in OpenVEX and CycloneDX feed
      data.
    checkability: partially-automated
    checks:
    - id: FEED-001.CHECK-001
      title: OpenVEX and CycloneDX entries exist for the release
      type: feed
      severity: blocking
      implementation: osera-fitness.feed001.feed_entry_presence
      evidence:
      - openvex_entry
      - cyclonedx_entry
  - id: FEED-001.REQ-002
    level: MUST
    text: Feed entries must preserve the exact patched package URL, including encoded
      release metadata.
    checkability: automated
    checks:
    - id: FEED-001.CHECK-002
      title: Feed purls match the published patched artifact identifier
      type: feed
      severity: blocking
      implementation: osera-fitness.feed001.exact_purl_match
      evidence:
      - purl
      - release_version
  source_path: docs/_standards/feed-001-openvex-cyclonedx.md
  url: "/standards/feed-001-openvex-cyclonedx/"
- schema-version: 0.1.0
  sequence: 410
  standard_id: EVD-001
  title: Change and Test Surface Guidance
  summary: Providers publish concise recipient guidance describing what changed and
    what surface area should be tested.
  doc-status: Pre-Draft
  standard-version: 0.0.1
  candidate-pack: OSERA-SP-0.2.0 observe
  ratified-in: Not ratified
  ratified-date: Not ratified
  fitness-role: Observe-only check
  type: EVD
  category: Recipient Evidence
  applies-to:
  - Patch providers
  - Enterprise recipients
  - Tooling providers
  requirements:
  - id: EVD-001.REQ-001
    level: SHOULD
    text: Patch providers should publish versioned recipient guidance describing what
      changed and what surface area should be tested.
    checkability: manual
    checks:
    - id: EVD-001.CHECK-001
      title: Recipient guidance uses the current guidance schema
      type: release-evidence
      severity: observe
      implementation: osera-fitness.evd001.recipient_guidance_schema
      evidence:
      - recipient_guidance
      - schema_version
  source_path: docs/_standards/evd-001-change-and-test-surface.md
  url: "/standards/evd-001-change-and-test-surface/"
- schema-version: 0.1.0
  sequence: 510
  standard_id: APP-001
  title: Estate-Wide Patch Application
  summary: Patch feeds should support automated discovery and application across dependency
    estates.
  doc-status: Pre-Draft
  standard-version: 0.0.1
  candidate-pack: OSERA-SP-0.2.0 observe
  ratified-in: Not ratified
  ratified-date: Not ratified
  fitness-role: Observe-only check
  type: APP
  category: Patch Application
  applies-to:
  - Enterprise recipients
  - Tooling providers
  - Patch providers
  requirements:
  - id: APP-001.REQ-001
    level: SHOULD
    text: Patch feeds and metadata should support estate-wide discovery and application
      across dependency estates.
    checkability: partially-automated
    checks:
    - id: APP-001.CHECK-001
      title: Estate-wide discovery metadata is present
      type: feed-metadata
      severity: observe
      implementation: osera-fitness.app001.estate_discovery_metadata
      evidence:
      - feed_entries
      - dependency_coordinates
  source_path: docs/_standards/app-001-estate-application.md
  url: "/standards/app-001-estate-application/"
- schema-version: 0.1.0
  sequence: 610
  standard_id: STD-001
  title: Standards-as-Code Source Metadata
  summary: OSERA standards use human-authored Markdown with structured YAML front
    matter as the machine-readable source of truth.
  doc-status: Ratified
  standard-version: 0.1.0
  candidate-pack: OSERA-SP-0.1.0 ratified
  ratified-in: OSERA-SP-0.1.0
  ratified-date: '2026-09-10'
  fitness-role: Required check
  type: STD
  category: Standards Governance
  applies-to:
  - OSERA maintainers
  - Tooling providers
  requirements:
  - id: STD-001.REQ-001
    level: MUST
    text: Standard pages must include schema-versioned YAML front matter containing
      identifiers, lifecycle status, requirements, checks, evidence expectations,
      and pack references.
    checkability: automated
    checks:
    - id: STD-001.CHECK-001
      title: Standard front matter validates against the active OSERA schema
      type: standards-repository
      severity: blocking
      implementation: osera-fitness.std001.standard_frontmatter_schema
      evidence:
      - standard_markdown
      - schema-version
  - id: STD-001.REQ-002
    level: MUST
    text: The standards repository must publish normalized catalog artifacts generated
      from the Markdown front matter.
    checkability: automated
    checks:
    - id: STD-001.CHECK-002
      title: Generated catalog artifacts are current
      type: standards-repository
      severity: blocking
      implementation: osera-fitness.std001.generated_catalog_current
      evidence:
      - docs/catalog/osera-standards.yaml
      - docs/catalog/osera-standards.json
  source_path: docs/_standards/std-001-standards-as-code.md
  url: "/standards/std-001-standards-as-code/"