Specification Modules

# FILE: spec/part-03-information-model/INFORMATION-MODEL.yaml
# =====================================================================
# Rocom — Part 3: Information Model
# Status: ADOPTED 1.0, Edition 2026a
# License: CC-BY 4.0 (see LICENSE-SPEC)
# Scope: Core data types referenced by Parts 4, 5, 6, 7.
#        Contracts and profiles MUST use these types verbatim.
#
# Correction proposals incorporated:
#   CP-007 — Agent Identity Model (issuer-agnostic, UDI-aligned)
#     Status: MERGED. See spec/cp-007-agent-identity.md
#   CP-008 — Resource Authority Model
#     Status: MERGED. See spec/cp-008-resource-authority.md
#   CP-009 — Priority and Preemption Model
#     Status: MERGED. See spec/cp-009-priority-preemption.md
#
# Coordinated amendments (Part 2 revision, control-plane service levels):
#   Location model extended with namespace/identifier (cpl-req-801).
#   See spec/part-02-conformance/SERVICE-LEVELS.md §14.1
# =====================================================================

module: information-model
part: 3
version: 1.0
edition: 2026a

# ====================================================================
# Agent — the canonical agent record (Part 4, Part 5)
# CP-007 incorporated: agent_identity replaces flat agent_id/hr_ref model
# ====================================================================
agent:
  description: >
    Any entity allocatable to tasks: human staff, robot, or
    human-in-the-loop operator station.
  required_fields:
    - agent_identity
    - agent_type
    - availability_status
  fields:
    agent_id:
      type: string
      description: >
        Deprecated (CP-007). Use agent_identity instead.
        Retained for backward compatibility; must be derived from
        agent_identity.production_identifier.serial_number when present,
        to ensure unique individual identification. Deriving from
        access_key alone is insufficient — access_key identifies the
        agent type, not the individual unit.
      example: "robot-EVE-001"
    agent_identity:
      description: >
        Three-layer identity model (CP-007). access_key identifies
        the agent type (stable across versions and units).
        device_identifier identifies the configuration/version.
        production_identifier identifies the individual unit.
        Each layer declares its issuing_entity; implementations
        MUST NOT require all layers to share the same issuer.
      type: object
      required_fields:
        - access_key
        - device_identifier
        - production_identifier
      fields:
        access_key:
          type: object
          description: >
            Canonical lookup key for the agent type. Stable across
            software versions, configuration changes, and individual
            units of the same model. Used for type-level addressing.
          required_fields:
            - issuing_entity
            - value
          fields:
            issuing_entity:
              type: string
              enum: [gs1, hibcc, iccbba, ifa, vda5050, internal]
              description: >
                Entity that issued this identifier. gs1, hibcc, iccbba,
                and ifa are the EU-designated UDI issuers (Decision 2019/939).
                vda5050 denotes identity from VDA 5050 factsheet.
                internal denotes operating-organisation assignment.
                Implementations MUST treat this enumeration as extensible.
              example: "internal"
            value:
              type: string
              description: >
                Basic UDI-DI where regulated; otherwise a stable
                manufacturer+model key.
              example: "EVE-transport-2026"
        device_identifier:
          type: object
          description: >
            Identifies the specific device configuration. Changes
            when software version or capabilities change.
          required_fields:
            - issuing_entity
            - value
          fields:
            issuing_entity:
              type: string
              enum: [gs1, hibcc, iccbba, ifa, vda5050, internal]
              description: Entity that issued this identifier.
              example: "gs1"
            value:
              type: string
              description: Configuration/version-bearing identifier.
              example: "SN-2026-EVE-00142"
            software_version:
              type: string
              description: Optional, informative version string.
              required: false
              example: "2.1.0"
        production_identifier:
          type: object
          description: >
            Identifies the individual unit. When the agent
            communicates over VDA 5050, serial_number carries
            the VDA 5050 serialNumber value verbatim.
          required_fields:
            - serial_number
          fields:
            serial_number:
              type: string
              description: VDA 5050 serialNumber verbatim.
              example: "EVE-00142"
            manufacture_date:
              type: string
              format: date
              description: Optional manufacture date.
              required: false
        regulatory:
          type: object
          description: >
            Present only when the agent is a regulated medical
            device under MDR (EU) 2017/745 or IVDR (EU) 2017/746.
            Absence of this block MUST NOT be interpreted as a
            claim of regulatory status.
          required: false
          fields:
            basic_udi_di:
              type: string
              description: Basic UDI-DI per MDR/IVDR.
            udi_di:
              type: string
              description: UDI-DI for the specific device configuration.
            eudamed_registered:
              type: boolean
              description: Whether the device is registered in EUDAMED.
    agent_type:
      type: string
      enum: [human, robot, cockpit]
      description: Agent category. Determines applicable allocation rules.
    hr_ref:
      type: string
      description: >
        Deprecated (CP-007). Reference to HR system record
        (employee ID or serial number). For robots, use
        agent_identity.production_identifier.serial_number (individual
        unit). For humans, use production_identifier from workforce
        system. device_identifier is for configuration/version — not
        for individual identification.
      required: false
    provider_id:
      type: string
      description: Source provider that registered this agent.
      example: "columna-flow-rigshospitalet"
    availability_status:
      type: string
      enum: [available, busy, unavailable, scheduled_absent]
    current_location:
      type: location
      required: false

# ====================================================================
# Capability (Part 5)
# ====================================================================
capability:
  description: A structured declaration of what an agent can do.
  fields:
    capability_id:
      type: string
      description: Key matching an entry in the capability registry (Part 5).
      example: "transport.meal"
    name:
      type: string
      example: "Meal transport between wards"
    level:
      type: string
      enum: [basic, intermediate, expert]
      description: >
        Proficiency level. 'basic' covers standard operation.
        'intermediate' adds contextual adaptation. 'expert'
        covers supervised autonomous operation in complex
        environments. Note: Part 5 capability registry uses
        the same values; 'advanced' and 'certified' are not
        standard capability levels.
    certified:
      type: boolean
      description: Whether the capability has passed certification testing.
      default: false
    constraints:
      type: array
      items: string
      required: false

