The 5-minute presenter script · the committee slot

1. 0:00What you are about to see is a manufacturer applying for OIML type evaluation. Today that is a scanned form, an email, and a spreadsheet. Everything here is simulated: the demo cast is fictional and the instance resets nightly.
2. 0:30S1The first pick is the Recommendation itself, as a card, with its edition. R 60 for load cells. Nothing defaults silently, because everything downstream derives from this pick.
3. 1:30S2This instrument form was not designed by a programmer. The R 60 model authors it: the declaration the Recommendation asks for, clause and all. Change the Recommendation and the form changes.
4. 2:30S3-S4The steps fill in any order and the draft survives leaving. Real life interrupts applications; the wizard is built for that.
5. 3:30S5The authority is picked from cards: the logo, the scope, and only the authorities that can actually take R 60.
6. 4:15S6Review the whole file, submit. The application is now in the authority's queue, and nothing was printed or emailed.
7. 4:45Try it yourself tonight: demo.oimlsmart.org, the Applicant persona, assumed from the account chooser the identity service offers.

The 20-minute presenter script · the working visit

1. 0:00Frame the visit: the application is the scheme's front door. The promise: by the end of this flow the room believes the form is the Recommendation, not a transcription of it. Simulated cast, nightly reset, say it once up front.
2. 1:00S1Open the wizard. Dwell on the Recommendation cards: the publication id, the title, the instrument category. Ask the room who still receives applications naming the wrong edition; this pick pins the edition for everything that follows.
3. 3:00S1Show that changing the Recommendation re-derives the instrument step. The wizard is model-driven, not hard-coded per Recommendation: R 60, R 91, R 129, R 144 all ride the same machinery.
4. 5:00S2The instrument step in depth: the family pick, the model in scope, the classification dimensions. The declaration form is the one R 60-3 §4.5 declares; the guidance on every field reads the model's descriptions, so the vocabulary can never drift from the Recommendation.
5. 7:30S2The product-reference prefill: a registered product reference fills the whole chain. For a manufacturer with a catalogue, the application becomes a review, not a data-entry task.
6. 9:30S3Jump the stepper between reached steps. The per-step validation is honest about what is missing without blocking navigation; the submit gate enforces completeness and names what it wants.
7. 11:30S4Perform the draft: fill, close, return, take the resume banner's offer. The draft is client-side working state; the record starts at submit, which is exactly the honesty the audit chain needs.
8. 13:30S5The samples and the documentation checklist (R 60-2 §2.5): the checklist is the model's, so two authorities cannot invent different documentation demands for the same Recommendation.
9. 15:30S5The authority cards: the logo or the honest monogram, the scope summary, and the per-Recommendation filter. The picker cannot route an R 60 application to an authority that does not cover R 60.
10. 17:30S6Review and submit. Open the application's page: the journey begins. Tease the next flow: at this moment the row is already in the authority's review queue, which is where we go next.
11. 19:00Questions. The two that always come: editions (pinned at S1, carried by the model) and paper (records mode exists for the transition; the audience pages cover it). Close on the try-it path: the Applicant account, /app/portal.