Visual tool-validation evidence / scope-limited report

Follow one device dossier from release to correction

Intended use shown

An authorised manufacturer uses MDIS to prepare a device document release, obtain a partner's review, correct an affected document and deliver the approved successor. The worked example is the synthetic AtlasView Multi-EO Release Monitor dossier.

The story

39 consecutive steps, 39 original screenshots. Follow the manufacturer, the authorised representative and an unrelated company in separate authenticated sessions. Each page carries the exact executed Gherkin step and its observed outcome.

Disposition

Representative workflow evidence. A passing scenario supports this defined workflow on the recorded candidate. It does not approve every MDIS requirement, every redesign screen, or a client's own configuration.

How to read it

Read the expectation above each image, then compare the observed result with the screen. Assertions about persisted identities, revisions and audit history are identified explicitly: those facts are not established by a screenshot alone. The PDF uses large A3 landscape pages; each page shows the captured viewport; full original images remain available in the HTML; the companion HTML opens offline and supports full-size images.

Execution scope

What was exercised - and where

Software and environment

MDIS ui-v2 + API + PostgreSQL, built and run as a local disposable Docker stack. Chromium automated browser execution. Synthetic accounts and documents only. Storage uses fake GCS, email uses Mailpit with the SMTP proxy, and EUDAMED uses the disposable simulator; these external production services are not validated here.

Starting conditions

The disposable seed supplies an existing device dossier and connected operators. This focused story adds an authorised representative, opens its first release candidate and prepares two synthetic document revisions. It begins after account and device provisioning; those setup workflows and medical-device clinical use are outside this story.

Record identity

Run: local-b275539ea5-20260907T172831Z
Source: MedQAIR/MDIS @ b275539ea53f70cb04466895853fe05c7fd62c86
Focused story execution: 2026-09-07T17:29:09.104Z to 2026-09-07T17:29:19+00:00 UTC.
The screenshots and source-input hashes are recorded in the accompanying evidence index.

Traceability boundary

The exact scenario is A visible changes request stops one release and its successor can deliver, in features/release-integration/release-document-feedback.feature, tagged @SR-197 / @VAL-REL-019. Its wider UR and risk tags are routing metadata, not evidence that every obligation under those requirements passed.

Prepare and release / Step 01 of 39 / Manufacturer

Introduce the participants

Expected

Three independent sessions represent the manufacturer, its reviewer and an unrelated company.

Observed · step passed

Three distinct browser contexts and selected context identities were verified.

Given the anchored-feedback participants use separate signed-in sessions
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 02 of 39 / Manufacturer

Open the device dossier

Expected

Open the existing AtlasView Multi-EO Release Monitor dossier.

Observed · step passed

The recorded device URL opens in ui-v2; this starts from a seeded dossier.

And I open the current multi-EO release device
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 03 of 39 / Manufacturer

Inspect the device's connections

Expected

Open Who receives it to inspect the device's economic operators.

Observed · step passed

The current access surface is available for this device.

And I open the device's access page
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 04 of 39 / Manufacturer

Connect the authorised representative

Expected

Add the test authorised representative to the device.

Observed · step passed

The representative is added through the current access surface. A connection alone is not a document grant.

And I add the authorised representative to this device
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 05 of 39 / Manufacturer

Return to the device

Expected

Return to the same device before preparing a change.

Observed · step passed

The browser returns to the recorded device URL.

And I go back to the device
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 06 of 39 / Manufacturer

Start the release candidate

Expected

Create the named production-version draft using the current change flow.

Observed · step passed

A new draft opens for VAL-REL-019 automated review.

And I start production version "VAL-REL-019 automated review"
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 07 of 39 / Manufacturer

Prepare two document revisions

Expected

The release contains the product label and an unaffected multilingual eIFU.

Observed · step passed

Two document revisions are available in the candidate. This is seeded test content.

And I ensure the current release has two documents
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 08 of 39 / Manufacturer

Confirm release authority

Expected

Complete and confirm the current release-authority fields.