# ====================================================================
# Time Window (Part 4)
# ====================================================================
time_window:
  description: A scheduled availability period.
  fields:
    start:
      type: string
      format: date-time
    end:
      type: string
      format: date-time
    status:
      type: string
      enum: [available, unavailable]
    recurrence:
      type: string
      description: "RRULE or 'none'"
      required: false

# ====================================================================
# Location (Part 4, Part 5)
# Extended: namespace/identity model per cpl-req-801, 803
# Backward compat: ward_or_zone retained as deprecated
# ====================================================================
location:
  description: >
    Physical place within a deployment. The namespace/identifier pair
    provides stable identity (cpl-req-801, 803). Name, hierarchy, and
    coordinates are informational. State is carried separately.
  required_fields:
    - namespace
    - identifier
  fields:
    namespace:
      type: string
      description: >
        The identification system or registry that defines the
        identifier format and scope. Examples: GS1, internal,
        vda5050, uniclass, operator-defined.
      example: "GS1"
    identifier:
      type: string
      description: >
        The value unique within its namespace. Does not change
        with state or occupancy (cpl-req-803).
      example: "701234567890123"
    name:
      type: string
      description: >
        Human-readable label. Locale-dependent. SHALL NOT serve
        as the sole basis for automated identification (cpl-req-804).
      required: false
      example: "Pharmacy receiving area"
    parent:
      type: string
      description: >
        Reference to the containing location (format: namespace:identifier).
        Supports hierarchy: building → floor → ward → room.
      required: false
      example: "internal:urn:facility:pharmacy"
    ward_or_zone:
      type: string
      description: >
        DEPRECATED. Preserved for backward compatibility with
        existing Part 4 contracts. New implementations SHALL use
        namespace and identifier.
      required: false
      example: "Ward 3B"
    coordinates:
      type: object
      required: false
      description: Position within a spatial reference frame.
      properties:
        x: { type: number }
        y: { type: number }
        map_id: { type: string }

# ====================================================================
# Resource Authority — shared resource access (CP-008)
# ====================================================================
resource_authority:
  description: >
    Explicit model of shared resources agents compete for:
    space, doors, lifts, docks, and tasks. Grants are
    time-bound with explicit release and capacity modeling.
    Agents that lose contact have defined obligations.
  required_fields:
    - resource_id
    - resource_type
    - grant_holders
  fields:
    resource_id:
      type: string
      description: Unique identifier for the shared resource.
      example: "door-3B-01"
    resource_type:
      type: string
      enum: [door, lift, dock, zone, task]
      description: Type of shared resource.
    capacity:
      type: integer
      description: >
        Maximum concurrent holders. 1 for exclusive resources
        (doors). >1 for shared resources (lifts).
      default: 1
    grant_holders:
      type: array
      items: object
      description: >
        Current agents holding access grants. Each grant has
        an explicit lifetime with expiry.
      properties:
        agent_id:
          type: string
          description: Agent holding this grant.
        granted_at:
          type: string
          format: date-time
        expires_at:
          type: string
          format: date-time
          description: >
            Grant expiry. Grants MUST expire — no indefinite
            grants. Agent must explicitly release or request
            renewal before expiry.
    communication_loss_policy:
      type: string
      enum: [auto_release, hold_until_timeout, escalate]
      description: >
        Behavior when grant holder loses contact.
        'auto_release' releases immediately.
        'hold_until_timeout' holds for a configurable period.
        'escalate' notifies orchestrator for manual resolution.
      default: hold_until_timeout

# ====================================================================
# Cost Model (Part 4)
# ====================================================================
cost_model:
  description: How the orchestrator prices using an agent for a task.
  fields:
    base_cost_per_minute:
      type: number
      description: "Cost in EUR, normalized."
    min_engagement_minutes:
      type: number
    cost_factors:
      type: array
      items: object
      required: false
      description: >
        Arbitrary cost modifiers (e.g., time-of-day,
        location-based, regulatory). Structure is
        implementation-defined.
      properties:
        factor_id:
          type: string
          description: Identifier for this factor.
        weight:
          type: number
          description: Multiplicative weight.
        applies_when:
          type: string
          description: Human-readable condition.

# ====================================================================
# Task (Part 4)
# ====================================================================
task:
  description: A unit of work to be allocated to an agent.
  required_fields:
    - task_id
    - description
    - required_capability
    - priority
  fields:
    task_id:
      type: string
      format: uuid
    description:
      type: string
    required_capability:
      type: string
      description: Capability key matching the capability registry.
    priority:
      type: string
      enum: [immediate, expedited, routine, deferred]
      description: >
        Priority level (CP-009). 'immediate' for life-safety
        tasks. 'expedited' for time-critical but non-emergency.
        'routine' for standard operations. 'deferred' for
        background work. Replaces numeric 0–9 scale; numeric
        values are implementation-specific and must map to
        these levels.
      default: routine
    priority_origin:
      type: string
      description: >
        Entity authorized to set this priority (CP-009).
        Only the clinical lead, BMS (fire/evacuation), or
        orchestrator (system policy) may set 'immediate'.
      required: false
    status:
      type: string
      enum: [pending, assigned, in_progress, completed, cancelled]
      default: pending
    assigned_agent_id:
      type: string
      required: false
    zone:
      type: string
      required: false
    constraints:
      type: array
      items: string
      required: false

# ====================================================================
# Data Profile (Part 7)
# ====================================================================
data_profile:
  description: >
    What data classes an agent delivers, where, and on what basis.
    Required for robots; optional for human agents.
  required_fields:
    - data_classes_delivered
    - declared_destinations
  fields:
    data_classes_delivered:
      type: array
      items: string
      description: "From data class taxonomy (Part 7): operational_telemetry, diagnostic, sensor_payload, personal_data"
    declared_destinations:
      type: array
      items: destination
    gdpr_article:
      type: string
      enum: [6_1_f, 6_1_a, 9_2_h, 9_2_a, none]
      description: "Processing basis for Art. 9 data."
      default: none

