part-03-information-model: INFORMATION-MODEL.yaml
Contracts and profiles MUST use these types verbatim.
module: information-model part: 3 version: 0.1-draft edition: 2026a-draft
Agent — the canonical agent record (Part 4, Part 5)
agent: description: > Any entity allocatable to tasks: human staff, robot, or human-in-the-loop operator station. required_fields: - agent_id - agent_type - availability_status fields: agent_id: type: string description:
part-04-services: availability_provider_contract.yaml
Defines the interface any workforce data source must implement
to feed agent availability into the orchestrator cross-allocation engine.
Implementations:
part-05-transport: capability-registry.yaml
capabilities: transport.medication: label: Medication Transport description: > Transport of pharmaceutical products requiring temperature monitoring and chain-of-custody tracking. params: temperatureRange: type: object properties: min: { type: number, unit: celsius } max: { type: number, unit: celsius } default: min: 2 max: 8 chainOfCustody: type: boolean default: true compl
part-06-security: identity-trust.yaml
requirements for all agents, adapters, providers and
connectors crossing the IT/OT boundary.
Companion parts: Part 4 (service contracts), Part 5 (transport),
Part 7 (data governance — depends on this part for
attribution)
deployment profile, not by this specification.
module: identity-trust part: 6 version: 0.1-draft edition: 2026a-draft
terminology: orchestrator: > The system implementing
| ID | Principle |
|---|
it-p-001 | Every non-human agent (robot, adapter, provider, connector) MUST hold a verifiable machine identity. No anonymous participants at the IT/OT boundary.
|
it-p-002 | Identity lifecycle is bound to agent lifecycle: onboarding of an agent implies identity issuance; offboarding implies revocation.
|
it-p-003 | Open standard in the specification, replaceable vendors in implementation. This part references SPIFFE and X.509; it MUST NOT reference any CA vendor, IAM product, or national identity scheme normatively. National schemes enter as deployment profiles.
|
it-p-004 | All identity events (issuance, rotation, revocation, failed authentication) MUST be written to the orchestrator's immutable audit trail.
|
L1 — Pilot / Lab
| ID | Requirement | Verification |
|---|
it-req-001 | Every agent presents a unique X.509 client certificate. | conformance test ID-01 (shared certificates rejected) |
it-req-002 | Static certificates permitted; maximum validity 24 months. | certificate inspection |
it-req-003 | Manual revocation supported: a revoked agent is denied within one operational day.
| conformance test ID-02 |
it-req-004 | Identity events logged to the audit trail (it-p-004). | audit log inspection |
L2 — Production Single Site
| ID | Requirement | Verification |
|---|
it-req-101 | Certificate rotation without service interruption. Maximum validity: PENDING-DEPLOYMENT-PROFILE (reference value: 90 days).
| conformance test ID-10 |
it-req-102 | Revocation propagated to all brokers/endpoints within PENDING-DEPLOYMENT-PROFILE (reference value: 15 minutes).
| conformance test ID-11 |
it-req-103 | Network zone model enforced: agents in the OT zone communicate with IT-zone systems ONLY via the convergence layer (see Part 1). Zone parameters: PENDING-DEPLOYMENT-PROFILE.
| architecture review + network test ID-12 |
it-req-104 | Certificate profile (key type, EKU, SAN content) conforms to the deployment's CA policy. Profile: PENDING-DEPLOYMENT-PROFILE.
| certificate inspection |
L3 — Production Multi-Site
| ID | Requirement | Verification |
|---|
it-req-201 | Fully automatic issuance and rotation (no human in the loop for routine lifecycle); SPIRE or equivalent workload-identity plane.
| conformance test ID-20 |
it-req-202 | Central revocation authority with signed revocation feed; propagation under 5 minutes.
| conformance test ID-21 |
it-req-203 | Onboarding/offboarding in the agent registry triggers identity issuance/revocation atomically (no orphan credentials, no credential-less registered agents).
| conformance test ID-22 (orphan sweep) |
it-req-204 | Compromise response: a flagged agent is quarantined (denied all brokers/endpoints, task allocation suspended) within 5 minutes.
| tabletop exercise + conformance test ID-23 |
Regulatory Mapping
| Regime | Relevance |
|---|
| EU CRA | security-by-design for products implementing this standard |
| IEC 62443 | Conformance levels map informatively (not certifiably) to security levels: L1~SL1, L2~SL2, L3~SL3.
|
| NIS2 | hospital operators; zone model (it-req-103) is the hook |
| Normen (NO) | applies to Norwegian deployments (no-helseid profile) |
part-07-data-governance: data_governance_module.yaml
transfer governance for all data crossing the IT/OT boundary
or leaving the deployment’s trust domain.
Companion modules: identity-trust (attribution prerequisite),
fleet-binding (VDA 5050), availability-provider, task-source
deployment profile, not by this specification.
module: data-gove
| ID | Principle |
|---|
dg-p-001 | The convergence layer is the only sanctioned data path across the IT/OT boundary. Direct cloud egress from robots or vendor fleet systems is out of policy. (Extends it-req-103 from access control to data flow.)
|
dg-p-002 | Data minimization by protocol: the boundary protocol (VDA 5050 profile) carries state, orders and operational telemetry only. Sensor payloads (video, audio, point clouds) do not cross the convergence layer. This is a spec principle, not an implementation choice.
|
dg-p-003 | The spec provides the policy and verification surface, not physical prevention. Enforcement requires OT-zone network controls (egress deny) and contractual terms. Documentation and marketing MUST state this boundary honestly.
|
dg-p-004 | Every declared data flow is attributable: flows are bound to the originating agent's machine identity (identity-trust) and logged to the immutable audit trail.
|
L1 — Pilot / Lab
| ID | Requirement | Verification |
|---|
dg-req-001 | Every agent has a data profile in the Agent Registry: cap-006): sensors on board, data classes generated, declared destinations, lawful basis per destination.
| registry inspection; conformance test DG-01 |
dg-req-002 | Every provider/task-source connection declares data_classes_delivered, declared_destinations and lawful_basis (availability_provider_contract data_profile section).
| contract inspection; conformance test DG-02 |
dg-req-003 | Sensor-payload class does not traverse the convergence layer (dg-p-002). Teleoperation exception per dg-req-020.
| conformance test DG-03 (payload injection attempt must be rejected) |
dg-req-004 | Operational telemetry is verified free of personal-data fields (no names, no free-text carrying patient/staff identifiers in order payloads).
| schema review + conformance test DG-04 |
L2 — Production Single Site
| ID | Requirement | Verification |
|---|
dg-req-101 | All vendor telemetry/diagnostic egress is declared, routable and blockable at the convergence layer. Undeclared destinations are denied by default.
| conformance test DG-10 (undeclared endpoint blocked) |
dg-req-102 | No third-country transfer of any data class without a documented transfer basis (SCC, adequacy decision, or equivalent) recorded in the registry entry. Approved-destination list: PENDING-DEPLOYMENT-PROFILE.
| registry inspection; audit sample |
dg-req-103 | Data flows are attributable to agent identity in the audit trail: which agent, which class, which destination, when. Retention period: PENDING-DEPLOYMENT-PROFILE (reference value: 12 months).
| conformance test DG-11 (flow → identity lookup) |
dg-req-104 | The registry can export an Article 30-compatible record of processing (per-agent and per-connection view) on demand.
| export test DG-12; DPO review of format |
L3 — Production Multi-Site
| ID | Requirement | Verification |
|---|
dg-req-201 | Egress policy is enforced technically at the convergence layer (allow-list per agent identity and data class), not only declared. Policy changes are versioned and approved (two-person rule: PENDING-DEPLOYMENT-PROFILE).
| conformance test DG-20 |
dg-req-202 | Continuous verification: declared data profiles are reconciled against observed flows; deviations raise governance events within 24 hours.
| conformance test DG-21 (planted deviation detected) |
dg-req-203 | Third-country transfer register is auditable per art. 30 with per-transfer lawful-basis reference, exportable to regional compliance systems. Format: PENDING-DEPLOYMENT-PROFILE.
| export test DG-22 |
All Levels
| ID | Requirement | Verification |
|---|
dg-req-020 | Teleoperation/remote assistance MAY carry sensor payloads across the boundary ONLY as a declared exception: (a) registered in the agent's data profile, (b) session-bound and time-limited, (c) initiated by an identified human operator, (d) logged start/stop with operator identity, (e) terminated automatically at session end. Standing sensor streams are never an exception.
| conformance test DG-30 (session lifecycle); audit inspection |
Data Classes
| Class | Definition | Personal Data? |
|---|
| operational-telemetry | State required for orchestration: position, battery, task/order state, error codes, availability.
| no (by design; see dg-req-004) |
| diagnostic | Vendor service data: logs, firmware state, component wear, performance counters.
| normally no; must be verified per vendor |
| sensor-payload | Raw or derived sensor streams: video, audio, lidar/point clouds, images.
| presumed YES in healthcare environments (GDPR art. 9 exposure) |
| personal-data | Any data relating to identified/identifiable persons, including staff scheduling data delivered by availability providers and task metadata naming individuals.
| True |
Regulatory Mapping
| Regime | Relevance |
|---|
| GDPR (incl. art. 9, art. 30) | data classes, lawful basis, records of processing |
| Schrems II / third-country transfers | dg-req-102/203 — transfer basis per destination |
| EHDS | European data sovereignty alignment; convergence layer keeps health-adjacent data in-region by default
|
| NIS2 | zone model + egress control at critical-infrastructure operators |
| Normen (NO) | applies when Norwegian deployments activate; profile to be defined with NHN (on hold per 2026-08-11 decision) |