Alignment is not certification
This document describes how Orbit's data model and workflows map to ISO 9001:2015 quality management terminology and structure. It is not a certification claim. Certification is a status held by an organisation, following an accredited third-party audit against a specific scope, not by software. RME Solutions does not represent, in this document or elsewhere, that it holds an ISO 9001 certificate, and this document should not be read or quoted as evidence that it does. If your organisation needs Orbit's deploying organisation to hold ISO 9001 certification as a supplier-assurance condition, ask directly — that is a fact about RME Solutions, not about this software, and this document cannot answer it for you.
Current edition — verified 2026-08-13
ISO 9001:2015 (with Amendment 1:2024, which integrated climate-change context into the "context of the organization" clause) remains the current certifiable edition. A full revision is in progress: the Draft International Standard (DIS) was published August 2025, the Final DIS is expected to be balloted around April 2026, and publication is expected in the fall of 2026 (September–November), with an approximately three-year transition period to around September 2029. As of this writing, no organisation can meaningfully claim alignment with the unpublished 2026 revision — this document deliberately says "2015" throughout and will be revisited once the new edition actually publishes, not before.
What Orbit genuinely supports
ISO 9001 is a standard for an organisation's quality management system — its terminology and structure are a useful index for how well a piece of software supports a client's own QMS, not a checklist the software itself passes or fails. Read every row below as "Orbit provides infrastructure a client can build a QMS practice on," not "Orbit implements this ISO clause."
| ISO 9001:2015 concept | What Orbit provides today | Where |
|---|---|---|
| Documented information (clause 7.5) | Every SharePoint list Orbit provisions has enableVersioning: true — every ticket, catalogue entry, and approval record carries a native edit history, not just a current-state snapshot. Declarative service-catalogue and form definitions (instances/<id>/catalogue.json, instances/<id>/forms/) are themselves documented, validated, versionable process descriptions, not tribal knowledge. | src/core/schema/orbit.schema.json (enableVersioning), docs/catalogue-authoring.md, docs/forms-authoring.md |
| Process approach / control of production and service provision (clause 8.5) | The service catalogue turns "how do we fulfil this request" into a structured, repeatable, typed form + approval-routing definition rather than an ad hoc email thread — the same request type produces the same required fields and the same approval path every time. | src/core/pack/schema.ts, instances/<id>/catalogue.json |
| Risk-based thinking (clause 6.1) | Impact, Urgency, and RiskLevel fields exist on tickets and change records, letting a client capture risk context per record. | src/core/schema/orbit.schema.json (tickets.Impact/Urgency/RiskLevel) |
| Nonconformity and corrective action (clause 10.2) | Problem-type tickets carry RootCause, Workaround, and WorkaroundAvailable fields — a structured place to record why something went wrong and what was done about it, linked to the originating record via ticket relationships. | src/core/schema/orbit.schema.json (tickets.RootCause/Workaround), src/core/domain/vocabulary.ts |
| Management review inputs (clause 9.3) | Activity/audit views and portal-usage telemetry give a client organisation raw material for a management review — request volumes, approval turnaround, ticket ageing — without Orbit prescribing what "good" looks like for that client. | src/modules/admin/tabs/ActivityAuditTab.tsx, src/services/telemetryService.ts |
| Continual improvement (clause 10.3) | Two distinct things: (a) RME's own development process runs typecheck/lint/tests/pack-validation/leak gates on every change (package.json, .github/workflows/quality.yml) as evidence of a controlled release process for the product itself; (b) once HyperKB ships (this plan), a client's own known-error and article-feedback loop becomes a real continual-improvement input, not just a developer-side one. | .github/workflows/quality.yml, docs/kb-plan/00-OVERVIEW.md |
Known gaps and dispositions
| Gap | Disposition |
|---|---|
| No customer-satisfaction measurement (clause 9.1.2) anywhere in the product. | Client-owned. This is an organisational process (surveys, feedback channels), not a data-model gap — Orbit does not add a satisfaction-survey field speculatively; a client with a real requirement here should raise it as a product decision on its own evidence, per this repository's existing "standards mapping alone is not schema justification" rule. |
Impact/Urgency exist but are not consistently collected or used to derive Priority. | Documented, deferred. Already named as a gap in docs/whitelabel-plan/02-ISO27001-ITIL-ALIGNMENT.md's data-model notes; carries over unchanged here rather than being re-litigated as a separate ISO 9001 finding. |
| No formal internal-audit or management-review record type — Orbit surfaces the raw inputs (above) but does not structure a management-review minutes/output record. | Deferred, real requirement needed first. A ManagementReview list would be new schema; per this repository's ethos, that is only justified once a client actually needs it structured rather than kept in whatever document system they already use for governance records. |
No supplier/vendor quality-evaluation workflow (clause 8.4) beyond the free-text Vendors field in a client's org vocabulary. | Client-owned. Supplier evaluation is an organisational process; Orbit's asset/procurement records can be evidence a client attaches to their own supplier file, not a replacement for one. |
See also
docs/whitelabel-plan/02-ISO27001-ITIL-ALIGNMENT.md— the detailed ISO/IEC 27001 and ITIL 4 control/gap register this document deliberately does not duplicate; ISO 9001 was not previously in scope of that register, so this document is net-new ground rather than a condensed version of existing material.docs/standards/itil-4-alignment.md— where ISO 9001's process-control language and ITIL 4's service-management practices overlap (change enablement, continual improvement), read that document for the operational detail this one deliberately keeps at the quality-management level.docs/kb-plan/01-TERMINOLOGY-ALIGNMENT-REGISTER.mdrow 8 — the precision rule this document follows for the ":2015" edition qualifier.