# ====================================================================
# Declared Destination (Part 7)
# ====================================================================
destination:
  description: Where data is transferred and under what basis.
  required_fields:
    - destination_id
    - system_name
    - location
    - lawful_basis
  fields:
    destination_id:
      type: string
    system_name:
      type: string
    location:
      type: string
      example: "hospital-internal"
    lawful_basis:
      type: string
      enum: [adequacy, sccs, bcrs, explicit_consent, legal_obligation, none]
    description:
      type: string
      required: false

# ====================================================================
# Compliance Event (Part 5, Healthcare profile)
# ====================================================================
compliance_event:
  description: Published on zone transitions (Part 5, rocom/v0/compliance/event).
  required_fields:
    - event_id
    - task_id
    - agent_id
    - zone
    - event_type
    - compliance_status
    - audit_correlation_id
  fields:
    event_id:
      type: string
      format: uuid
    task_id:
      type: string
      format: uuid
    agent_id:
      type: string
      format: uuid
    zone:
      type: string
    event_type:
      type: string
      enum: [zone_entry, zone_exit, restricted_zone_check, chain_of_custody]
    compliance_status:
      type: string
      enum: [passed, failed, exception]
      description: REQUIRED per Part 5 (P-2.2.4).
    audit_correlation_id:
      type: string
      format: uuid
      description: REQUIRED per Part 5 (P-2.2.2). Links to orchestrator audit trail.

# ====================================================================
# Chain of Custody Event (Part 5, Healthcare profile — any level)
# ====================================================================
chain_of_custody_event:
  description: >
    Published on rocom/v0/chainOfCustody/event for tasks
    requiring chain-of-custody tracking. Healthcare profile
    requirement (any level, not L3-only).
  required_fields:
    - event_id
    - task_id
    - item_type
    - agent_id
    - action
    - timestamp
    - audit_correlation_id
  fields:
    event_id:
      type: string
      format: uuid
    task_id:
      type: string
      format: uuid
    item_type:
      type: string
      enum: [medication, sample, meal, waste, linen]
    agent_id:
      type: string
      format: uuid
    action:
      type: string
      enum: [picked_up, in_transit, delivered, handed_off]
    custody_signature:
      type: string
      description: Cryptographic hash of custody state.
      required: false
    timestamp:
      type: string
      format: date-time
    audit_correlation_id:
      type: string
      format: uuid
      description: >
        REQUIRED per Part 5. Links to orchestrator audit trail
        for end-to-end chain-of-custody traceability.

# FILE: availability_provider_contract.yaml
# Availability Provider Contract — Rocom v0.2
# Defines the interface any workforce data source must implement
# to feed agent availability into the orchestrator cross-allocation engine.
#
# Coordinated with Part 2 revision (control-plane service levels).
# L0-L3 conformance aligned to SERVICE-LEVELS v1.0 §3.3 Workforce plane.
# agent_id deprecated in favor of agent_identity (CP-007).
# location extended with namespace/identifier (Part 3 amendment).
#
# Implementations:
#   - rocom-core/src/providers/columna_flow.rs  (Columna Flow API)
#   - rocom-core/src/providers/gat.rs            (GAT/MinGat — Norwegian municipalities)
#   - rocom-core/src/providers/workday.rs        (Workday enterprise HR)
#   - rocom-core/src/providers/rocom_fleet.rs    (Rocom robot fleet — always present)

