Compliance frameworks

The five frameworks

SOSX produces its own governance evidence as it runs, rather than writing it up afterwards: the audit log, the catalogued sources, the record of every approval gate and the separation of judgement from proof are produced by the platform as it runs. Framework by framework, here is what each one asks for and what SOSX produces for it:

ISO 42001

The AI management-system standard asks an organisation to show how its use of AI is governed: policies, roles, oversight, records. SOSX produces evidence for that governance from the working system itself: every AI interaction is audit-logged, and the stages that decide the model pass a human approval gate.

ISO 27001

The information-security management standard asks for demonstrable control over information assets and the processes around them. SOSX's contribution is documentation generated from a live system model rather than assembled by hand: an accurate, connected picture of the estate that stays current with the systems it describes.

The EU AI Act

The deadline is fixed, and the plain question a Head of AI Governance asks is the one we build for: "which of our AI-containing systems does it touch, and what can I hand the auditor?" SOSX's answer is a model that carries its own evidence: every claim cites a catalogued source, and the documentation follows from the model instead of being assembled beside it.

NIST AI RMF

The AI Risk Management Framework asks for a mapped, measured and managed picture of AI risk. SOSX maps systems and their interactions as one typed, parameterised model (the accurate, connected picture of the estate that risk management needs), and produces evidence that aligns with the framework from that model.

OWASP agentic top-10

For agentic AI specifically, SOSX produces evidence that aligns with the OWASP agentic top-10, grounded in the same substrate: logged interactions, catalogued sources, human approval gates.

The newest standard is about innovation itself

There is a sixth standards story, and it is newer than the other five. In September 2024 ISO published ISO 56001:2024: the first certifiable international standard for innovation management systems, in the same harmonised family as ISO 9001 for quality. Among the principles it carries is, in so many words, a systems approach: an organisation can now be assessed against requirements to understand its context, manage its innovation portfolio and run its collaborations as a connected whole. And the same ISO committee is drafting guidance on innovation ecosystem management (ISO/CD 56012): which is the mapping of actors, dependencies and flows by another name.

What no requirements standard can do is say how that systemic work is to be practised, the standards' own critics press exactly this point, so the method gap lands on the adopter. That gap is precisely the discipline SOSX operationalises: ecosystem mapping as a typed, parameterised network; indicators as computable values with units, provenance and confidence rather than titles in a report; decisions recorded with their rationale chains and re-tested when the parameters beneath them move. And because every claim, interaction and approval is recorded by construction, the practice leaves evidence as a by-product of doing the work: which is the honest answer to the known failure mode of management standards, the certificate maintained for the badge while the practice decays. To be plain, in the same register as the rest of this page: SOSX is not certified against ISO 56001 and does not certify you; it builds the systemic work the standard requires into daily practice, and keeps the record that practice leaves behind.

There is also the engineering side of the same question, which matters to anyone putting SOSX upstream of a design programme. The approach is aligned to ISO/IEC/IEEE 15288:2023, specifically its Business or Mission Analysis process, and to ISO/IEC/IEEE 21839, 21840 and 21841:2019 for systems of systems: the standards that say what this kind of analysis is, and what a system of systems is, before anyone argues about tooling. The same sentence applies as everywhere else on this page: we align to them and produce evidence against them, and we do not claim compliance with or certification to any of them.

The audit substrate

Compliance documents are only as good as the record beneath them, and two things decide that: what the record contains, and whether its language means the same thing to the person who reads it next. On the second point there is a finding worth knowing. Moore and Thomas, in The Anatomy of Decisions (2nd edn, 1988), report managers asked to rank everyday probability words (probable, likely, possible) ordering them inconsistently, with wide disagreement about what each one meant. Any assurance document written in hedging adverbs inherits that problem: the author's "likely" and the auditor's are not the same claim. The discipline that answers it is old and unglamorous, typed confidence markers and stated ranges, attached to values rather than to prose.

SOSX keeps that record by construction. Every claim in an analysis cites a catalogued source; judgement, formal proof and computation are kept visibly separate, so a reviewer always knows what kind of statement they are reading; every AI interaction is audit-logged; the stages that decide the model pass a human approval gate. So when the oversight body asks how an analysis was produced, the answer is an artefact, not an assurance: the sources, the approval trail, the audit log, produced in hours rather than weeks of assembly.