governance — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited governance (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill covers the change process, release management, and lifecycle governance for openEHR specifications. It is based on the official governance documents at specifications.openehr.org/governance.
Every specification follows a formal lifecycle:
Planning → Development → Trial → Stable
↓
Paused → Retired| State | Duration | Format | Versioning | Change Management |
|---|---|---|---|---|
| Planning | 6 months max | Wiki | 0.y.z | Informal |
| Development | 18 months max | Wiki | 0.y.z | Optional CRs |
| Trial | 2 years max | HTML + computable | x.y.z | Formal CRs |
| Stable | Unbounded | HTML + computable | x.y.z | Formal CRs |
| Paused | Unbounded | HTML + computable | paused | CRs only for state changes |
| Retired | Unbounded | Frozen version | n/a | None |
The Specifications Editorial Committee (SEC) reviews promotion criteria three months before target dates. Unmet criteria may trigger a single three-month extension; subsequent failure results in retirement.
The spec_status field in manifest.json and manifest_vars.adoc tracks this state.
openEHR uses three-part semantic versioning (x.y.z):
Documentation-only corrections (typos, clarifications) receive a revision number update without triggering a new release number.
SPECPR Jira tracker{spec_tickets}/SPECPR-NNN[SPECPR-NNN^]SPECRM, SPECAM){spec_tickets}/SPECRM-NNN[SPECRM-NNN^]A CR requires: title, description, problem statement or PR references, affected component(s).
The SEC determines if the CR addresses real needs. Accepted CRs receive:
Minor changes (single-document, no semantic impact):
Major changes (cross-cutting or semantic):
Minor changes:
Major changes:
From Release 1.0 onward, specification changes (excluding documentation-only text updates) must be announced on the Discourse specifications forum, and require implementation in at least one formal software, schema, or technical expression before adoption.
Releases organize changes by component. The SEC defines release identifiers and delivery dates, allocating CRs to releases.
Release-N.N.N (e.g., Release-1.0.4)Release-N.N.NvN (e.g., Release-1.0.4v1) — for post-release correctionsRead references/release-checklist.md for the full step-by-step checklist.
The high-level process:
spec_status for each spec, ensure Jira links are correct.Release-N.N.N), publish with -l Release-N.N.N, commit, tag (annotated), push.Release-N.N.NvN+1masterNew specifications are proposed via PR or CR. The SEC verifies:
id field)All specifications must include:
| Role | Responsibility |
|---|---|
| SEC (Specifications Editorial Committee) | Reviews all changes, accepts/rejects CRs, manages release allocation, promotes specs |
| Component Maintainer | Supervises component specs, assigns Change Owners, approves minor changes |
| Change Owner | Develops impact assessments, executes work, revises based on feedback |
| Community | Raises PRs, participates in open reviews on Discourse |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.