[Use Case] Agent-team delivery of regulated medical-device compliance work — verifiable authority and evidence semantics in production

Complete every field. Replace the angle-bracket placeholders. Tick boxes with [x].

1. Identification

Title: Agent-team delivery of regulated medical-device compliance work — verifiable authority and evidence semantics in production
Submitting organization: Independent expert
Contact name: Steven Zhao (independent expert)
Contact email: zhaoxinghua06@126.com

Sector (tick all that apply; a cross-industry case may tick more than one):
- [ ] Education
- [ ] Displaced persons / humanitarian
- [x] Health
- [ ] Financial services
- [ ] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Regulated medical-device software compliance

2. The situation

Describe the functional interaction: who is acting, what they are trying to achieve,
and what happens. The trust and security aspects are drawn out in Sections 3 to 5.

Plain language description (required, 3 sentences max):
A regulated medical-device manufacturer uses a multi-agent team to carry out compliance work (change-impact assessment, documentation updates, evidence collection for submissions). A regulatory auditor must later verify that each compliance artefact was produced by an agent acting under valid, traceable authority at the time of production. Today the auditor cannot reconstruct that chain — who mandated the team, under what scope, at which process-state version — because authority grants and evidence-generation events are not recorded in a verifiable form.

Actor (every party involved):
- The medical-device manufacturer (principal and deployer of the agent team)
- The agent team (multiple agents, each with a role in the compliance workflow)
- The regulatory auditor (relying party)
- The attestation service (records authority grants and evidence-generation events)

Action: The agent team produces compliance artefacts (e.g., post-market surveillance reports, design-change impact assessments) across a multi-step workflow; each step generates evidence that later becomes part of a regulatory submission.

Decision required (at the moment the agent acts, what does the party on the receiving
end have to decide? Write it as a question): "May this manufacturer's agent-produced compliance artefact be accepted into the regulatory record as evidence produced under valid, traceable authority?"

Problem encountered (why that decision cannot be made today): Authority grants and production events are not recorded with stable identity and state-version semantics, so an auditor cannot verify (a) which agent did what, (b) under which mandate, (c) at which version of the controlled process state.

Current mitigation: Human review of artefacts before submission; system-level audit logs without cross-agent authority semantics; manual reconstruction of the chain after the fact.

Residual gap: No standard, machine-checkable record that binds (agent identity, mandate, process-state version, evidence event) into one attestable unit; verification is therefore slow, partial, and not reproducible.

3. Actors and context

Taxonomy roles involved
- [x] Principal — the manufacturer's compliance owner granting the mandate
- [x] Relying party — the regulatory auditor
- [x] Builder
- [x] Deployer / Owner
- [x] Agent instance
- [ ] User — interacts with the agent; may or may not be the principal
- [ ] Infra provider
- [x] Attestor — attestation service recording authority and evidence events
- [ ] Other (specify):

Mandates in this case (required)

List each grant of authority. State the legal regime governing each one: the regime
fixes what could be conferred, at what moment standing may change, and with what
continuing effect. A single-regime case is entirely valid.

Cross-border?
- [x] Yes — jurisdictions involved: EU and US regulatory submissions
- [ ] No

Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No

Agent action type (required; tick all that apply. Where several apply, the most
consequential governs the case)
- [ ] Read-only
- [x] Consequential (reversible)
- [x] Irreversible — submission artefacts become legal evidence

Crosses organisational boundary? (required)
- [x] Yes (specify): from manufacturer to external auditor / regulatory authority
- [ ] No

Risk level (required)
- [ ] Low
- [x] Medium
- [x] High — regulated medical-device safety context

4. Theme relevance

Check every theme this situation exercises, mark the single primary theme, and justify
each checked theme against Section 2 above. If your case maps to specific theme
proposals in the themes repository, link them below.

Related theme proposals: FG-TIDA/themes#28 (verifier-side requirements); FG-TIDA/themes#37 (lifecycle verifiable change-event record); FG-TIDA/use-cases#23 (verifier-side challenge reference)

5. Requirements

One row per requirement. Add rows as needed. Type: Legal / Business / Technical.
Technical requirements are the primary output; include legal or business requirements
where they bear on a technical decision. Criticality: Must / Should / Nice-to-have.

6. Assessment criteria

Success criteria: An auditor can reconstruct, for any submitted artefact: (agent identity, mandate, process-state version, evidence event) and identify exactly which parts were not evaluated.
Measurable metric: Time to verify a sample submission reduced vs. manual reconstruction; percentage of evidence events with complete, machine-checkable binding.

7. Duplication check

Required under ITU-T Recommendation A.7 clause 7: the Focus Group does not duplicate work underway in ITU-T study groups or other bodies.

Existing standards or SDOs (which existing work touches this case): NIST AI Agent Standards Initiative (agent identity and authentication research track — no regulated-workflow evidence semantics); ITU-T FG-TIDA current use-case register (no Health-sector case); ISO 13485 / EU MDR cover organisational quality systems but not machine-verifiable agent authority records.

Overlap notes (why the work named above does not already solve this): The Focus Group's verifier-side requirements (themes#28) are the natural home for the standard record format; this case supplies the regulated-sector anchor that existing use cases (Telecom, education, consumer AI) do not cover.

8. Maturity

Pilot status

• [ ] Hypothetical
• [x] Pilot in progress
• [ ] Deployed in production

Reference implementation: n/a (pilot in a regulated compliance workflow)

9. IP and confidentiality

Confidentiality level

• [x] Public
• [ ] FG-internal only
• [ ] Redact before publication

IP notes (optional):

10. Assets

Link to assets:
- [ ] Dataset
- [ ] Code
- [x] Protocol
- [ ] Other:

IP notes (optional): The case proposes a record semantics; no proprietary assets are required to evaluate it.