contract:
  name: "Availability Provider Interface"
  version: "1.0.0"
  description: >-
    Source-agnostic contract for feeding human and robot agent availability
    into the orchestrator cross-allocation engine. Any workforce system (Columna Flow,
    GAT, Workday, Rocom fleet) implements this contract to become an availability
    provider. The engine normalizes all sources to the unified Agent model.

  required_fields:
    # --- Identity ---
    - name: agent_id
      type: "String (UUID or system-native ID)"
      description: "Unique identifier for the agent. Must be stable across availability updates."
      example: '"staff-42" eller "robot-EVE-001"'

    - name: agent_type
      type: "Enum { human, robot, cockpit }"
      description: "Agent category. Determines which allocation rules apply."
      example: "human"

    - name: provider_id
      type: "String"
      description: "Identifier of the provider implementation supplying this data."
      example: '"columna-flow-rigshospitalet" eller "gat-oslo-kommune"'

    # --- Capabilities ---
    - name: capabilities
      type: "Array[Capability]"
      description: "What this agent can do. Used for task-to-agent matching."
      schema:
        Capability:
          capability_id: "String"
          name: "String"
          level: "Enum { basic, intermediate, expert }"
          constraints: "Optional[String]"
      example: >-
        [{ capability_id: "transport", name: "Transport items between wards", level: "basic" },
         { capability_id: "patient_assist", name: "Patient assistance", level: "expert",
           constraints: "requires_certification_nurse" }]

    # --- Availability ---
    - name: availability_status
      type: "Enum { available, busy, unavailable, scheduled_absent }"
      description: "Current availability for task allocation."
      example: "available"

    - name: availability_windows
      type: "Array[TimeWindow]"
      description: "Scheduled availability periods for planning. Empty array = on-demand."
      schema:
        TimeWindow:
          start: "ISO 8601 datetime"
          end: "ISO 8601 datetime"
          status: "Enum { available, unavailable }"
          recurrence: "Optional[String] — RRULE or 'none'"
      example: >-
        [{ start: "2026-08-11T06:00:00+02:00", end: "2026-08-11T14:00:00+02:00",
           status: "available", recurrence: "FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR" }]

    - name: current_location
      type: "Optional[Location]"
      schema:
        Location:
          ward_or_zone: "String"
          coordinates: "Optional[{ x: Float, y: Float, map_id: String }]"
      example: { ward_or_zone: "Ward 3B", coordinates: { x: 12.5, y: 8.3, map_id: "map-floors1-3" } }

    # --- Cost Model ---
    - name: cost_model
      type: "CostModel"
      description: "How the allocation engine prices using this agent for a task."
      schema:
        CostModel:
          base_cost_per_minute: "Float (in EUR, normalized)"
          min_engagement_minutes: "Float (minimum dispatch duration)"
          cost_factors: "Optional[Array[CostFactor]] — arbitrary cost modifiers; implementation-defined structure"
        CostFactor:
          factor_id: "String — identifier for this factor"
          weight: "Float — multiplicative weight"
          applies_when: "String — human-readable condition"
      example: >-
        { base_cost_per_minute: 0.85,
          min_engagement_minutes: 15,
          cost_factors: [{ factor_id: "overtime", weight: 1.5, applies_when: "outside availability windows" }] }

    # --- Compliance ---
    - name: compliance_flags
      type: "Array[String]"
      description: "Regulatory or collective agreement flags affecting allocation."
      example: >-
        ["requires_union_consultation_for_robot_replacement",
         "gdpr_workforce_data_source_consent",
         "eu_cra_class_b_robot"]

    # --- Data Profile ---
    # Minimal declaration: what data classes this agent delivers, where, and on what basis.
    # Full sensor inventory belongs in the data-governance module, not the provider contract.
    # Required for robots; optional for human agents.
    - name: data_profile
      type: "DataProfile (optional for humans, required for robots)"
      description: "Minimal data governance declaration per agent: data classes delivered, declared destinations, lawful transfer basis. Enables real-time Art. 30 register from the agent registry. Full sensor inventory managed by data-governance module."
      schema:
        DataProfile:
          data_classes_delivered: "Array[String] — from data class taxonomy: operational_telemetry, diagnostic, sensor_payload, personal_data"
          declared_destinations: "Array[Destination]"
          Destination:
            destination_id: "String"
            system_name: "String"
            location: "String (e.g., 'EU', 'US-East', 'hospital-internal')"
            lawful_basis: "Enum { adequacy, sccs, bcrs, explicit_consent, legal_obligation, none }"
            description: "Optional[String]"
          gdpr_article: "Enum { 6_1_f, 6_1_a, 9_2_h, 9_2_a, none } — processing basis for Art. 9 data"
      example: >-
        { data_classes_delivered: ["operational_telemetry", "diagnostic", "sensor_payload"],
           declared_destinations: [
             { destination_id: "rocom-orchestrator-internal", system_name: "Agent Registry",
               location: "hospital-internal", lawful_basis: "legal_obligation" },
             { destination_id: "vendor-cloud-eu", system_name: "Vendor Fleet Telemetry",
               location: "EU", lawful_basis: "sccs", description: "Battery diagnostics only" }
           ],
           gdpr_article: "9_2_h" }

  events:
    # Push model: provider emits these events to the orchestrator
    - name: agent.registered
      description: "New agent becomes known to the system."
      payload: "All required_fields"

    - name: agent.availability_changed
      description: "Agent availability status or windows changed."
      payload:
        - agent_id
        - availability_status
        - availability_windows
        - current_location
        - timestamp

    - name: agent.capabilities_updated
      description: "Agent capability profile changed (training, firmware update, reassignment)."
      payload:
        - agent_id
        - capabilities
        - timestamp

    - name: agent.deregistered
      description: "Agent removed from the system (offboarding, decommissioning)."
      payload:
        - agent_id
        - reason
        - timestamp

  polling_alternative:
    description: "Providers that cannot push may poll via REST endpoint."
    endpoint: "GET /api/v1/agents/{agent_id}/availability"
    response: "All required_fields for the requested agent"
    rate_limit: "10 req/min per provider"

  conformance_levels:
    # Aligned to Part 2 control-plane service levels (cpl-req-301, 302, 303)
    - level: "L1"
      name: "Static integration"
      requirement: >-
        Provider supplies agent_identity (CP-007), agent_type, declared
        capabilities, configured availability and allocation constraints.
        Supports predefined allocation and explicit acceptance or refusal.
        Location references carry namespace (cpl-req-801).
        Sufficient for on-demand allocation with no advance planning.
      example_implementations: ["Simple robot fleet adapter", "Manual availability form"]

    - level: "L2"
      name: "State-aware coordination"
      requirement: >-
        L1 + availability_windows (with recurrence), capability changes,
        current_location (extended location type with namespace/identifier).
        Availability, eligibility, and workload changes are reflected within
        service-quality bounds. Predefined allocation policies use current state.
        Enables shift planning and capability-based task matching.
      example_implementations: ["Columna Flow Task Management", "GAT/MinGat", "Workday"]

    - level: "L3"
      name: "Fully dynamic coordination"
      requirement: >-
        L2 + compliance_flags, real-time push events, dynamic offers,
        acceptance/refusal, release and reassignment. Respects competence,
        working-time constraints, consent, and reserved human decisions.
        A person may decline; L3 handles that outcome dynamically.
        Enables fully automated cross-allocation with compliance verification.
      example_implementations: ["Columna Flow + Rocom adapter", "GAT + Rocom fleet integration"]

