The applicant's journey
The same chain as flows 01 to 04, from the manufacturer's seat: notified at every stage, progress visible throughout without ever leaking the other parties' workspaces, the certificate downloaded as verifiable data, and a completion that is earned by the record rather than ceremonially closed.
The flow at a glance
The actor is the applicant again (Steelyard Instruments Ltd.) in the portal at /app/portal, plus anyone at the public verify page. This flow is the applicant's viewpoint over the whole arc: the notifications as each stage lands, the progress projection on the application's own page, the certificate at the end, and the settling doctrine that governs what "done" means.
The walkthrough
Notified at every stage
The application received, the project created, the samples requested and received, the dispatch to the laboratory, the test reports' submission, the evaluation's completion, the certificate's issuance, the registration's publication: each stage lands in the applicant's inbox with its reason, and the email channel carries the applicant-facing ones. Nobody phones the authority to ask where things stand; the record says it, stage by stage.
Try it:sign in as Applicant, then work in/app/portalon the demo instance.
The progress view, cone-honest
The application's own page carries the journey: the stages and where the file stands, with the promise set underneath (the claims the record makes and their per-claim verification status). The projection is honest in both directions: it never inflates progress, and it never leaks the other parties' in-flight workspaces. The applicant sees everything the scheme entitles them to (their project, their certificate-to-be), and the restricted fields stay hidden, per the same cone machinery that governs the laboratory's view in flow 03.
Try it:sign in as Applicant, then work in/app/portal/applications/…on the demo instance.
The certificate, downloaded as verifiable data
When the evaluation completes and the certificate issues (flow 04), it appears in the applicant's portal: the full OIML document with its classification table, its conditions, its serials, its dates, its ACTIVE state. It prints as the document the market knows, and underneath it is signed data (the CNML record with its VC, SD-JWT, DPP, and AAS carrier forms when the signing pass has sealed them; the demo's nightly signing keeps the worked example sealed, and the pages say honestly when a form is awaiting it). The manufacturer's software can consume the certificate directly; the PDF era's re-typing ends here.
Try it:sign in as Applicant, then work in/app/portal/certificates/…on the demo instance.
Completion is earned: the settling doctrine
A project is marked Completed only when everything is settled: every fee marked paid (the authority-to-applicant fee, the authority-to-laboratory fees), every sample's custody closed (returned, retained, or disposed), the review threads resolved, the reports finalized, the certificate issued and registered. A premature attempt refuses with the named open items and who owes them; the terminal state lands on the audit chain and the participants' access ends per the cone. Named honestly: the gate's model is decided doctrine in the engineering record, and its surface ships with the platform wave now in review (the audit page tracks it); the demo today shows the certificate ACTIVE and the projects' states reading their truth, and this page will carry the gate's capture when the wave lands.
Try it:sign in as Applicant, then work in/app/portalon the demo instance.
Anyone can verify: the public check
The journey's last step belongs to everyone: a buyer, a market-surveillance officer, another authority. The verify page checks the certificate number against the BIML-registered copy with no account at all: the verdict, the registration record, and the revocation and suspension checks against the W3C Status List with their check timestamp. The certificate the applicant downloaded in S3 is the same data this page verifies; the loop from application to public trust closes here.
Try it:sign in as no account needed, then work in/app/verifyon the demo instance.
The applicant's journey (demo flow 05): the presenter scripts
OIML SMART demo walkthrough, printed from www.oimlsmart.org/demo/applicant-journey. Everything the scripts present is simulated: the demo instance resets nightly and the cast is fictional.
The presenter scripts
Two lengths, keyed to the steps above (S1 to S5). Print this page for a clean copy of the scripts.
The 5-minute presenter script · the committee slot
- 0:00We have walked the chain from three desks. Now the fourth view: the manufacturer who started it all, watching their application cross the scheme. Simulated cast, nightly reset.
- 0:30S1Every stage notifies: the inbox carries each event with its reason. Nobody phones to ask where the file is.
- 1:15S2The progress view: the stages, the promise set with its per-claim verification. Honest in both directions: no inflated progress, no leaked workspaces.
- 2:15S3The certificate: the full OIML document in the portal, and underneath it signed data the manufacturer's software can consume. No more re-typing from PDFs.
- 3:15S4And completion means settled: fees marked paid, custody closed, threads resolved, the certificate registered. A premature close refuses and names what is open. The terminal state is earned.
- 4:00S5The closer needs no account: anyone types the certificate number and gets the verdict against the registered copy, revocation and suspension checks included. That is what public trust looks like as a web page.
- 4:40Try it: the Applicant account, /app/portal; then the verify page without any account at all.
The 20-minute presenter script · the working visit
- 0:00Frame: the applicant is the scheme's customer, and this flow is the customer experience of trust. Simulated cast, nightly reset.
- 1:00S1The notifications inbox: walk the stages of the worked example and match each to the act that produced it (the sample request from flow 02, the report from flow 03, the issuance from flow 04). The record narrates itself.
- 3:30S1The honest coverage: which stages notify the applicant today and which are authority-facing; the catalog grows by declared need, never by noise. The email channel carries the applicant-facing set.
- 5:30S2The progress projection and the promise set: every claim the record makes carries its verification status. Compare with the status spreadsheet every manufacturer keeps today.
- 7:30S2The cone, from the applicant side: their project, their certificate-to-be, and the authority's and laboratory's internal fields hidden. One shared record, three honest views; this is what makes the dataspace safe.
- 9:30S3The certificate page: the document, the conditions, the serials, the revision history. Then the data forms: CNML signed, with the VC, SD-JWT, DPP, and AAS carriers, and the honest note for when a form awaits the signing pass.
- 12:00S3Why data matters to a manufacturer: the certificate feeds their quality system, their customers' procurement systems, and market surveillance directly. The verification is offline-capable; trust does not phone home.
- 14:00S4The settling doctrine: walk the open-items list the gate checks (fees, custody, threads, reports, the certificate). Completion as an earned state is the audit answer to projects that linger half-closed for years. Name the surface's in-review status honestly.
- 16:30S5The verify page, performed: the number, the verdict, the registration record, the status-list checks with their timestamp. Then the pointer: the same check runs by file drop on the CNML verify page, offline.
- 18:30Questions. The usual: access after completion (ends per the cone, the record stays) and corrections (the lifecycle acts on the certificate page: annex, revise, renew, suspend, withdraw). Close on the try-it paths.
Today (SMART) and the vision (SMART+)
Today · SMART
- The stage notifications, the journey projection, the promise set with per-claim verification. the portal ↗
- The certificate as the full OIML document and as signed data, with the public verify page (no account). verify now ↗
- The certificate lifecycle: annex, revise, renew, suspend, withdraw, each a recorded act. the certificate ↗
The vision · SMART+
The honest questions
What can the applicant actually see?
Everything the scheme entitles them to: their application, their project's record, the stages, the notifications, and the certificate. What stays hidden is the other parties' internal work (the authority's review notes, the laboratory's in-flight runs), per the same cone machinery every party sits behind.
Does completion lock the manufacturer out?
The project's working access ends per the cone when it completes; the record stays, and the certificate stays verifiable forever. The lifecycle acts that follow (annex, revise, renew, suspend, withdraw) are new recorded acts on the certificate, not a reopening of the settled project.
Why should a manufacturer trust the gate?
Because it refuses in the open: a premature completion attempt names exactly what stands open and who owes it (a fee unmarked, a sample's custody, an unresolved thread). Nothing closes by ceremony, and the terminal state lands on the audit chain where every party can read how it was earned.
Is any of this journey real?
The manufacturer, the application, and the certificate are the demo's fictional worked example, and the instance re-seeds nightly. The machinery is real: the notifications, the projection, the cone, the signed certificate, and the public verify page are the same code that runs the production hub, captured live this wave.
Where to go next
The engineering record behind all five flows: what the audit found, what the build answered, the doctrine decisions.
The Applicant persona, assumed through the identity service, then /app/portal: the worked example's journey and certificate are already there.
info@oimlsmart.org for a walkthrough with your manufacturers' association or your quality team.
Verified 2026-09-01: every step above was performed headlessly against the live demo by scripts/capture-walkthroughs.ts (the worked example's inbox, journey, and certificate; the public verify page with no account) and each capture carries its assertion record in public/img/walkthroughs/manifest.json. The step names and machine states match the engineering record (DEMO_FLOWS/05) in the smart repository; where a surface is still in flight, the step says so (S4).