0 · Prerequisite
This process cannot operate until the Initiative leaves fail-closed.
Verification is a published determination. Under the Governance Charter the constitutional roles — Editor, Review Committee, Release Authority, Conformance Appeals Authority — are unappointed, and under CONFORMANCE.md R1.5 nothing may be published without a Release Authority. There is therefore no body constituted to verify anyone, and until there is, no submission may be accepted and no listing may be granted.
Stating this first is not a formality. A standard that told implementers to validate before executing, while itself issuing determinations under no declared authority, would be the thing this category exists to replace. The steps required to leave fail-closed are set out in Governance Charter §8.
Everything below describes the process that begins on the day those roles are filled.
1 · Scope
S1.1 — This document governs the verification of implementations against the IOM Standard v1.0 and their listing in the conformance directory. It does not govern the Authority Score artifact, whose conformance is defined in CONFORMANCE.md.
S1.2 — Three kinds of recognition exist in the directory, and this process governs only the first:
| Recognition | What it asserts | Governed here |
|---|---|---|
| Conformant implementation | A product or platform satisfies every mandatory requirement | Yes |
| Solution and service partner | An organization can deliver against the standard | No — a membership determination |
| Endorsing organization | An organization supports the standard as an initiative | No — a membership determination |
S1.3 — Conformance is a property of an implementation at a version, not of an organization. An organization is never conformant. A product at version 4.2 may be; version 5.0 is a separate question.
S1.4 — Open-source and commercial implementations are verified on identical terms, with identical evidence requirements and identical publication.
2 · What conformance is
S2.1 — Conformance is binary. An implementation satisfies every mandatory requirement of the Standard or it does not. There are no levels, no percentages, and no partial listings.
Meeting six requirements and resembling the seventh is not conformance. A capable product that does most of this is a capable product, and saying so is not a lesser statement — it is a different one.
S2.2 — An implementation that does not satisfy every mandatory requirement MUST NOT be described as conformant. Per Standard §14 it MAY be described as IOM-informed.
S2.3 — The mandatory requirements are those of Standard v1.0, Appendix A. This document does not restate them and MUST NOT be read as modifying them. Where this document and the Standard differ, the Standard governs.
S2.4 — The IOM Maturity Model is not a conformance instrument. It scores an organization’s estate on a graduated scale; conformance assesses a product against a binary bar. A submitter’s maturity score is irrelevant to this process, and a determination MUST NOT cite one.
3 · Roles
Verification uses the constitutional roles defined in the Governance Charter. It introduces none.
| Role | In this process |
|---|---|
| Review Committee | Reviews evidence · witnesses the demonstration · issues the determination |
| Release Authority | Publishes the listing and the evidence record · retires a lapsed listing |
| Conformance Appeals Authority | Hears appeals against the evidence and procedure behind a determination |
| Editor | Maintains this document · has no role in any determination |
S3.1 — The reviewers who witness a demonstration MUST NOT hold a commercial interest in the implementation under review, an employment relationship with the submitter, or a role in its development.
S3.2 — Where the Initiative or any of its members has any relationship with a submitter, the determination record MUST disclose it, in the same place and the same manner as the determination itself.
A disclosed conflict is a fact a reader can weigh. An undisclosed one, discovered later, retroactively devalues every listing the directory has ever issued — including the honest ones.
S3.3 — A submission from an organization that holds a governance role in the Initiative MUST be reviewed by a panel constituted entirely from outside that organization, and the determination record MUST state that this was done.
4 · Stages
Application → Evidence → Demonstration → Determination → Listing → Re-verification
S4.1 — An application MUST identify the implementation, the exact version submitted, and a technical contact able to operate the system during a demonstration.
S4.2 — Evidence is reviewed before a demonstration is scheduled. A demonstration is expensive for both parties, and evidence that cannot support a claim on paper will not support it live.
S4.3 — A submission MAY be returned once for completion without prejudice. A second incomplete submission SHOULD be closed and re-applied for.
S4.4 — There is no fee. Nothing in this process may be purchased, expedited, or influenced by membership status, and a determination MUST NOT reference either.
5 · Evidence
S5.1 — Evidence MUST be submitted for each mandatory requirement separately. A single architectural overview addressing several at once is not evidence; it is a description.
S5.2 — For each requirement, a submission MUST provide:
| The mechanism | How the requirement is satisfied, in enough detail that a reviewer could predict the system’s behaviour in a case the submitter did not choose |
| The boundary | What the mechanism does not cover — which asset classes, which change paths, which environments |
| The artifact | A concrete instance: a blueprint, a refusal record, an evidence trail, a reconciliation output |
S5.3 — The boundary statement is mandatory and its absence is disqualifying. An implementation that cannot state where its coverage ends has not established that it has one.
Every requirement in the Standard is a statement about authority, and authority is bounded by scope. A submission claiming universal coverage is describing something other than what was built.
S5.4 — The following MUST NOT be accepted as evidence for any requirement:
- Product documentation describing intended behaviour
- Roadmap commitments, beta features, or capabilities behind a flag not enabled in the submitted version
- Screenshots or recordings prepared by the submitter
- Synthetic datasets, reference environments, or demonstration estates authored for the purpose
- Customer testimony about outcomes
S5.5 — Evidence MUST be submitted in a form that can be published. Material that cannot be published cannot be relied on, because a listing whose basis is confidential is an assertion rather than a verification. Where a customer environment is involved, the submitter MUST obtain permission to publish, or use a different environment.
6 · Demonstration
S6.1 — Every mandatory requirement MUST be demonstrated live, against live infrastructure, operated by the submitter and witnessed by reviewers.
S6.2 — Reviewers MUST direct at least part of the demonstration. A submitter-scripted sequence establishes that a path works; it does not establish that the system behaves correctly in a case nobody rehearsed.
S6.3 — The demonstration MUST include at least one refusal: a proposed change that violates a declared constraint, blocked before execution, with the reason returned and the attempt recorded. A submission that can show approval but not refusal has demonstrated a pipeline, not an authority layer.
S6.4 — The refused change MUST violate a constraint declared before the demonstration was scheduled. A constraint authored to produce the refusal demonstrates the fixture, not the system.
S6.5 — Reviewers MUST be able to inspect the system’s account of what it did — what was proposed, what was permitted, what was refused, and on what basis — without the submitter mediating access.
S6.6 — A demonstration MAY be halted and rescheduled if the environment proves not to satisfy §7. A halted demonstration is not a failure and MUST NOT be recorded as one.
7 · What “against live infrastructure” means
This is the requirement most likely to be met in form and evaded in substance, so it is defined rather than left to judgement.
S7.1 — An environment satisfies this requirement only if all of the following hold.
It is in production use, or a faithful replica of one. The estate serves real workloads with real availability expectations, or reproduces one asset-for-asset. An environment built to be demonstrated is not one.
It contains assets the implementation did not create. The estate includes infrastructure that predates the implementation, or arrived through paths it does not manage. A model of only what a tool provisioned is a record of its own output.
It is heterogeneous. More than one domain — some combination of cloud, network, identity, on-premises, or operational technology. A single-domain estate cannot exercise the cross-domain requirements at all.
It contains things nobody documented. Real estates carry undeclared configuration, historical exceptions, and assets whose purpose is remembered rather than recorded. An environment without them cannot exercise reconciliation, because there is nothing to reconcile against.
Change arrives by more than one route. At minimum a governed path and an unmanaged one. An implementation that governs only changes arriving through its own interface has not demonstrated authority over the estate; it has demonstrated authority over itself.
S7.2 — The environment MUST be described in the evidence record with sufficient specificity for a reader to judge whether it meets §7.1 — the domains covered, the approximate scale, and the age profile of the estate.
S7.3 — Where the environment belongs to a customer of the submitter, the customer’s identity MAY be withheld, but the characteristics required by §7.2 MUST NOT be.
8 · Determination
S8.1 — The Review Committee issues one of three determinations.
| Determination | Meaning |
|---|---|
| Conformant | Every mandatory requirement demonstrated. Listed. |
| Not conformant | One or more requirements not demonstrated. Not listed. |
| Incomplete | The demonstration could not be completed. Neither listed nor recorded as a failure. |
S8.2 — A determination MUST state, per requirement, whether it was demonstrated and what was shown. A determination that reports only an outcome cannot be checked and is not a verification.
S8.3 — A determination of not conformant MUST identify which requirements were not satisfied. It MUST NOT be published. The directory records what is conformant; it is not a register of unsuccessful applicants.
Publishing failures would make submission an act of risk, and a process nobody enters verifies nothing.
S8.4 — A submitter MAY re-apply at any time, and the prior determination MUST NOT prejudice the new one.
9 · The listing
S9.1 — A listing MUST carry: the implementation, the exact version verified, the determination date, the environment description required by §7.2, and the published evidence record.
S9.2 — The evidence record is published in full. A listing whose basis cannot be read is a badge.
S9.3 — A listing asserts conformance of the version verified, on the date verified. It asserts nothing about later versions, and nothing about any deployment other than the one demonstrated.
S9.4 — The Initiative grants the listing. A listing is never claimed by the holder. A conformance claim made anywhere other than the directory is the holder’s own statement and is not a determination of the Initiative — which is the distinction the directory exists to make legible.
10 · Re-verification and lapse
S10.1 — A listing SHOULD be re-verified every twelve months, and MUST be re-verified on a major version change of the implementation.
The interval is a judgement, not a measurement. It is short enough that a listing describes something recognisably current, and long enough that verification remains proportionate to what it establishes.
S10.2 — A listing not re-verified within its interval MUST be marked lapsed rather than removed. It stays published, with its date, and stops asserting present conformance.
Removal would erase the fact that a determination was once made, which is a fact readers may legitimately want. Immutability applies to determinations for the same reason it applies to releases: a record that can vanish cannot be relied on while it is present.
S10.3 — A holder MAY withdraw a listing at any time, and the reason MUST NOT be published unless the holder asks for it to be.
S10.4 — The Initiative MAY revoke a listing where evidence is found to have been materially inaccurate. Revocation MUST be published with its basis, and is appealable under §11.
11 · Appeals
S11.1 — A submitter MAY appeal a determination to the Conformance Appeals Authority.
S11.2 — An appeal MAY challenge the evidence and the procedure — that a requirement was assessed against something the Standard does not require, that submitted evidence was not considered, that the demonstration was halted improperly, that a conflict was not disclosed.
S11.3 — An appeal MUST NOT challenge the outcome of a demonstration that took place. A requirement demonstrated or not demonstrated is a matter of record.
If an appeal could reverse an undemonstrated requirement, a committee could confer conformance on an implementation that did not show it. That is a human override of a determination the process exists to make on evidence — the defect the Standard scores against at D5.3.
S11.4 — The Appeals Authority MAY uphold, vacate, or remand for re-demonstration. Where a determination is vacated because the Initiative erred, the error MUST be published in the same manner as any determination.
S11.5 — The Appeals Authority SHOULD NOT be a member of the panel that issued the determination. Where it is, the appeal record MUST disclose it.
12 · Open question for the Standard
The seventh requirement is stated two ways.
Standard v1.0 Appendix A qualifies AI governance with “(where present)”. The Starter Kit conformance checklist and the Conformance Scorecard both treat it as unconditional. An implementation with no AI surface is therefore conformant under the normative document and non-conformant under both instruments derived from it.
Until the Standard resolves this, verification under this document reads Appendix A as governing, per S2.3: where an implementation has no AI-mediated change path, the requirement is assessed as not applicable and recorded as such in the evidence, with the boundary statement required by S5.2 stating why.
This reading is stated so that determinations are consistent and the choice is visible. It is not a resolution, and the Editor SHOULD raise it for the Standard’s next revision.
An open publication of The IOM Standard. Distributed under CC BY 4.0. “Proposed standard” — vendor-neutral, community-governed.