# ============================================================
# AsyncAPI Skisse — Event-driven provider interface
# ============================================================
  asyncapi_sketch: |
    asyncapi: 3.0.0
    info:
      title: Rocom Availability Provider Interface
      version: 0.1.0
      description: >-
        Event-driven contract for feeding agent availability data into the orchestrator
        cross-allocation engine. Any workforce system implements this to become
        an availability provider.
  
    channels:
      availability.events:
        description: "Agent availability events — push model"
        messages:
          AgentRegistered:
            name: AgentRegistered
            payload:
              type: object
              required: [event_type, agent_id, agent_type, provider_id, capabilities, availability_status, cost_model, compliance_flags]
              properties:
                event_type:
                  type: string
                  const: agent.registered
                agent_id:
                  type: string
                  format: uuid
                agent_type:
                  type: string
                  enum: [human, robot, cockpit]
                provider_id:
                  type: string
                capabilities:
                  type: array
                  items:
                    type: object
                    properties:
                      capability_id: { type: string }
                      name: { type: string }
                      level: { type: string, enum: [basic, intermediate, expert] }
                availability_status:
                  type: string
                  enum: [available, busy, unavailable, scheduled_absent]
                availability_windows:
                  type: array
                  items:
                    type: object
                    properties:
                      start: { type: string, format: date-time }
                      end: { type: string, format: date-time }
                      status: { type: string, enum: [available, unavailable] }
                cost_model:
                  type: object
                  properties:
                    base_cost_per_minute: { type: number }
                    min_engagement_minutes: { type: number }
                    cost_factors:
                      type: array
                      items:
                        type: object
                        properties:
                          factor_id: { type: string }
                          weight: { type: number }
                          applies_when: { type: string }
                compliance_flags:
                  type: array
                  items: { type: string }
                timestamp:
                  type: string
                  format: date-time
  
          AvailabilityChanged:
            name: AvailabilityChanged
            payload:
              type: object
              required: [event_type, agent_id, availability_status, timestamp]
              properties:
                event_type:
                  type: string
                  const: agent.availability_changed
                agent_id: { type: string, format: uuid }
                availability_status:
                  type: string
                  enum: [available, busy, unavailable, scheduled_absent]
                availability_windows:
                  type: array
                current_location:
                  type: object
                  properties:
                    ward_or_zone: { type: string }
                    coordinates:
                      type: object
                      properties:
                        x: { type: number }
                        y: { type: number }
                        map_id: { type: string }
                timestamp: { type: string, format: date-time }
  
          CapabilitiesUpdated:
            name: CapabilitiesUpdated
            payload:
              type: object
              required: [event_type, agent_id, capabilities, timestamp]
              properties:
                event_type:
                  type: string
                  const: agent.capabilities_updated
                agent_id: { type: string, format: uuid }
                capabilities:
                  type: array
                timestamp: { type: string, format: date-time }
  
          AgentDeregistered:
            name: AgentDeregistered
            payload:
              type: object
              required: [event_type, agent_id, reason, timestamp]
              properties:
                event_type:
                  type: string
                  const: agent.deregistered
                agent_id: { type: string, format: uuid }
                reason: { type: string }
                timestamp: { type: string, format: date-time }
  
    operations:
      publishAvailability:
        action: send
        channel:
          $ref: '#/channels/availability.events'
        messages:
          - $ref: '#/channels/availability.events/messages/AgentRegistered'
          - $ref: '#/channels/availability.events/messages/AvailabilityChanged'
          - $ref: '#/channels/availability.events/messages/CapabilitiesUpdated'
          - $ref: '#/channels/availability.events/messages/AgentDeregistered'

# FILE: part-04-services/task_source_contract.yaml
# Task Source Contract — Rocom v0.2
# Defines the interface any task-generating system must implement
# to feed work requests into the orchestrator allocation engine.
#
# Coordinated with Part 2 revision (control-plane service levels).
# L0-L3 conformance aligned to SERVICE-LEVELS v1.0 §3.4 Task plane.
# zone extended with namespace/identifier (Part 3 amendment).
#
# Implementations:
#   - Management system allocation engine receives tasks via POST /tasks (Sup-001)
#   - Enterprise ERP systems (SAP, columna) as task sources
#   - BMS-generated maintenance tasks
#   - Manual task entry via cockpit interface

contract:
  name: "Task Source Interface"
  version: "1.0.0"
  description: >-
    Source-agnostic contract for feeding task requests into the orchestrator
    allocation engine. Any enterprise system (ERP, BMS, turnus, manual entry)
    implements this contract to become a task source. The orchestrator normalizes
    all sources to the unified Task model (Part 3).

  required_fields:
    # --- Identity ---
    - name: task_id
      type: "String (UUID)"
      description: "Unique identifier for the task. Generated by the task source or orchestrator."
      example: '"task-4a8b2c1d-..."'

    - name: description
      type: "String"
      description: "Human-readable task description."
      example: '"Transport medication from pharmacy to Ward 3B"'

    - name: required_capability
      type: "String"
      description: "Capability key matching the capability registry (Part 5)."
      example: '"transport.medication"'

    - name: priority
      type: "Enum { immediate, expedited, routine, deferred }"
      description: "Priority level per Part 3 (CP-009). 'immediate' for life-safety. 'expedited' for time-critical. 'routine' is the default. 'deferred' for scheduled/background work."
      example: "routine"

    - name: source_id
      type: "String"
      description: "Identifier of the task source system generating this request."
      example: '"sap-erp-rigshospitalet" eller "bms-maintenance"'

    # --- Execution ---
    - name: status
      type: "Enum { pending, assigned, in_progress, completed, cancelled }"
      description: "Current task status. Task sources create tasks as pending."
      example: "pending"

    - name: assigned_agent_id
      type: "Optional[String]"
      description: "Agent assigned to this task by the orchestrator. Null for pending tasks."
      example: '"robot-EVE-001"'

    - name: zone
      type: "Optional[String]"
      description: "Target ward/zone (Part 3 Location model)."
      example: '"Ward 3B"'

    - name: constraints
      type: "Optional[Array[String]]"
      description: "Operational constraints (e.g., 'restricted_zones: true', 'chain_of_custody: required')."
      example: '["chain_of_custody: required", "temperature_range: 2-8C"]'

    - name: deadline
      type: "Optional[DateTime]"
      description: "Latest completion time (ISO 8601)."
      example: '"2026-09-15T14:00:00+02:00"'

    - name: chain_of_custody
      type: "Optional[Boolean]"
      description: "Whether chain-of-custody tracking is required. Healthcare profile requirement at any level (not L3-only)."
      example: "true"

    # --- Compliance ---
    - name: compliance_flags
      type: "Optional[Array[String]]"
      description: "Regulatory flags affecting task execution."
      example: '["gdpr_chain_of_custody", "eu_cra_class_b"]'

  events:
    # Push model: task source emits these events to the orchestrator
    - name: task.created
      description: "New task submitted to the orchestrator."
      payload: "All required_fields"

    - name: task.updated
      description: "Task modified (priority change, deadline extension, constraints added)."
      payload:
        - task_id
        - description
        - priority
        - constraints
        - deadline
        - timestamp

    - name: task.cancelled
      description: "Task cancelled by the originating source before assignment."
      payload:
        - task_id
        - reason
        - timestamp

  polling_alternative:
    description: "Task sources that cannot push may use the orchestrator REST API."
    endpoint: "POST /tasks"
    request_body: "All required_fields"
    response: "task_id, status: accepted, assigned_agent_id (if auto-assigned)"
    rate_limit: "50 req/min per source"

  conformance_levels:
    # Aligned to Part 2 control-plane service levels (cpl-req-401, 402, 403)
    - level: "L1"
      name: "Static integration"
      requirement: >-
        Source provides task_id, description, required_capability, priority
        (CP-009 values with authorised origin), origin/destination location
        references (namespace declared per cpl-req-801). Standardised task
        submissions with lifecycle outcomes. Predefined assignment rules may
        be used. Sufficient for on-demand allocation.
      example_implementations: ["Manual cockpit entry", "Simple script"]

    - level: "L2"
      name: "State-aware coordination"
      requirement: >-
        L1 + deadline, constraints, zone (extended location type), task
        progress, authorised amendments, cancellations and exceptions within
        service-quality bounds. Predefined responses account for deadlines,
        readiness, dependencies and evidence requirements. Acceptance,
        execution and completion remain distinct states. Enables planned
        allocation with zone-restricted and chain-of-custody tasks.
      example_implementations: ["SAP ERP production orders", "Columna Flow task management"]

    - level: "L3"
      name: "Fully dynamic coordination"
      requirement: >-
        L2 + chain_of_custody, compliance_flags, real-time push events,
        event-driven reevaluation and coordinated reassignment/replanning
        when needs or dependencies change. Preserves CP-009 priority origin
        and preemption restrictions, CP-008 resource authority and applicable
        chain-of-custody. Enables fully automated allocation with compliance
        verification.
      example_implementations: ["SAP + Rocom adapter", "BMS maintenance integration"]