Observed · step passed

The journey completes the release-authority controls before releasing.

And I complete and confirm the current release authority
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 09 of 39 / Manufacturer

Choose the delivery recipient

Expected

Select the product-label revision for the test importer.

Observed · step passed

The selection is saved through the UI; a fresh API read contains the target revision.

And I configure the fresh anchored-feedback delivery
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 10 of 39 / Manufacturer

Require the representative's approval

Expected

Configure the authorised representative as a blocking approver.

Observed · step passed

The representative is selected as Approve before the release action.

And I configure the authorised representative as a blocking approver
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 11 of 39 / Manufacturer

Release once

Expected

Submit this candidate once for its configured approval process.

Observed · step passed

One Release action submits the candidate. The next step checks the waiting state.

And I release this tracked candidate once
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Prepare and release / Step 12 of 39 / Manufacturer

Wait for the blocking decision

Expected

Delivery must wait while the blocking approval is outstanding.

Observed · step passed

The release visibly waits for approval; delivery has not activated.

Then delivery is visibly waiting for its blocking decision
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Partner review / Step 13 of 39 / Authorised representative

Hand over to the reviewer

Expected

Continue in the representative's own authenticated session.

Observed · step passed

The selected actor, user and context are checked against the representative's retained session.

When the authorised representative takes over the anchored-feedback review
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Partner review / Step 14 of 39 / Authorised representative

Open the exact approval request

Expected

Open this release's request from the work queue.

Observed · step passed

The exact tracked release is selected; Approve the release and Frozen release documents are visible.

And I open the exact anchored-feedback approval from the work queue
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Partner review / Step 15 of 39 / Authorised representative

Anchor feedback to the PDFs

Expected

Create region feedback on the label and separate page feedback on the unchanged eIFU.

Observed · step passed

Both anchors were asserted in their respective document tabs; API responses bind each to its exact revision and approver.

And I open anchored feedback on the changed and unaffected PDFs
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Partner review / Step 16 of 39 / Authorised representative

Request a correction

Expected

Record a changes request with a reason against the frozen candidate.

Observed · step passed

The approval-decision response is retained for later identity and audit checks.

And I request the anchored correction on the frozen release
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Partner review / Step 17 of 39 / Authorised representative

Confirm the recorded decision

Expected

The application must acknowledge the submitted decision.

Observed · step passed

Decision recorded. is visible. Persisted decision attribution is checked again in step 36.

Then the anchored-feedback approval decision is durably recorded
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 18 of 39 / Manufacturer

Return to the manufacturer

Expected

Continue in the original manufacturer's session.

Observed · step passed

The acting session changes back to the manufacturer without reusing the reviewer's context.

When the Manufacturer resumes the anchored-feedback release
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 19 of 39 / Manufacturer

Reopen the stopped release

Expected

Open the same tracked release after the changes request.

Observed · step passed

The browser opens the retained release URL; the following step checks the feedback.

And I reopen the tracked release
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 20 of 39 / Manufacturer

Read and answer the finding

Expected

Find both threads, reply to the label finding and mark it addressed.

Observed · step passed

The reply is stored and visible; the label thread is Addressed and the independent eIFU anchor remains visible.

Then the Manufacturer discovers and answers the anchored feedback
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 21 of 39 / Manufacturer

Start a correction successor

Expected

Use the supported further-release path to correct the frozen attempt.

Observed · step passed

A separate successor draft opens; the released attempt is not edited in place.

When I start the supported further-release remedy
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 22 of 39 / Manufacturer

Check the successor setup

Expected

Keep the approver editable and reconcile saved audience counts.

Observed · step passed

The UI counts match the saved selection and the approver remains editable. Counts alone do not prove recipient identities.

Then the successor keeps its approver editable and shows its saved audience counts
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 23 of 39 / Manufacturer

Replace the affected revision

Expected

Upload a corrected label while carrying the unaffected eIFU forward.

Observed · step passed

Fresh release data identifies a new label revision and the unchanged eIFU revision.

