Your certification workflow, run the way B 18 describes it. Applications in, samples tracked, test work dispatched, evaluations synthesized, certificates signed, every verdict computed from the Recommendation’s model rather than transcribed from prose. Your liability posture does not widen; the platform does digitally what your authority does today.
Assume the Issuing Authority persona through the identity service (the instance resets nightly) and the review queue below is yours.

What you can do
Every act below was performed against the live demo by the scripted capture apparatus before it was listed; each figure names its capture date and links the live surface. An act that cannot be performed does not list.
See every application waiting on you, oldest first. The review queue is a queue, not an inbox folder; nothing waits silently.

Open one and the whole file is there. The applicant, the instrument with its classified attributes, the documentation, the review notes, and the acts the state machine currently allows, and only those.

Issue the sample request from the review. Type evaluation needs physical samples (PD-05 §4.2.5); the request, the shipment, and the receipts are tracked records, and the decision actions stay closed until the samples are received. No silent hop over the sample states.

Accept, and the Evaluation Project opens. The project is the shared dataspace the laboratory joins on dispatch: samples, test requests, reports, verdicts, and the certificate-to-be share one record.

Select the samples for the evaluation, with the justification. R 60-3 §4.7 with the §4.7.2 note, as a recorded act on the project hub (the hub above carries the per-sample selection); only the selected samples ever enter the dispatch pool the matrix below draws from.
Dispatch test work on a matrix. Test forms crossed with samples, assigned per laboratory; one TestRequest per laboratory; out-of-round rows are reported, never silently dropped.

Issue certificates from finalized evaluations. The certificates desk lists what is ready and carries the issued set with its register acts. Registering with the BIML is one act, and the registered copy is the validity reference the public verify page answers from.

Review the certified scope before the signature. Picking a finalized evaluation opens the issuance form: the certified scope from the evaluation’s verdicts, the scheme, the signing key. The signature is your act, and the record says so.

Follow the certificate’s whole lifecycle. Issue annex, revise, issue parallel, renew, suspend, withdraw: each a recorded act on the certificate as the authority sees it, with the BIML registration record and the CNML sign state on the same page.

Bridge the paper world without lying about it. Enter an application for a client, import records, register an offline evaluation: the records-mode entries exist, and what entered offline is marked as such, never dressed as platform evidence.

How it works
What this changes, and what it does not
Today your authority coordinates the chain over email and document stores: applications arrive as PDFs, test reports come back as PDFs, the type evaluation report is assembled by hand, and accepting another authority’s evaluation means trusting their letterhead. On the platform every stage is an act with a record, and the certificate carries its evidence chain. What does not change: your review, your evaluation, your decision, your signature. The verdict engine computes; the authority decides.
Today (SMART) and the vision (SMART+)
Today · SMART
- The IA console: the review queue, the Evaluation Projects, the certificates desk. the console ↗
- The dispatch builder and the laboratory negotiation-evidence record. see it live ↗
- CNML certificates signed over the verdict chain, registered with the BIML, publicly verified. the CNML page ↗
- Records mode: offline evaluations and client-entered applications, honestly marked. the entries ↗
The vision · SMART+
- Verifying another authority’s evaluation cryptographically, chain and all, instead of re-reading prose. roadmap ↗
- The twin-backed evaluation: evidence arriving from the instrument’s SMART twin between bench sessions. roadmap ↗
- Suspension and withdrawal propagated to every verifiable copy the moment you act (the status-list distribution). roadmap ↗
What you can use, and what you can run
Your consoles on the hosted OIML-CS SMART Platform are yours today. If you ask whether your authority can run its own instance, the honest answer involves your Member State, quoted below from the program’s single entitlement source, with the path spelled out.
| Service | Issuing Authority / Test Laboratory (of a Member State) |
|---|---|
| OIML SMART account (the identity service) | ✅ |
| Identity service software | operates under its Member State |
| OIML-CS SMART Platform (cloud) | ✅ their consoles |
| SMART Platform software (self-host) | operates under its Member State’s 🏠 |
| The demo instance | ✅ |
| The Studio viewer | ✅ |
| The Vocabulary | ✅ |
| The status service | ✅ |
| Ommisa, the AI service | ✅ |
| SMART Recommendations content | ✅ |
| The trust registry (organization keys) | ✅ their organization keys |
| The SMI Simulation | ✅ |
| The SMART Twin (SMART+) | roadmap |
- Use — hosted, on the official services
- Self-host — on-prem/cloud, under the category’s own entitlement
- Streaming updates — the rolling channel the deployment runbook names
- The upsell note — see the narratives below the matrix
Quoted from the program's single entitlement source; the full matrix, all member categories by all services, lives atWho can run what.
A body asks: can we self-host?
The honest answer: the entitlement is your Member State’s. An Issuing Authority or Test Laboratory operates its own instance under its proposing Member State’s entitlement — the Member State is the entitled party; the body operates. The IA-only, TL-only, and IA+TL postures exist exactly for this, and the platform’s federation means your instance talks to the OIML-CS platform either way.
The honest questions
Does the platform decide, or do we?
You decide. The verdict engine computes the Recommendation’s arithmetic and states what the evidence supports, including INDETERMINATE where evidence is missing. The review, the evaluation, and the issuance are your acts, recorded as yours. The platform’s discipline is that nothing is transcribed and nothing is silent.
Does this widen our liability?
No. The platform does digitally what your authority does today: the same Declaration, the same scope, the same decision. The certificate is stronger evidence of the same act, not a larger act. If anything, the record-keeping narrows your exposure: every verdict shows what it was computed from.
Another authority’s evaluation crosses our desk. What changes?
Today you trust the letterhead. On the platform the evaluation’s chain is verifiable: the certificate verifies against the BIML-registered copy by number or by file, and the verdict chain behind it names the tests and readings. Full chain-level verification of a foreign evaluation is a roadmap leg; the certificate verification is live today.
We still receive paper applications. Is this all-or-nothing?
No. Records mode exists exactly for the transition: enter an application for a client, register an offline evaluation, import records. What came from paper is marked as coming from paper; the audit trail never pretends otherwise. Gradualness is the design, not the exception.
Where to go next
The Issuing Authority persona, assumed through the identity service. The review queue, the dispatch, the certificates desk.
The roles you recognize, on B 18:2025, with the scheme's document chain.
info@oimlsmart.org: which Recommendations, which scheme, which of your laboratories; the first conversation starts there.