# ============================================================
# AsyncAPI Skisse — Event-driven task source interface
# ============================================================
  asyncapi_sketch: |
    asyncapi: 3.0.0
    info:
    title: Rocom Task Source Interface
    version: 0.1.0
    description: >-
      Event-driven contract for submitting tasks to the orchestrator
      allocation engine. Any enterprise system implements this to become
      a task source.

    channels:
    tasks.events:
      description: "Task events — push model"
      messages:
        TaskCreated:
          name: TaskCreated
          payload:
            type: object
            required: [event_type, task_id, description, required_capability, priority, source_id]
            properties:
              event_type:
                type: string
                const: task.created
              task_id:
                type: string
                format: uuid
              description:
                type: string
              required_capability:
                type: string
              priority:
                type: string
                enum: [immediate, expedited, routine, deferred]
                default: routine
              source_id:
                type: string
              status:
                type: string
                enum: [pending, assigned, in_progress, completed, cancelled]
                default: pending
              zone:
                type: string
              constraints:
                type: array
                items: { type: string }
              deadline:
                type: string
                format: date-time
              chain_of_custody:
                type: boolean
              compliance_flags:
                type: array
                items: { type: string }
              timestamp:
                type: string
                format: date-time

        TaskUpdated:
          name: TaskUpdated
          payload:
            type: object
            required: [event_type, task_id, timestamp]
            properties:
              event_type:
                type: string
                const: task.updated
              task_id: { type: string, format: uuid }
              description: { type: string }
              priority:
                type: string
                enum: [immediate, expedited, routine, deferred]
              constraints:
                type: array
                items: { type: string }
              deadline:
                type: string
                format: date-time
              timestamp: { type: string, format: date-time }

        TaskCancelled:
          name: TaskCancelled
          payload:
            type: object
            required: [event_type, task_id, reason, timestamp]
            properties:
              event_type:
                type: string
                const: task.cancelled
              task_id: { type: string, format: uuid }
              reason: { type: string }
              timestamp: { type: string, format: date-time }

    operations:
    publishTask:
      action: send
      channel:
        $ref: '#/channels/tasks.events'
      messages:
        - $ref: '#/channels/tasks.events/messages/TaskCreated'
        - $ref: '#/channels/tasks.events/messages/TaskUpdated'
        - $ref: '#/channels/tasks.events/messages/TaskCancelled'

# FILE: specs/rocom-profile/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
    compliance:
      - gdpr: false
      - cyber_resilience_act: true
      - restricted_zones: true

  transport.sample:
    label: Sample Transport
    description: >
      Transport of laboratory samples requiring biohazard classification
      and chain-of-custody integrity.
    params:
      biohazardLevel:
        type: string
        enum: [none, low, medium, high]
        default: low
      chainOfCustody:
        type: boolean
        default: true
    compliance:
      - gdpr: false
      - cyber_resilience_act: true
      - restricted_zones: true

  transport.meal:
    label: Meal Transport
    description: >
      Transport of patient meals with temperature maintenance and
      delivery-time guarantees.
    params:
      temperatureRange:
        type: object
        properties:
          min: { type: number, unit: celsius }
          max: { type: number, unit: celsius }
        default:
          min: 60
          max: 75
      deliveryTimeMax:
        type: integer
        unit: minutes
        default: 30
    compliance:
      - gdpr: false
      - cyber_resilience_act: true
      - restricted_zones: false

  cleaning.floor:
    label: Floor Cleaning
    description: Automated floor cleaning in corridors and public areas.
    params:
      cleaningMethod:
        type: string
        enum: [dry, wet, disinfectant]
        default: wet
      areaType:
        type: string
        enum: [corridor, ward, public, operating_theatre_ante]
    compliance:
      - gdpr: false
      - cyber_resilience_act: true
      - restricted_zones: false

  cleaning.uv:
    label: UV Disinfection
    description: >
      Autonomous UV-C disinfection cycles in isolated rooms.
      Requires zone lockdown verification before activation.
    params:
      uvWavelength:
        type: integer
        unit: nm
        default: 254
      cycleDuration:
        type: integer
        unit: minutes
        default: 30
      zoneLockdownRequired:
        type: boolean
        default: true
    compliance:
      - gdpr: false
      - cyber_resilience_act: true
      - restricted_zones: true

  delivery.linen:
    label: Linen Delivery
    description: Transport of clean or soiled linen between laundry and wards.
    params:
      linenType:
        type: string
        enum: [clean, soiled]
        default: clean
      loadCapacity:
        type: integer
        unit: kg
        default: 50
    compliance:
      - gdpr: false
      - cyber_resilience_act: true
      - restricted_zones: false

  delivery.waste:
    label: Waste Delivery
    description: >
      Transport of general or clinical waste to disposal areas.
      Segregation of hazardous waste requires certified capability level.
    params:
      wasteType:
        type: string
        enum: [general, clinical, hazardous]
        default: general
      containerType:
        type: string
        enum: [bin, trolley, sharps]
    compliance:
      - gdpr: false
      - cyber_resilience_act: true
      - restricted_zones: true

