Type evaluation, end to end

One application, walked from the wizard to the public register. A manufacturer’s certification manager starts the morning with a new load cell to certify; by the end of the story the authority’s officers have reviewed, sampled, dispatched, evaluated, and decided, the laboratory’s operators have tested against the Recommendation’s own model, and the certificate sits on the public register where anyone can verify it. Every stage below is a real act on the live demo, performed by the scripted capture apparatus on the date each figure names.

The story, chapter by chapter

The five demo flows are not five stories; they are one story told from five chairs. The per-role chapters (the applicant’s, the authority’s, the laboratory’s) each have their own page on this site, linked as the arc passes their chair. The thread that ties the chapters together on the demo is the canonical worked example: the Steelyard LC-500 load cell’s application, its evaluation project, and certificate R60/2021-A-EX1-26.01.

Chapter 1 · The application (flow 01)

Start the application; the wizard’s first question is the Recommendation. No silent default: the applicant picks R 60 (or R 91, R 129, R 144) from cards, then the instrument step derives from that Recommendation’s model, the samples and documentation follow, and the Issuing Authority is picked from cards that only show authorities able to take the selected Recommendation. The draft saves; the steps are individually navigable. Assume the Applicant persona through the identity service and open the wizard.

Follow the application’s journey from the first minute. The applicant’s own page carries the six-stage journey with the promise set and per-claim verification status; the notifications arrive at every stage. This is flow 05 running underneath all the others.

The applicant’s chair has its own page: For Manufacturers.

Chapter 2 · The authority’s intake (flow 02)

See the application land in the review queue, oldest first. The authority’s morning starts here: a queue, not an inbox folder, so nothing waits silently. Assume the Issuing Authority persona and the review queue is yours.

Open one and the whole file is there. The applicant, the instrument with its classified attributes, the subject chain, the documentation, the review notes, and every act the arc recorded, open and closed, with the project hub and the evaluation workspace one click away. The honest outcomes at review are reject-with-reason (required, audited, the applicant notified) or accept. The sample request, the shipment, and the receipts are tracked records; the decision actions stay closed until the samples are received.

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. The fee negotiation’s evidence (the contract document, its attested hash) files onto the project; the applicant gains the project view with the restricted fields honestly restricted. The dispatch itself is a matrix: test forms crossed with samples, assigned per laboratory.

The authority’s chair has its own page: For Issuing Authorities.

Chapter 3 · The laboratory’s work (flow 03)

The test request lands in the laboratory’s inbox. The laboratory reviews, rejects with reason or accepts, and accepting joins it to the Evaluation Project’s dataspace. Assume the Test Laboratory persona for the inbox.

Then the substantial work: each assigned test runs model-driven, the procedure, its parameters, and its acceptance criteria all from the Recommendation’s model, the measured values judged against the limits the model computes. The test report is authored on the model’s own form and submitted to the authority through the project, as data, not as a PDF. The laboratory’s chair has its own page: For Test Laboratories.

Chapter 4 · The evaluation and the certificate (flow 04)

The authority validates the evidence and decides. Every test-report row validates against the model’s acceptance rules; the verdicts are computed, never hand-tallied; the review period’s comments resolve before finalization. The certificates desk then lists what is ready: the certified scope comes from the evaluation’s verdicts, and the signature is the officer’s own attributed act.

Registering with the BIML is one act, and the register auto-publishes. The certificate goes to the OIML-CS register as a signed, receipt-tracked submission; the registered copy becomes the validity reference. The applicant downloads the certificate in the OIML layout, a document software can verify.

Chapter 5 · The register and the verification (flows 04 + 05, public)

Anyone can read the register. No account: the published certificates, per scheme, with the validity doctrine stated. This is where the arc ends for the world: the public register.

Anyone can verify. Type the number, read the verdict: ACTIVE from the BIML-registered copy, with the live revocation and suspension checks and the CNML signature pipeline. No account, no phone call to the authority: the verify page.

How it works

What this changes, and what it does not

Today this arc runs on email and document stores: the application as a scanned form, the test schedule as a spreadsheet, the reports as PDFs, the type evaluation report assembled by hand, and progress tracked by asking. On the platform every stage is an act with a record, the forms derive from the Recommendation’s model, and the certificate carries its evidence chain. What does not change: the authority’s review, evaluation, decision, and signature; the laboratory’s judgment at the bench; the applicant’s responsibility for the instrument. The verdict engine computes; the people decide.

Today (SMART) and the vision (SMART+)

The honest questions

Is this a real workflow or a mock-up?

Every capture on this page was taken on the live demo by the scripted apparatus on the date the caption names; each figure links the exact surface it came from. The demo runs the same software as the member instances, in demo posture, against a fictional cast (the Steelyard load cell, the Gulliver-cast authorities and laboratories), and it resets nightly. The guided-demo entry on the login page walks the same arc with a presenter script.

Does the platform decide the outcome?

No. The verdict engine computes the Recommendation’s arithmetic and states what the evidence supports, including INDETERMINATE where evidence is missing. The review, the evaluation, the issuance, and the signature are the authority’s acts, recorded as theirs; the laboratory’s readings and judgments are the laboratory’s.

Our applicants still send paper. Is this all-or-nothing?

No. Records mode exists for the transition: the authority can 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. Certificates keep their paper meaning throughout; the CNML original and the public verification are additions.

What happens after the certificate issues?

The lifecycle is first-class: annex, revise, replace, renew, suspend, withdraw, each a recorded act, and the public verification reads the live status. What today ends at issuance is where the SMART+ vision continues: continuous compliance keeps judging the instrument in service, roadmap-labeled where it is not yet live.

Where to go next