This file is the single source of truth for the standards the EmbeddedOS organisation aims to satisfy across all 13 canonical product repositories. Every product README references this file via a one-line pointer rather than duplicating the list (which is how the list silently drifts out of date).

All canonical product repos tag releases as vMAJOR.MINOR.PATCH (SemVer):

v0.1.0    v0.2.0    v1.0.0    v1.0.1    v1.1.0-rc.1    v1.1.0

Pre-release candidates use -rc.N. No other suffix is recognised by the release.yml workflow or by the sync-release-branch.yml workflow.

• eosllm — also tags VS-Code-extension artifacts as vscode-vX.Y.Z and browser-extension artifacts as browser-vX.Y.Z. Core library still tags plain vX.Y.Z.
• www.embeddedos.org — marketing site versions itself separately as vX.Y.Z starting from v0.1.x. Not part of the canonical 13-product versioning and not consumed downstream.
• eApps — historical pre-2026-05 tags (≈159 tags from before the new org-uniform release model). Old tags are immutable and not deleted; new tags follow the standard.

Every repo has exactly two long-lived branches:

When a vX.Y.Z tag is pushed on master, the sync-release-branch.yml workflow force-updates release to point at the same commit. Tags are immutable; the release branch is a movable pointer.

Consumers integrating with a product can pin to:

• A specific vX.Y.Z tag (most stable; recommended for production).
• The release branch (auto-tracks latest released).
• The master branch (development; may break).

Each product targets compliance with the subset that applies to its domain. A repo's README declares which frameworks it claims to support.

• Quality / engineering process

  • ISO/IEC/IEEE 15288:2023 — systems and software engineering — life cycle processes
  • ISO/IEC 12207 — software life cycle processes
  • ISO/IEC 25000 (SQuaRE) — systems and software quality requirements and evaluation
  • Conventional Commits 1.0.0
  • Semantic Versioning 2.0.0

• Security

  • ISO/IEC 27001 — information security management
  • FIPS 140-3 — cryptographic-module security
  • OpenSSF Scorecard — automated repo-health checks
  • CodeQL — static security analysis

• Functional safety (domain-specific)

  • IEC 61508 — general-purpose functional safety
  • ISO 26262 — automotive functional safety
  • DO-178C — airborne software
  • IEC 62304 — medical device software

• Accessibility

  • WCAG 2.1 AA

• Supply chain transparency

  • SPDX SBOM format
  • CycloneDX SBOM format
  • NTIA Minimum Elements for an SBOM

• Licensing

  • All source code: MIT License unless a repo's LICENSE declares otherwise (eCAD-Hardware-Products is proprietary for the hardware schematics).
  • All documentation/books: CC BY-SA 4.0.

Repos that do not ship their own override use these by default:

• CODE_OF_CONDUCT.md — Contributor Covenant 2.1
• CONTRIBUTING.md — short org-wide guide
• SECURITY.md — disclosure policy + response SLA
• .github/ISSUE_TEMPLATE/config.yml — issue routing
• .github/PULL_REQUEST_TEMPLATE.md — PR template
• .github/dependabot-template.yml — dependabot config template
• .github/workflows/sync-release-branch.yml — release-branch auto-sync
• .github/workflows/check-canon.yml — canonical-product-list validator

A repo asserts compliance with a framework by:

1. Adding it to the Standards Compliance section of its README.md.
2. Linking to evidence (a doc page, a CI workflow that enforces it, or an audit report).
3. Running the verifying workflow on every push (where automation exists).

A claim without (2) and (3) is aspirational, not asserted, and must be labelled as such in the README so consumers are not misled.