• Deployment-profile parameters for dk-region-hovedstaden
• Trust-domain federation (multi-region) — deferred to a later edition
• Formal IEC 62443 mapping — pending third-party assessment

# FILE: spec/part-06-security/identity-trust.yaml
# =====================================================================
# Rocom — Part 6: Security (Identity & Trust)
# Status: ADOPTED 1.0, Edition 2026a
# License: CC-BY 4.0 (see LICENSE-SPEC)
# Scope: Machine identity (non-human identity, NHI) and trust
#        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)
# NOTE:  Parameters marked PENDING-DEPLOYMENT-PROFILE are set per
#        deployment profile, not by this specification.
# =====================================================================

module: identity-trust
part: 6
version: 1.0
edition: 2026a

terminology:
  orchestrator: >
    The system implementing the orchestration layer of this standard
    (see Part 1); responsible for task allocation, the agent registry
    and the audit trail.

principles:
  - id: it-p-001
    statement: >
      Every non-human agent (robot, adapter, provider, connector) MUST
      hold a verifiable machine identity. No anonymous participants at
      the IT/OT boundary.
  - id: it-p-002
    statement: >
      Identity lifecycle is bound to agent lifecycle: onboarding of an
      agent implies identity issuance; offboarding implies revocation.
  - id: it-p-003
    statement: >
      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.
  - id: it-p-004
    statement: >
      All identity events (issuance, rotation, revocation, failed
      authentication) MUST be written to the orchestrator's immutable
      audit trail.

identity_model:
  id_format: SPIFFE-compatible URI
  example: "spiffe://<trust-domain>/agent/<agent-type>/<agent-id>"
  trust_domain: >
    One trust domain per deployment (hospital or municipality).
    Federation between trust domains is out of scope for this edition.
  credential: X.509 SVID (certificate binding the SPIFFE ID)
  registry_binding: >
    The orchestrator's agent registry is the authoritative mapping
    between agent record and SPIFFE ID. An agent without a registry
    entry MUST NOT be issued a credential.

transport_bindings:
  - binding: fleet binding (VDA 5050 / MQTT — see Part 5)
    requirement: mTLS 1.2+; client certificate = agent SVID
  - binding: orchestrator service interfaces (HTTP)
    requirement: TLS 1.2+; client authentication per conformance level
  - binding: availability-provider / task-source contracts (see Part 4)
    requirement: mTLS between connector and provider endpoint

requirements:
  # ---- Level 1 — pilot / lab ----------------------------------------
  - id: it-req-001
    level: L1
    statement: Every agent presents a unique X.509 client certificate.
    verification: conformance test ID-01 (shared certificates rejected)
  - id: it-req-002
    level: L1
    statement: Static certificates permitted; maximum validity 24 months.
    verification: certificate inspection
  - id: it-req-003
    level: L1
    statement: >
      Manual revocation supported: a revoked agent is denied within
      one operational day.
    verification: conformance test ID-02
  - id: it-req-004
    level: L1
    statement: Identity events logged to the audit trail (it-p-004).
    verification: audit log inspection

  # ---- Level 2 — production, single site ----------------------------
  - id: it-req-101
    level: L2
    statement: >
      Certificate rotation without service interruption. Maximum
      validity: PENDING-DEPLOYMENT-PROFILE (reference value: 90 days).
    verification: conformance test ID-10
  - id: it-req-102
    level: L2
    statement: >
      Revocation propagated to all brokers/endpoints within
      PENDING-DEPLOYMENT-PROFILE (reference value: 15 minutes).
    verification: conformance test ID-11
  - id: it-req-103
    level: L2
    statement: >
      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.
    verification: architecture review + network test ID-12
  - id: it-req-104
    level: L2
    statement: >
      Certificate profile (key type, EKU, SAN content) conforms to the
      deployment's CA policy. Profile: PENDING-DEPLOYMENT-PROFILE.
    verification: certificate inspection

  # ---- Level 3 — production, multi-site / regional ------------------
  - id: it-req-201
    level: L3
    statement: >
      Fully automatic issuance and rotation (no human in the loop for
      routine lifecycle); SPIRE or equivalent workload-identity plane.
    verification: conformance test ID-20
  - id: it-req-202
    level: L3
    statement: >
      Central revocation authority with signed revocation feed;
      propagation under 5 minutes.
    verification: conformance test ID-21
  - id: it-req-203
    level: L3
    statement: >
      Onboarding/offboarding in the agent registry triggers identity
      issuance/revocation atomically (no orphan credentials, no
      credential-less registered agents).
    verification: conformance test ID-22 (orphan sweep)
  - id: it-req-204
    level: L3
    statement: >
      Compromise response: a flagged agent is quarantined (denied all
      brokers/endpoints, task allocation suspended) within 5 minutes.
    verification: tabletop exercise + conformance test ID-23

deployment_profiles:
  - profile: dk-region-hovedstaden
    status: in definition
    fills: [it-req-101, it-req-102, it-req-103, it-req-104]
  - profile: no-helseid
    status: planned
    note: HelseID system-credential integration (Norway).