When I upload the corrected immutable successor revision
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 24 of 39 / Manufacturer

Select the corrected delivery revision

Expected

Explicitly select the corrected label for the importer.

Observed · step passed

The current recipient picker saves the successor selection and fresh data confirms the corrected revision.

And I keep the corrected revision in the configured delivery
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 25 of 39 / Manufacturer

Release the successor once

Expected

Submit the corrected candidate through one Release action.

Observed · step passed

The successor is submitted once; its approval state is checked next.

And I release this tracked candidate once
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Correct through a successor / Step 26 of 39 / Manufacturer

Wait again for approval

Expected

The correction must not bypass the blocking approval.

Observed · step passed

The successor visibly waits for its blocking decision.

Then delivery is visibly waiting for its blocking decision
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Review the correction / Step 27 of 39 / Authorised representative

Hand the correction to the reviewer

Expected

Continue in the same representative's independent session.

Observed · step passed

The retained reviewer identity is checked before the successor review.

When the authorised representative takes over the anchored-feedback review
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Review the correction / Step 28 of 39 / Authorised representative

Open the successor approval

Expected

Choose the exact successor from the work queue.

Observed · step passed

The tracked successor's approval page and frozen documents are visible.

And I open the exact anchored-feedback approval from the work queue
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Review the correction / Step 29 of 39 / Authorised representative

Review the carried finding

Expected

Keep feedback lineage while preventing a stale anchor on the replacement PDF.

Observed · step passed

The reply and origin survive. The old region anchor is absent on the replacement; the unchanged eIFU keeps its own anchor.

Then the reviewer sees the carried finding without a stale anchor
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Review the correction / Step 30 of 39 / Authorised representative

Resolve the corrected finding

Expected

Resolve the carried label finding on the successor.

Observed · step passed

The resolution request succeeds and the thread visibly reads Resolved.

When I resolve the carried anchored finding
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Review the correction / Step 31 of 39 / Authorised representative

Approve the correction

Expected

Approve and record the successor's decision.

Observed · step passed

The reviewer submits the approval through Record decision. This is a synthetic test decision.

And I approve the anchored-feedback successor
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Review the correction / Step 32 of 39 / Authorised representative

Confirm the approval was recorded

Expected

Acknowledge the approved decision in the reviewer's view.

Observed · step passed

Decision recorded. is visible; the exact persisted decision is checked in step 36.

Then the anchored-feedback approval decision is durably recorded
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Deliver and retain evidence / Step 33 of 39 / Manufacturer

Return to delivery oversight

Expected

Return to the manufacturer's existing session after approval.

Observed · step passed

The manufacturer takes over without another Release action.

When the Manufacturer resumes the anchored-feedback release
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Deliver and retain evidence / Step 34 of 39 / Manufacturer

Reopen the successor

Expected

Open the exact successor to inspect its final state.

Observed · step passed

The retained successor URL opens in ui-v2.

And I reopen the tracked release
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Deliver and retain evidence / Step 35 of 39 / Manufacturer

Observe automatic delivery

Expected

The blocking approval must activate delivery without a second release action.

Observed · step passed

The tracked successor is delivered after approval. The manufacturer has not pressed Release again.

Then the tracked release is delivered without another Release action
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Deliver and retain evidence / Step 36 of 39 / Manufacturer / automated API checks

Reconstruct the retained history

Expected

Fresh reads must preserve both attempts, decisions, actors, feedback lineage and final delivery.

Observed · step passed

Persisted identity, audit, decision and feedback checks pass. The picture shows the final UI; the database facts come from assertions.

And fresh reads reconstruct the anchored-feedback release history
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Refuse unrelated access / Step 37 of 39 / Unrelated manufacturer

Switch to an unrelated company

Expected

Use a separate company session for the isolation check.

Observed · step passed

The acting session switches to the foreign manufacturer; the next steps test access refusal.

When the unrelated Manufacturer takes over for the isolation check
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Refuse unrelated access / Step 38 of 39 / Unrelated manufacturer / automated API checks