regulatory_mapping:
  - regime: EU CRA
    relevance: security-by-design for products implementing this standard
  - regime: IEC 62443
    relevance: >
      Conformance levels map informatively (not certifiably) to
      security levels: L1~SL1, L2~SL2, L3~SL3.
  - regime: NIS2
    relevance: hospital operators; zone model (it-req-103) is the hook
  - regime: Normen (NO)
    relevance: applies to Norwegian deployments (no-helseid profile)

open_items:
  - Deployment-profile parameters for dk-region-hovedstaden
  - Trust-domain federation (multi-region) — deferred to a later edition
  - Formal IEC 62443 mapping — pending third-party assessment

• identity-trust

• PENDING-DEPLOYMENT-PROFILE parameters (approved destinations, retention, two-person rule, export format)
• Vendor contract clause templates (egress declaration warranty) — commercial work item, outside spec scope
• Interaction with certification: DG conformance tests enter the Rocom Certified test set from L2

# =====================================================================
# Rocom OpenSpec v0.2 — Module: data-governance
# Status: ADOPTED 1.0, Edition 2026a
# Author: Rocom project (Egil), drafted with Claude
# Scope: Data classification, egress control and third-country
#        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
# NOTE:  Parameters marked PENDING-DEPLOYMENT-PROFILE are set per
#        deployment profile, not by this specification.
#        input via the Systematic workshop. Use placeholder values.
# =====================================================================

module: data-governance
version: 1.0
spec_parent: rocom-openspec-v0.2
depends_on: [identity-trust]   # attribution requires machine identity

principles:
  - id: dg-p-001
    statement: >
      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.)
  - id: dg-p-002
    statement: >
      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.
  - id: dg-p-003
    statement: >
      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.
  - id: dg-p-004
    statement: >
      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.

data_classes:
  - class: operational-telemetry
    definition: >
      State required for orchestration: position, battery, task/order
      state, error codes, availability.
    personal_data: no (by design; see dg-req-004)
  - class: diagnostic
    definition: >
      Vendor service data: logs, firmware state, component wear,
      performance counters.
    personal_data: normally no; must be verified per vendor
  - class: sensor-payload
    definition: >
      Raw or derived sensor streams: video, audio, lidar/point clouds,
      images.
    personal_data: presumed YES in healthcare environments (GDPR
      art. 9 exposure)
  - class: personal-data
    definition: >
      Any data relating to identified/identifiable persons, including
      staff scheduling data delivered by availability providers and
      task metadata naming individuals.
    personal_data: yes

requirements:
  # ---- Level 1 — pilot / lab ----------------------------------------
  - id: dg-req-001
    level: L1
    statement: >
      Every agent has a data profile in the Agent Registry:
      cap-006): sensors on board, data classes generated, declared
      destinations, lawful basis per destination.
    verification: registry inspection; conformance test DG-01
  - id: dg-req-002
    level: L1
    statement: >
      Every provider/task-source connection declares
      data_classes_delivered, declared_destinations and lawful_basis
      (availability_provider_contract data_profile section).
    verification: contract inspection; conformance test DG-02
  - id: dg-req-003
    level: L1
    statement: >
      Sensor-payload class does not traverse the convergence layer
      (dg-p-002). Teleoperation exception per dg-req-020.
    verification: conformance test DG-03 (payload injection attempt
      must be rejected)
  - id: dg-req-004
    level: L1
    statement: >
      Operational telemetry is verified free of personal-data fields
      (no names, no free-text carrying patient/staff identifiers in
      order payloads).
    verification: schema review + conformance test DG-04

  # ---- Level 2 — production, single site ----------------------------
  - id: dg-req-101
    level: L2
    statement: >
      All vendor telemetry/diagnostic egress is declared, routable and
      blockable at the convergence layer. Undeclared destinations are
      denied by default.
    verification: conformance test DG-10 (undeclared endpoint blocked)
  - id: dg-req-102
    level: L2
    statement: >
      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.
    verification: registry inspection; audit sample
  - id: dg-req-103
    level: L2
    statement: >
      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).
    verification: conformance test DG-11 (flow → identity lookup)
  - id: dg-req-104
    level: L2
    statement: >
      The registry can export an Article 30-compatible record of
      processing (per-agent and per-connection view) on demand.
    verification: export test DG-12; DPO review of format

  # ---- Level 3 — production, multi-site / regional ------------------
  - id: dg-req-201
    level: L3
    statement: >
      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).
    verification: conformance test DG-20
  - id: dg-req-202
    level: L3
    statement: >
      Continuous verification: declared data profiles are reconciled
      against observed flows; deviations raise governance events
      within 24 hours.
    verification: conformance test DG-21 (planted deviation detected)
  - id: dg-req-203
    level: L3
    statement: >
      Third-country transfer register is auditable per art. 30 with
      per-transfer lawful-basis reference, exportable to regional
      compliance systems. Format: PENDING-DEPLOYMENT-PROFILE.
    verification: export test DG-22

  # ---- Teleoperation exception (all levels where used) ---------------
  - id: dg-req-020
    level: L1+
    statement: >
      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.
    verification: conformance test DG-30 (session lifecycle);
      audit inspection

regulatory_mapping:
  - regime: GDPR (incl. art. 9, art. 30)
    relevance: data classes, lawful basis, records of processing
  - regime: Schrems II / third-country transfers
    relevance: dg-req-102/203 — transfer basis per destination
  - regime: EHDS
    relevance: >
      European data sovereignty alignment; convergence layer keeps
      health-adjacent data in-region by default
  - regime: NIS2
    relevance: zone model + egress control at critical-infrastructure
      operators
  - regime: Normen (NO)
    relevance: applies when Norwegian deployments activate; profile
      to be defined with NHN (on hold per 2026-08-11 decision)

open_items:
  - "PENDING-DEPLOYMENT-PROFILE parameters (approved destinations, retention, two-person rule, export format)"
  - "Vendor contract clause templates (egress declaration warranty) — commercial work item, outside spec scope"
  - "Interaction with certification: DG conformance tests enter the Rocom Certified test set from L2"