Attempt foreign reads and writes

Expected

An unrelated company must not read or mutate this feedback.

Observed · step passed

The scenario executes direct read and mutation refusal checks using the foreign session.

And I try to read and mutate the exact anchored feedback
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Refuse unrelated access / Step 39 of 39 / Unrelated manufacturer

Show the non-disclosing result

Expected

The foreign UI must disclose no protected feedback and offer no lifecycle actions.

Observed · step passed

The non-disclosing view and absence of lifecycle controls are asserted. This is the final negative-control step.

Then the foreign anchored-feedback view is non-disclosing and has no lifecycle actions
@SR-197 · @VAL-REL-019 · screenshot after this exact step

Results and remaining coverage

A passed story is one part of the evidence

Recorded machine result

The selected story passed all 39 steps. The latest complete browser run at ac5713498 recorded 70/71 normal tests passed (98.6%), 1 failed and 0 skipped. Its separate authentication lane passed 2/2; combined, that is 72/73 (98.6%). The screenshots in this report come from the earlier focused run at b275539ea5; they are not relabelled as captures of ac5713498. The full-suite result and illustrated evidence therefore have distinct source identities.

Redesign coverage

The recorded screen-ledger baseline is 84 screens: 47 uncovered, 34 preview-only, 2 real-stack and 1 recorded. A test can pass without proving an entire screen's acceptance criteria. This report does not promote a ledger row merely because a screenshot visits it.

Known limits

The nightly evidence receipt was not green at preparation time. No controlled User Requirement is yet recorded as fully validated. A complete requirement-level conclusion must come from the controlled validation-report reconciliation, not from this illustrated companion.

Revalidation

Reassess this evidence when the UI journey, approval semantics, permissions, schema, document revision behavior, deployment configuration or external interfaces change. This report identifies the exact tested source; it is not a claim about an unspecified later release.

Full-suite deviation / latest run at ac5713498

One accessibility failure remains outside this passing story

Accessibility

A manufacturer releases with the keyboard: the existing Axe assertion reports serious text-contrast failures in the approval controls. Candidate text/monograms measured 3.52:1 and role controls 4.18:1 against the 4.5:1 requirement. The assertion remains enabled; the complete run is not qualifying.

Four earlier functional failures now pass

The fresh complete run passed frozen first-release withdrawal, starting a successor release, the unavailable add-device explanation, and the two-release correction-successor journey. The upload step was corrected to wait for transfer completion and the authoritative document row before editing or committing the release. These results supersede the four functional failures recorded at 92578a21e.

Approval-chain checks

The PRRC, authorised representative, importer and distributor obligations passed in this full run. These checks demonstrate their named assertions, not complete coverage of every screen or controlled requirement.

Separate capture and verification identities

Illustrations: b275539ea53f70cb04466895853fe05c7fd62c86, run local-b275539ea5-20260907T172831Z.
Latest complete suite: ac571349833908a92626548a4ecc2e908e195763, run local-ac57134983-20260907T175944Z. The remaining contrast issue requires a product fix and a new passing verification run.

Client adoption record / intentionally unapproved

Use this evidence in your own tool-validation record

1. Confirm your intended use

Record your organisation, MDIS environment and version, intended users, workflows and the records you rely on. Identify which parts of this demonstrated workflow apply to your use and which additional workflows need evidence.

2. Check configuration and differences

Compare your roles, approval policy, recipients, integrations and retention settings with the recorded test conditions. Record deviations and any additional checks on your configured environment. The supplier's synthetic test environment does not establish your local configuration.

3. Record your conclusion

Document acceptance criteria, applicable evidence, unresolved deviations, their impact and any required actions. Attach this report by its evidence-index hash. Keep the decision proportionate to the intended use and your quality-system process.

4. Review and approve

Client organisation: ______________________________
Intended-use / validation record reference: ______________________________
Environment and version: ______________________________
Reviewer, decision and date: ______________________________
Approval is deliberately left to the client's authorised reviewer.