7 Resource type taxonomy

This chapter defines the standard resource types for OSIRIS v1.0. Resource types categorize infrastructure components using a hierarchical dot-notation taxonomy (see Chapter 4, section 4.2.2 Type field definition).

7.1 Overview

7.1.1 Purpose and scope

The taxonomy provides:

• Common vocabulary for infrastructure resources across IT and OT domains
• Semantic consistency enabling tools to recognize and process standard resource categories
• Extensibility through namespaced custom types when standard types do not apply
• Interoperability by establishing shared type strings that producers and consumers understand

The taxonomy is descriptive, not prescriptive: OSIRIS does not mandate that producers use only standard types. Producers MAY define custom types for vendor-specific or domain-specific resources. However, producers SHOULD use standard types when applicable to maximize interoperability.

Scope of this chapter:

• Standard types defined by OSIRIS v1.0 (sections 7.2–7.6)
• Type naming conventions and hierarchy rules (section 7.1.2)
• Selection guidance for choosing appropriate types (section 7.7)

This chapter does not define:

• Connection types (see Chapter 5, section 5.2)
• Group types (see Chapter 6, section 6.2)
• Validation rules (see Chapter 9)

Coverage: The taxonomy spans both IT infrastructure (network, compute, storage, application) and Operational Technology (building automation, physical security, power distribution, industrial control). This unified approach reflects the convergence of IT and OT systems in modern infrastructure, particularly in data centers, smart buildings and industrial IoT environments.

7.1.2 Type naming conventions

Resource types follow the dot-notation hierarchy rules defined in Chapter 4, section 4.2.3. This section provides additional guidance specific to the standard taxonomy.

General conventions:

• Types MUST use segments: [a-z0-9] lowercase letters, digits and dots separator only (no hyphens, underscores or spaces)
• Types SHOULD use dots to separate hierarchy levels (e.g. compute.vm.template)
• Types SHOULD use singular nouns (e.g. storage.volume, not storage.volumes)
• Types SHOULD be concise yet descriptive (e.g. network.firewall rather than network.security.firewall.device)

Hierarchy depth: Standard types in this taxonomy use 2-3 segments for most resources to avoid overloading the schema:

Two segments:

compute.vm

Three segments:

compute.vm.template

Producers MAY use deeper hierarchies only when necessary to increase the level of details (e.g. building.hvac.ahu or power.datacenter.pdu) but SHOULD consider whether additional specificity belongs in properties rather than the type string itself.

Standard type families: This taxonomy organizes resources into five top-level families:

Namespace reservation: As defined in Chapter 4, section 4.2.4, the osiris.* namespace is reserved for vendor-specific and organization-specific extensions. Standard types in this chapter do not use the osiris.* prefix.

7.1.3 Standard types vs custom types

Standard types are defined in this chapter and recognized across the OSIRIS ecosystem. Producers SHOULD use standard types when:

• The resource maps clearly to a standard type definition
• Semantic alignment exists (the standard type accurately describes the resource’s role)
• Interoperability is desired (consumers can apply special handling for standard types)

Extension (namespaced) types (osiris.*) are defined by producers for vendor-specific or domain-specific resources.

Producers SHOULD use custom types when:

• No standard type exists that accurately describes the resource
• Vendor-specific semantics are critical to preserve
• The resource is organization-specific and not applicable to other environments

Coexistence: Standard and custom types coexist within the same OSIRIS document.

A topology MAY contain:

{
  "topology": {
    "resources": [
      {
        "id": "aws::i-0abc123def4567890",
        "type": "compute.vm",
        "provider": {"name": "aws"}
      },
      {
        "id": "custom-aws-widget-001",
        "type": "osiris.aws.lambda.edge",
        "provider": {"name": "aws"}
      }
    ]
  }
}

Consumers MUST accept resources with both standard and custom types. Consumers SHOULD apply special handling (rendering, filtering, behavioral logic) for recognized standard types while treating custom types as generic resources.

Fallback behavior: When a vendor-specific resource has a close standard equivalent, producers SHOULD consider:

1. Using the standard type with vendor details in provider or properties
2. Using a namespaced custom type if semantics differ significantly
3. Documenting the mapping decision for parser consumers

7.1.4 Taxonomy evolution

Stability: Standard types defined in this chapter are stable for OSIRIS v1.x. Additions, modifications or deprecations follow semantic versioning principles:

• Minor versions (e.g. v1.1, v1.2) MAY add new standard types without breaking compatibility
• Minor versions SHOULD NOT remove or change the semantics of existing standard types
• Major versions (e.g. v2.0) MAY remove deprecated types or change type semantics with migration guidance

Type deprecation: If a standard type becomes obsolete or is replaced by a better alternative, OSIRIS will:

1. Mark the type as deprecated in a minor release
2. Document the recommended replacement type
3. Maintain the deprecated type for at least one major version cycle
4. Remove the type in a subsequent major release

Community contributions: Proposals for new standard types MAY be submitted to the OSIRIS governance process. Accepted proposals will be incorporated in minor releases.

Criteria for inclusion include:

• Clear, unambiguous definition
• Broad applicability across multiple providers or environments
• Avoidance of vendor-specific semantics
• Alignment with existing taxonomy structure

Extension types under extensions["osiris.*"] are not semantically governed by OSIRIS and may evolve independently. Producers using vendor/organization extensions SHOULD version their generator tools if extension semantics change to help consumers track compatibility.

7.2 Application resources

Application resources represent software services, databases, message queues, caches and code repositories that support application workloads.

7.2.1 Databases

Type: application.database

Definition: A database is a managed service or self-hosted system that stores, organizes and provides access to structured or semi-structured data. Databases support various data models (relational, document, key-value, graph) and query interfaces.

When to use: Use application.database for but not limited to:

• Managed cloud databases (CockroachDB, Neon DB, AWS RDS, Azure SQL Database, GCP Cloud SQL)
• NoSQL databases (DynamoDB, CosmosDB, MongoDB)
• Self-hosted databases (PostgreSQL, MySQL, MariaDB, SQL Server instances)

Common properties:

Provider mappings:

Example (AWS RDS):

{
  "id": "aws::myapp-prod-db",
  "type": "application.database",
  "name": "production-postgresql-primary",
  "provider": {
    "name": "aws",
    "type": "AWS::RDS::DBInstance",
    "native_id": "myapp-prod-db",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "engine": "postgres",
    "engine_version": "15.4",
    "database_type": "relational",
    "instance_class": "db.r6g.xlarge",
    "size_gb": 500,
    "multi_az": true,
    "encrypted": true,
    "endpoint": "myapp-prod-db.abc123.us-east-1.rds.amazonaws.com"
  },
  "status": "active"
}

Example (Self-hosted PostgreSQL):

{
  "id": "postgres-mxp-prod-01.internal.osiris.com.acme",
  "type": "application.database",
  "name": "production-postgresql-primary",
  "provider": {
    "name": "postgresql",
    "type": "PostgreSQL",
    "native_id": "postgres-mxp-prod-01.internal.osiris.com.acme"
  },
  "properties": {
    "engine": "postgres",
    "engine_version": "15.4",
    "database_type": "relational",
    "hostname": "postgres-mxp-prod-01.internal.osiris.com.acme",
    "port": 5432,
    "size_gb": 2000,
    "replication_mode": "synchronous",
    "replica_count": 2
  },
  "location": {
    "datacenter": "MXP",
    "rack": "R15-A",
    "unit": 12
  },
  "status": "active"
}

7.2.2 Message queues and event streams

Type: application.queue

Definition: A message queue is a service that enables asynchronous communication between application components by storing messages in a queue until they are processed. Queues decouple producers and consumers and provide buffering for variable processing rates.

When to use: Use application.queue for but not limited to:

• AWS SQS
• Azure Service Bus Queues
• RabbitMQ queues
• Apache Kafka topics (when modeled as message queues)

Common properties:

Example (AWS SQS):

{
  "id": "aws::order-processing-queue",
  "type": "application.queue",
  "name": "order-processing-fifo-queue",
  "provider": {
    "name": "aws",
    "type": "AWS::SQS::Queue",
    "native_id": "https://sqs.us-east-1.amazonaws.com/123456789012/order-processing-queue.fifo",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "queue_type": "fifo",
    "retention_hours": 336,
    "max_message_size": 262144,
    "encrypted": true
  },
  "status": "active"
}

Type: application.eventstream

Definition: An event stream is a distributed, partitioned log of events that enables publish-subscribe messaging and event replay. Streams support high-throughput data pipelines and real-time processing.

When to use: Use application.eventstream for but not limited to:

• Apache Kafka topics
• AWS Kinesis streams
• Azure Event Hubs
• Pub/Sub topics (when emphasizing streaming characteristics)

Example (AWS Kinesis):

{
  "id": "aws::user-clickstream-prod",
  "type": "application.eventstream",
  "name": "user-clickstream-analytics",
  "provider": {
    "name": "aws",
    "type": "AWS::Kinesis::Stream",
    "native_id": "user-clickstream-prod",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "shard_count": 4,
    "retention_hours": 168,
    "encrypted": true,
    "enhanced_monitoring": true
  },
  "status": "active"
}

Example (Apache Kafka - on-premise):

{
  "id": "kafka::order-events-topic",
  "type": "application.eventstream",
  "name": "order-events-stream",
  "provider": {
    "name": "kafka",
    "type": "KafkaTopic",
    "native_id": "order-events-topic"
  },
  "properties": {
    "partition_count": 12,
    "replication_factor": 3,
    "retention_hours": 168,
    "cluster": "kafka-mxp-prod-cluster",
    "compression_type": "lz4"
  },
  "location": {
    "datacenter": "MXP"
  },
  "status": "active"
}

7.2.3 Caching services

Type: application.cache

Definition: A caching service provides in-memory data storage for fast retrieval of frequently accessed data. Caches reduce latency and database load by storing hot data in RAM.

When to use: Use application.cache for but not limited to:

• AWS ElastiCache (Redis, Memcached)
• Azure Cache for Redis
• GCP Memorystore
• Self-hosted Redis/Memcached instances

Common properties:

Example (AWS ElastiCache):

{
  "id": "aws::session-cache-prod",
  "type": "application.cache",
  "name": "session-cache-cluster",
  "provider": {
    "name": "aws",
    "type": "AWS::ElastiCache::ReplicationGroup",
    "native_id": "session-cache-prod",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "engine": "redis",
    "engine_version": "7.0",
    "memory_gb": 32,
    "node_count": 3,
    "encrypted_in_transit": true,
    "encrypted_at_rest": true,
    "automatic_failover": true
  },
  "status": "active"
}

Example (Self-hosted Redis):

{
  "id": "redis::mxp-session-cluster",
  "type": "application.cache",
  "name": "session-cache-cluster",
  "provider": {
    "name": "redis",
    "type": "RedisCluster",
    "native_id": "mxp-session-cluster"
  },
  "properties": {
    "engine": "redis",
    "engine_version": "7.2.3",
    "memory_gb": 64,
    "node_count": 6,
    "cluster_mode": true,
    "persistence": "aof",
    "nodes": [
      "redis-mxp-01.internal.osiris.com.acme:6379",
      "redis-mxp-02.internal.osiris.com.acme:6379",
      "redis-mxp-03.internal.osiris.com.acme:6379"
    ]
  },
  "location": {
    "datacenter": "MXP"
  },
  "status": "active"
}

7.2.4 Code repositories

Type: application.repository

Definition: A code repository is a version control system that stores source code, tracks changes and enables collaboration. Repositories use version control systems (Git, SVN) to manage codebase history.

When to use: Use application.repository for but not limited to:

• GitHub repositories
• GitLab projects
• Bitbucket repositories
• AWS CodeCommit repositories
• Azure Repos

Common properties:

Example:

{
  "id": "github::12345678",
  "type": "application.repository",
  "name": "web-application-frontend",
  "provider": {
    "name": "github",
    "type": "Repository",
    "native_id": "12345678"
  },
  "properties": {
    "vcs_type": "git",
    "default_branch": "main",
    "visibility": "private",
    "url": "https://github.com/myorg/web-app-frontend",
    "language": "TypeScript",
    "size_kb": 45632
  },
  "status": "active"
}

7.2.5 Application services

Type: application.service

Definition: An application service is a generic deployed application or microservice that does not fit more specific application resource types. Services represent running applications, APIs or workloads.

When to use: Use application.service for but not limited to:

• Microservices
• Web applications
• API services
• Background workers
• Any application component not covered by specific types (database, cache, queue, etc.)

Common properties:

Example:

{
  "id": "kubernetes::payment-api-deployment",
  "type": "application.service",
  "name": "payment-processing-api",
  "provider": {
    "name": "kubernetes",
    "type": "Deployment",
    "native_id": "payment-api-deployment",
    "namespace": "osiris.com.acme"
  },
  "properties": {
    "service_type": "api",
    "language": "python",
    "framework": "fastapi",
    "version": "2.5.1",
    "endpoints": ["https://api.acme.example/payments"],
    "replicas": 3,
    "container_image": "registry.acme.example/payment-api:2.5.1"
  },
  "status": "active"
}

7.3 Compute resources

Compute resources represent processing capacity: virtual machines, physical servers, containers, serverless functions and compute clusters. These resources execute workloads, run operating systems and provide the computational foundation of infrastructure.

7.3.1 Physical servers

Type: compute.server

Definition: A physical server is a bare-metal compute host: a physical machine with CPU, memory, storage and network hardware. Physical servers may run workloads directly (bare metal) or serve as hypervisor hosts for virtual machines or containers clusters.

When to use: Use compute.server for:

• Bare-metal cloud instances (e.g. AWS EC2 Bare Metal, Azure Dedicated Host)
• On-premise physical servers (e.g. Dell PowerEdge, HPE ProLiant, Cisco UCS)
• Hypervisor hosts (e.g. ESXi hosts, Proxmox nodes)
• Any physical compute hardware

Common properties:

Provider mappings:

Example:

{
  "id": "dell::SERVICE_TAG_ABC123",
  "type": "compute.server",
  "name": "esx-host-03.acme.example",
  "provider": {
    "name": "dell",
    "model": "PowerEdge R770",
    "native_id": "SERVICE_TAG_ABC123"
  },
  "properties": {
    "manufacturer": "Dell",
    "model": "PowerEdge R770",
    "cpu_model": "Intel Xeon Gold 6348",
    "cpu_cores": 56,
    "memory_mb": 524288,
    "role": "hypervisor",
    "hypervisor": "vmware_esxi_8.0",
    "management_ip": "10.0.10.42"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "floor": "1",
    "rack": "R01",
    "rack_unit": "42"
  }
}

7.3.2 Virtual machines

Type: compute.vm

Definition: A virtual machine (VM) is a software-based compute instance that emulates physical hardware. VMs run on hypervisors and provide isolated execution environments with dedicated CPU, memory, storage and network resources.

When to use: Use compute.vm for:

• Cloud virtual machine instances (AWS EC2, Azure VMs, GCP Compute Engine)
• On-premise virtualized servers (VMware VMs, Proxmox VMs, Hyper-V VMs)
• Virtual desktop infrastructure (VDI) instances
• Any resource that represents a full virtual machine with OS-level isolation

Common properties: Producers SHOULD include these properties when available:

Provider mappings:

[!NOTE] “Native Type” is an example identifier from a common interface (CloudFormation/ARM/API/Terraform/ROS). Parsers SHOULD label the source system in documentation (or encode it in provider.source) when the same provider has multiple native type namespaces (e.g. IBM VPC vs Classic, Alibaba ROS vs Terraform).

Example:

{
  "id": "aws::i-0abc123def4567890",
  "type": "compute.vm",
  "name": "web-server-01",
  "provider": {
    "name": "aws",
    "type": "AWS::EC2::Instance",
    "native_id": "i-0abc123def4567890",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "instance_type": "t3.medium",
    "vcpus": 2,
    "memory_mb": 4096,
    "os": "Ubuntu 22.04 LTS",
    "state": "running",
    "ip_addresses": {
      "private_ip": ["10.0.1.10", "10.0.1.11"],
      "public_ip": "203.0.113.10"
    }
  },
  "status": "active"
}

Related types:

• compute.vm.template - VM templates or images
• compute.vm.snapshot - Point-in-time VM snapshots

7.3.3 Containers

Type: compute.container

Definition: A container is a lightweight, isolated execution environment that shares the host OS kernel. Containers package applications with their dependencies and provide process-level isolation without the overhead of full virtualization.

When to use: Use compute.container for:

• Docker containers
• Kubernetes pods (when modeling individual containers within pods)
• ECS/EKS task containers
• Any container runtime instance (containerd, CRI-O, etc.)

Common properties:

Provider mappings:

Example:

{
  "id": "docker::a3b2c1d4e5f6",
  "type": "compute.container",
  "name": "redis-cache-01",
  "provider": {
    "name": "docker",
    "type": "Container",
    "native_id": "a3b2c1d4e5f6"
  },
  "properties": {
    "image": "redis:7.2-alpine",
    "registry": "docker.io",
    "runtime": "docker",
    "state": "running",
    "cpu_limit": "500m",
    "memory_limit": "512Mi",
    "ports": ["6379:6379"]
  },
  "status": "active"
}

Related types:

• compute.container.pod - Kubernetes pods (groups of containers)
• compute.container.image - Container images

7.3.4 Compute clusters

Type: compute.cluster

Definition: A compute cluster is a managed group of compute resources that work together to provide scalable processing capacity. Clusters abstract individual nodes and provide unified management, scheduling and scaling.

When to use: Use compute.cluster for:

• Kubernetes clusters
• VMware vSphere clusters
• Proxmox clusters
• ECS/EKS clusters
• Auto-scaling groups (when modeled as managed compute pools)

Common properties:

Provider mappings:

Example:

{
  "id": "vmware::domain-c7",
  "type": "compute.cluster",
  "name": "Production vSphere Cluster",
  "provider": {
    "name": "vmware",
    "type": "vSphere Cluster",
    "native_id": "domain-c7",
    "region": "mxp-dc1"
  },
  "properties": {
    "orchestrator": "vmware_vsphere",
    "version": "8.0 U3",
    "node_count": 6,
    "capacity": {
      "vcpus": 336,
      "memory_mb": 3145728
    },
    "ha_enabled": true,
    "drs_enabled": true
  },
  "status": "active"
}

7.3.5 Serverless functions

Type: compute.function.serverless

Definition: A serverless function is an event-driven compute resource that executes code in response to triggers without requiring explicit server or VM management. Functions scale automatically and are billed based on execution time.

When to use: Use compute.function.serverless for:

• AWS Lambda functions
• Azure Functions
• Google Cloud Functions
• Cloudflare Workers
• Any function-as-a-service offering

Common properties:

Provider mappings:

Example:

{
  "id": "aws::image-processor",
  "type": "compute.function.serverless",
  "name": "image-processor",
  "provider": {
    "name": "aws",
    "type": "AWS::Lambda::Function",
    "native_id": "image-processor",
    "region": "us-east-1",
    "account": "123456789012",
    "arn": "arn:aws:lambda:us-east-1:123456789012:function:image-processor"
  },
  "properties": {
    "runtime": "python3.11",
    "memory_mb": 1024,
    "timeout_seconds": 60,
    "handler": "lambda_function.handler",
    "trigger_type": "s3"
  },
  "status": "active"
}

7.4 Storage resources

Storage resources provide persistent data storage capabilities: block devices, object stores, file systems and storage arrays.

7.4.1 Block storage

Type: storage.volume

Definition: A storage volume is a block-level storage device that can be attached to compute resources. Volumes provide persistent storage with raw block access, typically used for operating systems, databases and applications requiring low-latency I/O.

When to use: Use storage.volume for:

• Cloud block storage (AWS EBS, Azure Managed Disks, GCP Persistent Disks)
• SAN volumes
• Virtual machine disks (VMDKs, VHDs)
• LUNs on storage arrays

Common properties:

Provider mappings:

Example:

{
  "id": "aws::vol-0abc123",
  "type": "storage.volume",
  "name": "database-data-volume",
  "provider": {
    "name": "aws",
    "type": "AWS::EC2::Volume",
    "native_id": "vol-0abc123",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "size_gb": 500,
    "volume_type": "gp3",
    "iops": 5000,
    "throughput_mbps": 250,
    "encrypted": true,
    "availability_zone": "us-east-1a"
  },
  "status": "active"
}

7.4.2 Object storage

Type: storage.bucket

Definition: An object storage bucket is a container for storing unstructured data (objects) in the cloud. Buckets provide scalable, durable storage accessed via HTTP APIs, typically used for media files, backups, logs and static website hosting.

When to use: Use storage.bucket for:

• AWS S3 buckets
• Azure Blob Storage containers
• GCP Cloud Storage buckets
• MinIO buckets
• Any object storage container

Common properties:

Provider mappings:

Example:

{
  "id": "aws::my-app-assets-bucket",
  "type": "storage.bucket",
  "name": "application-assets",
  "provider": {
    "name": "aws",
    "type": "AWS::S3::Bucket",
    "native_id": "my-app-assets-bucket",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "versioning_enabled": true,
    "public_access": false,
    "encryption": "SSE-S3",
    "lifecycle_rules": true
  },
  "status": "active"
}

7.4.3 File storage

Type: storage.filesystem

Definition: A file storage system provides file-based storage accessible over network protocols (NFS, SMB/CIFS). File systems organize data in hierarchical directories and support file-level operations.

When to use: Use storage.filesystem for:

• AWS EFS (Elastic File System)
• Azure Files
• GCP Filestore
• NFS exports
• SMB/CIFS shares

Common properties:

Example:

{
  "id": "aws::fs-0abc123",
  "type": "storage.filesystem",
  "name": "shared-application-data",
  "provider": {
    "name": "aws",
    "type": "AWS::EFS::FileSystem",
    "native_id": "fs-0abc123",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "protocol": "nfs",
    "size_gb": 2048,
    "performance_mode": "general-purpose",
    "encrypted": true
  },
  "status": "active"
}

7.4.4 Storage systems

Type: storage.array

Definition: A storage array is a dedicated hardware system that provides centralized storage services. Arrays aggregate multiple disks and provide advanced features like RAID, snapshots, replication and tiered storage.

When to use: Use storage.array for:

• SAN arrays (45Drives, NetApp, Pure Storage)
• NAS appliances
• Dedicated storage systems

Common properties:

Example:

{
  "id": "45drives::serial-123456",
  "type": "storage.array",
  "name": "storinator-xl60-01",
  "provider": {
    "name": "45drives",
    "model": "Storinator XL60",
    "native_id": "serial-123456"
  },
  "properties": {
    "manufacturer": "45Drives",
    "model": "Storinator XL60",
    "capacity_tb": 120,
    "protocols": ["zfs", "iscsi", "fc"],
    "version": "ceph 10.2.0",
    "management_ip": "10.0.20.10"
  },
  "status": "active"
}

7.5 Network resources

Network resources provide connectivity, routing, security and traffic management. This family includes virtual networks, physical network devices, security constructs, load balancers and network interfaces.

7.5.1 Virtual networks and subnets

Virtual Private Cloud or Virtual Network

Type: network.vpc

Definition: A virtual private cloud (VPC) or virtual network (VNet) is an isolated network segment within a cloud or hyperscaler provider’s infrastructure. VPCs provide logical network isolation with configurable IP address ranges, subnets, routing tables and security policies.

When to use: Use network.vpc for:

• AWS VPCs
• Azure Virtual Networks (VNets)
• GCP VPC Networks
• Any cloud-native virtual network construct

Common properties:

Provider mappings:

Example:

{
  "id": "aws::vpc-0abc123def4567890",
  "type": "network.vpc",
  "name": "production-vpc",
  "provider": {
    "name": "aws",
    "type": "AWS::EC2::VPC",
    "native_id": "vpc-0abc123def4567890",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "cidr": "10.0.0.0/16",
    "dns_enabled": true,
    "dns_hostnames": true,
    "ipv6_enabled": false
  },
  "status": "active"
}

Subnet

Type: network.subnet

Definition: A subnet is a subdivided IP address range within a larger network. Subnets provide logical segmentation and may be associated with availability zones, routing tables or security policies.

When to use: Use network.subnet for:

• Cloud subnets (AWS Subnets, Azure Subnets, GCP Subnetworks)
• VLAN segments (when modeling layer-3 subnets, not layer-2 VLANs)

Common properties:

Example:

{
  "id": "aws::subnet-0xyz789",
  "type": "network.subnet",
  "name": "public-subnet-1a",
  "provider": {
    "name": "aws",
    "type": "AWS::EC2::Subnet",
    "native_id": "subnet-0xyz789",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "cidr": "10.0.1.0/24",
    "availability_zone": "us-east-1a",
    "public": true
  },
  "status": "active"
}

VLAN

Type: network.vlan

Definition: A Virtual LAN (VLAN) is a layer-2 network segment that logically partitions a physical network. VLANs isolate broadcast domains and enable network segmentation without physical separation.

When to use: Use network.vlan for:

• IEEE 802.1Q VLANs
• Physical switch VLANs
• On-premise network segments (when VLAN ID is the defining characteristic)

Common properties:

Example:

{
  "id": "cisco::100",
  "type": "network.vlan",
  "name": "Production VLAN",
  "provider": {
    "name": "cisco",
    "type": "VLAN",
    "native_id": "100"
  },
  "properties": {
    "vlan_id": 100,
    "vlan_name": "office",
    "subnet": "10.100.0.0/24",
    "description": "Production network segment"
  },
  "status": "active"
}

7.5.2 Network devices

Router

Type: network.router

Definition: A router is a network device that forwards packets between networks based on IP routing tables. Routers operate at layer 3 and make path decisions based on destination IP addresses.

When to use: Use network.router for:

• Physical routers (Cisco, Ciena, Nokia)
• Virtual routers (cloud router gateways, virtual router appliances)
• Layer-3 routing devices

Common properties:

Example:

{
  "id": "cisco::serial-ABC123",
  "type": "network.router",
  "name": "edge-router-01",
  "provider": {
    "name": "cisco",
    "type": "ASR 1001-X",
    "native_id": "serial-ABC123"
  },
  "properties": {
    "manufacturer": "Cisco",
    "model": "ASR 1001-X",
    "version": "IOS XE 17.9.3",
    "routing_protocol": ["bgp", "ospf"],
    "management_ip": "10.0.10.1"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "floor": "1",
    "rack": "R01"
  }
}

Router port

Type: network.router.port

Definition: A router port (also called router interface) is a physical or logical connection point on a router used to connect to networks or other network devices. Router ports operate at Layer 3, have IP addresses assigned and participate in routing protocols.

When to use: Use network.router.port for:

• Physical router interfaces (GigabitEthernet, TenGigabitEthernet, Serial)
• Logical interfaces (Loopback, Tunnel, VLAN interfaces)
• WAN interfaces
• Subinterfaces for VLAN trunking

Common properties:

Example:

{
  "id": "cisco::Ethernet1",
  "type": "network.router.port",
  "name": "edge-router-uplink",
  "provider": {
    "name": "cisco",
    "type": "Router Interface",
    "native_id": "Ethernet1"
  },
  "properties": {
    "interface_name": "Ethernet1",
    "ip_address": "10.130.100.1",
    "subnet_mask": "255.255.255.252",
    "admin_status": "up",
    "oper_status": "up",
    "speed_mbps": 10000,
    "duplex": "full",
    "mtu": 9214,
    "description": "Uplink to ISP"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "floor": "1",
    "rack": "R01",
    "device": "edge-router-01"
  }
}

Switch

Type: network.switch

Definition: A network switch is a device that connects devices within a network segment and forwards frames based on MAC addresses. Switches operate primarily at layer 2, though many modern switches provide layer-3 capabilities.

When to use: Use network.switch for:

• Physical switches (Cisco Catalyst, Arista DCS)
• Layer-2 switching devices
• Spine switches
• Leaf switches
• Top-of-rack (ToR) switches

Common properties:

Example:

{
  "id": "arista::serial-XYZ789",
  "type": "network.switch",
  "name": "leaf-switch-01",
  "provider": {
    "name": "arista",
    "type": "DCS-7050SX3-48YC12",
    "native_id": "serial-XYZ789"
  },
  "properties": {
    "manufacturer": "Arista",
    "model": "DCS-7050SX3-48YC12",
    "version": "EOS 4.31.2F",
    "port_count": 48,
    "layer3_capable": true,
    "management_ip": "10.0.10.15"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "floor": "1",
    "rack": "R01"
  }
}

Switch port

Type: network.switch.port

Definition: A switch port is a physical or logical connection point on a network switch used to connect end devices or other network equipment. Switch ports operate primarily at Layer 2, forwarding frames based on MAC addresses, though some ports may support Layer 3 functionality on capable switches.

When to use: Use network.switch.port for:

• Physical switch interfaces (Ethernet, GigabitEthernet, TenGigabitEthernet)
• Access ports (connecting end devices)
• Trunk ports (carrying multiple VLANs)
• Port-channel/LAG members
• SFP/QSFP transceiver ports

Common properties:

Example:

{
  "id": "arista::Ethernet48",
  "type": "network.switch.port",
  "name": "server-connection-r01-u42",
  "provider": {
    "name": "arista",
    "type": "Switch Port",
    "native_id": "Ethernet48"
  },
  "properties": {
    "interface_name": "Ethernet48",
    "port_mode": "access",
    "vlan": 100,
    "admin_status": "up",
    "oper_status": "up",
    "speed_mbps": 10000,
    "duplex": "full",
    "mtu": 9214,
    "spanning_tree_state": "forwarding",
    "poe_enabled": false,
    "description": "Connection to Dell PowerEdge R770"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "floor": "1",
    "rack": "R01",
    "device": "leaf-switch-01"
  }
}

7.5.3 Network interfaces and endpoints

Type: network.interface

Definition: A network interface is a connection point between a resource and a network. Interfaces have IP addresses, MAC addresses and network configuration properties.

When to use: Use network.interface for:

• Virtual machine NICs (AWS ENI, Azure vNIC)
• Physical server network adapters
• Container network interfaces

Common properties:

Example:

{
  "id": "aws::eni-0abc123",
  "type": "network.interface",
  "name": "web-server-primary-nic",
  "provider": {
    "name": "aws",
    "type": "AWS::EC2::NetworkInterface",
    "native_id": "eni-0abc123",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "mac_address": "0a:1b:2c:3d:4e:5f",
    "ip_addresses": ["10.0.1.15"],
    "interface_type": "primary"
  },
  "status": "active"
}

7.5.4 Network Load balancing

Type: network.loadbalancer

Definition: A load balancer distributes incoming network traffic across multiple backend targets (servers, containers, functions) to ensure availability, scalability and fault tolerance.

When to use: Use network.loadbalancer for:

• Cloud load balancers (AWS ALB/NLB, Azure Load Balancer, GCP Load Balancer)
• Hardware load balancers (F5, Citrix ADC, Kemp)
• Software load balancers (HAProxy, NGINX)

Common properties:

Provider mappings:

Example:

{
  "id": "aws::web-application-lb",
  "type": "network.loadbalancer",
  "name": "web-application-lb",
  "provider": {
    "name": "aws",
    "type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
    "native_id": "web-application-lb",
    "region": "us-east-1",
    "account": "123456789012",
    "arn": "arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/web-application-lb/1234567890abcdef"
  },
  "properties": {
    "load_balancer_type": "application",
    "scheme": "internet-facing",
    "protocol": ["http", "https"],
    "dns_name": "web-lb-123456789.us-east-1.elb.amazonaws.com"
  },
  "status": "active"
}

7.5.5 Network security

Firewalls

Type: network.firewall

Definition: A firewall is a security device or service that filters network traffic based on rules. Firewalls inspect packets and enforce access control policies to protect networks from unauthorized access.

When to use: Use network.firewall for:

• Physical firewall appliances (Palo Alto, Checkpoint, Cisco ASA)
• Cloud firewalls (AWS Network Firewall, Azure Firewall)
• Virtual firewall appliances

Common properties:

Example:

{
  "id": "paloalto::serial-PAN5220-001",
  "type": "network.firewall",
  "name": "edge-firewall-primary",
  "provider": {
    "name": "paloalto",
    "type": "PA-5220",
    "native_id": "serial-PAN5220-001"
  },
  "properties": {
    "firewall_type": "hardware",
    "manufacturer": "Palo Alto Networks",
    "model": "PA-5220",
    "version": "PAN-OS 11.0.3",
    "ha_enabled": true,
    "management_ip": "10.0.10.20"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "floor": "1",
    "rack": "R05"
  }
}

Security group

Type: network.security.group

Definition: A security group is a classic Hyperscaler virtual firewall that controls inbound and outbound traffic for cloud resources. Security groups use rule-based policies to permit or deny traffic based on protocol, port and source/destination.

When to use: Use network.security.group for:

• AWS Security Groups
• Azure Network Security Groups (NSGs)
• GCP Firewall Rules (when modeled as rule groups)

Common properties:

Example:

{
  "id": "aws::sg-0abc123",
  "type": "network.security.group",
  "name": "web-tier-sg",
  "provider": {
    "name": "aws",
    "type": "AWS::EC2::SecurityGroup",
    "native_id": "sg-0abc123",
    "region": "us-east-1",
    "account": "123456789012"
  },
  "properties": {
    "direction": "both",
    "rule_count": 3,
    "description": "Security group for web tier"
  },
  "status": "active"
}

7.6 Operational Technology resources

Operational Technology (OT) resources represent physical infrastructure systems: building automation, physical security, power distribution, industrial control and physical infrastructure. This section start drafting the bridges between IT and OT domains.

7.6.1 Building automation

Air Handling Unit

Type: building.hvac.ahu

Definition: An Air Handling Unit (AHU) is a large HVAC device that conditions and circulates air as part of a building’s heating, ventilation and air conditioning system. AHUs typically contain fans, filters, heating/cooling coils and dampers.

When to use: Use building.hvac.ahu for:

• Commercial building air handlers
• Data center air handling systems
• Large-scale HVAC units with integrated controls

Common properties:

Example:

{
  "id": "carrier::AHU-F1-M01",
  "type": "building.hvac.ahu",
  "name": "Floor 1 Main AHU",
  "provider": {
    "name": "carrier",
    "type": "39M-120",
    "native_id": "AHU-F1-M01"
  },
  "properties": {
    "manufacturer": "Carrier",
    "model": "39M-120",
    "capacity_cfm": 12000,
    "protocol": "bacnet",
    "bacnet_device_id": 100201,
    "bacnet_network": 1,
    "ip_address": "10.20.10.30"
  },
  "status": "active",
  "location": {
    "building": "MXP",
    "floor": "1",
    "room": "Mechanical room"
  }
}

HVAC Zone/VAV

Type: building.hvac.vav

Definition: A Variable Air Volume (VAV) box is a terminal device that controls airflow to individual zones within a building. VAVs modulate air volume based on zone temperature demands.

When to use: Use building.hvac.vav for:

• VAV terminal units
• Zone damper controllers
• Individual zone HVAC controls

Common properties:

Example:

{
  "id": "trane::VAV-F2-201",
  "type": "building.hvac.vav",
  "name": "Room 201 VAV",
  "provider": {
    "name": "trane",
    "type": "VAV Box",
    "native_id": "VAV-F2-201"
  },
  "properties": {
    "zone_name": "Office 201",
    "min_cfm": 150,
    "max_cfm": 1000,
    "protocol": "bacnet",
    "bacnet_device_id": 100301
  },
  "status": "active",
  "location": {
    "building": "MXP",
    "floor": "2",
    "room": "201"
  }
}

Chiller/Boiler

Type: building.hvac.chiller / building.hvac.boiler

Definition: A chiller produces chilled water for cooling systems. A boiler produces hot water or steam for heating systems. Both are central plant equipment that serve multiple zones or buildings.

When to use: Use these types for:

• Central chiller plants
• Boiler systems
• District heating/cooling equipment

Example (Chiller):

{
  "id": "trane::CHLR-01",
  "type": "building.hvac.chiller",
  "name": "Central Chiller #1",
  "provider": {
    "name": "trane",
    "type": "CVHE-400",
    "native_id": "CHLR-01"
  },
  "properties": {
    "manufacturer": "Trane",
    "model": "CVHE-400",
    "capacity_tons": 400,
    "refrigerant": "R-134a",
    "protocol": "bacnet",
    "bacnet_device_id": 100001
  },
  "status": "active",
  "location": {
    "building": "MXP",
    "floor": "Basement",
    "room": "Central Plant"
  }
}

7.6.2 Physical security

Access control panel

Type: security.access.panel

Definition: An access control panel is a hardware device that manages electronic door locks and reader devices. Panels authenticate credentials (cards, biometrics, PINs) and grant/deny physical access.

When to use: Use security.access.panel for:

• Electronic access control systems (HID, Honeywell, Lenel)
• Badge reader controllers
• Door control panels

Common properties:

Example:

{
  "id": "hid::ACP-F1-001",
  "type": "security.access.panel",
  "name": "Floor 1 Main Access Panel",
  "provider": {
    "name": "hid",
    "type": "VertX V100",
    "native_id": "ACP-F1-001"
  },
  "properties": {
    "manufacturer": "HID",
    "model": "VertX V100",
    "door_count": 8,
    "protocol": "wiegand",
    "ip_address": "10.30.1.10"
  },
  "status": "active",
  "location": {
    "building": "MXP",
    "floor": "1"
  }
}

Camera

Type: security.camera

Definition: A security camera is a video surveillance device that captures and records visual information for monitoring, incident response and forensic analysis.

When to use: Use security.camera for:

• IP cameras
• Analog cameras (when modeled in infrastructure)
• PTZ (pan-tilt-zoom) cameras

Common properties:

Example:

{
  "id": "axis::ACCC8E123456",
  "type": "security.camera",
  "name": "Main entrance camera",
  "provider": {
    "name": "axis",
    "type": "P3245-LVE",
    "native_id": "ACCC8E123456"
  },
  "properties": {
    "camera_type": "dome",
    "resolution": "1920x1080",
    "firmware_version": "11.0",
    "stream_url": "rtsp://10.30.2.15/axis-media/media.amp",
    "management_ip": "10.30.2.18",
    "poe_powered": true
  },
  "status": "active",
  "location": {
    "building": "MXP",
    "floor": "Ground",
    "description": "Main entrance"
  }
}

7.6.3 Power and environmental

UPS (Uninterruptible Power Supply)

Type: power.ups

Definition: A UPS provides backup battery power to maintain uptime during electrical outages. UPS systems protect equipment from power disturbances and enable graceful shutdowns.

When to use: Use power.ups for:

• Data center UPS systems
• Rack-mounted UPS units
• Building backup power systems

Common properties:

Example:

{
  "id": "apc::AS0123456789",
  "type": "power.ups",
  "name": "Rack 01 UPS",
  "provider": {
    "name": "apc",
    "type": "Smart-UPS SRT 10kVA",
    "native_id": "AS0123456789"
  },
  "properties": {
    "manufacturer": "APC",
    "model": "Smart-UPS SRT 10kVA",
    "capacity_kva": 10,
    "runtime_minutes": 20,
    "protocol": "snmp",
    "management_ip": "10.40.1.15"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "floor": "1",
    "rack": "R01"
  }
}

PDU (Power Distribution Unit)

Type: power.pdu

Definition: A PDU distributes electrical power to multiple devices within a rack or equipment area. PDUs provide metering, monitoring and if supported remote outlet control and diagnostic.

When to use: Use power.pdu for:

• Rack-mounted PDUs
• Intelligent PDUs with network monitoring and control
• Metered power strips

Common properties:

Example:

{
  "id": "apc::PDU-R01-A",
  "type": "power.pdu",
  "name": "Rack 01 PDU A",
  "provider": {
    "name": "apc",
    "type": "AP8959",
    "native_id": "PDU-R01-A"
  },
  "properties": {
    "manufacturer": "APC",
    "model": "AP8959",
    "outlet_count": 16,
    "max_amperage": 30,
    "voltage": 208,
    "metered": true,
    "managed": true,
    "management_ip": "10.40.1.20"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "floor": "1",
    "rack": "R01",
    "position": "A"
  }
}

7.6.4 Industrial control systems

PLC (Programmable Logic Controller)

Type: industrial.plc

Definition: A PLC is a ruggedized industrial computer that controls manufacturing processes, machinery and automation systems. PLCs execute ladder logic programs and interface with sensors and actuators.

When to use: Use industrial.plc for:

• Factory automation controllers
• Process control systems
• Industrial automation equipment

Common properties:

Example:

{
  "id": "siemens::PLC-LINE01",
  "type": "industrial.plc",
  "name": "Production Line 1 PLC",
  "provider": {
    "name": "siemens",
    "type": "S7-1500",
    "native_id": "PLC-LINE01"
  },
  "properties": {
    "manufacturer": "Siemens",
    "model": "S7-1500",
    "protocol": "profinet",
    "io_points": 256,
    "firmware_version": "V2.9.3",
    "ip_address": "192.168.100.10"
  },
  "status": "active",
  "location": {
    "facility": "Manufacturing Plant",
    "line": "Production Line 1"
  }
}

SCADA System

Type: industrial.scada

Definition: A SCADA (Supervisory Control and Data Acquisition) system monitors and controls industrial processes at scale. SCADA systems aggregate data from sensors and PLCs and provide centralized visualization and control.

When to use: Use industrial.scada for:

• Industrial control systems
• Utility monitoring systems (water, power, gas)
• Process visualization and control platforms

Example:

{
  "id": "wonderware::SCADA-MASTER",
  "type": "industrial.scada",
  "name": "Plant Master SCADA",
  "provider": {
    "name": "wonderware",
    "type": "System Platform",
    "native_id": "SCADA-MASTER"
  },
  "properties": {
    "software": "Wonderware System Platform",
    "version": "2023",
    "node_count": 12,
    "tag_count": 5000,
    "redundancy": "hot-standby"
  },
  "status": "active",
  "location": {
    "facility": "Manufacturing Plant",
    "room": "Control Room"
  }
}

7.6.5 Physical infrastructure

Physical infrastructure resources represent the physical locations and structures that house IT and OT equipment. These resources form the foundation of the location hierarchy used throughout OSIRIS.

Data center

Type: physical.datacenter

Definition: A data center (or datacenter) is a facility used to house computer systems, networking equipment, storage systems and associated components. Data centers provide power distribution, cooling, physical security and network connectivity required for IT operations.

When to use: Use physical.datacenter for:

• Entire datacenter facilities
• Colocation facilities
• Enterprise data centers
• Edge data centers

Common properties:

Example:

{
  "id": "custom::MXP-DC-01",
  "type": "physical.datacenter",
  "name": "Milan Primary Datacenter",
  "provider": {
    "name": "custom",
    "type": "Enterprise Datacenter",
    "native_id": "MXP-DC-01",
    "namespace": "osiris.com.acme"
  },
  "properties": {
    "site_code": "MXP",
    "tier": "Tier III",
    "total_sqft": 15000,
    "power_capacity_kw": 3200,
    "cooling_capacity_tons": 600,
    "rack_count": 120,
    "certifications": ["ISO27001", "SOC2"],
    "address": "Via Example 123, Milan, Italy",
    "timezone": "Europe/Rome"
  },
  "status": "active",
  "location": {
    "city": "Milan",
    "country": "IT",
    "region": "EMEA"
  }
}

Buildings

Type: physical.building

Definition: A building is a physical structure within a datacenter campus or facility. Buildings may contain multiple floors with equipment rooms, offices and support facilities.

When to use: Use physical.building for:

• Individual buildings within datacenter campuses
• Multi-building facilities
• Separate structures within a site

Common properties:

Example:

{
  "id": "custom::MXP-BLDG-01",
  "type": "physical.building",
  "name": "MXP Building 01",
  "provider": {
    "name": "custom",
    "type": "Datacenter Building",
    "native_id": "MXP-BLDG-01",
    "namespace": "osiris.com.acme"
  },
  "properties": {
    "building_number": "01",
    "total_floors": 2,
    "total_sqft": 8000,
    "power_capacity_kw": 2000,
    "primary_use": "datacenter"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP"
  }
}

Floors

Type: physical.floor

Definition: A floor represents a level within a building. Floors contain rooms, equipment areas and infrastructure distribution systems.

When to use: Use physical.floor for:

• Individual floors within buildings
• Raised floor areas
• Equipment levels

Common properties:

Example:

{
  "id": "custom::MXP-F1",
  "type": "physical.floor",
  "name": "MXP Floor 1",
  "provider": {
    "name": "custom",
    "type": "Datacenter Floor",
    "native_id": "MXP-F1",
    "namespace": "osiris.com.acme"
  },
  "properties": {
    "floor_number": 1,
    "floor_sqft": 4000,
    "raised_floor": true,
    "raised_floor_height_inches": 24,
    "ceiling_height_ft": 12,
    "cooling_type": "hot-aisle-containment"
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "building": "01"
  }
}

Rooms

Type: physical.room

Definition: A room represents a physical space within a floor containing infrastructure equipment. Rooms may be server rooms, network closets, electrical rooms or mechanical spaces.

When to use: Use physical.room for:

• Server rooms
• Network closets
• Equipment rooms
• Mechanical rooms
• Electrical rooms

Common properties:

Example:

{
  "id": "custom::MXP-F1-R105",
  "type": "physical.room",
  "name": "Floor 1 Server Room 105",
  "provider": {
    "name": "custom",
    "type": "Server Room",
    "native_id": "MXP-F1-R105",
    "namespace": "osiris.com.acme"
  },
  "properties": {
    "room_number": "105",
    "room_sqft": 600,
    "room_type": "server",
    "cooling_capacity_tons": 25,
    "fire_suppression": "FM-200",
    "access_control": true
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "building": "01",
    "floor": "1"
  }
}

Racks

Type: physical.rack

Definition: A rack is a standardized equipment enclosure (typically 19-inch or 23-inch wide) that houses servers, network devices, storage and other infrastructure hardware. Racks are measured in rack units (U).

When to use: Use physical.rack for:

• Data center equipment racks
• Network equipment cabinets
• Server enclosures

Common properties:

Example:

{
  "id": "schneider::MXP-F1-R01",
  "type": "physical.rack",
  "name": "Floor 1 Rack 01",
  "provider": {
    "name": "schneider",
    "type": "NetShelter SX 42U",
    "native_id": "MXP-F1-R01"
  },
  "properties": {
    "height_units": 42,
    "width_inches": 19,
    "depth_inches": 42,
    "manufacturer": "APC",
    "model": "NetShelter SX",
    "max_weight_lbs": 3000,
    "power_capacity_kva": 20
  },
  "status": "active",
  "location": {
    "datacenter": "MXP",
    "building": "01",
    "floor": "1",
    "room": "105",
    "row": "A",
    "position": "01"
  }
}

7.7 Type selection guidance

This section provides practical guidance for choosing appropriate resource types and understanding when to use standard types versus custom types.

7.7.1 Choosing appropriate types

Decision framework: When assigning a type to a resource, follow this decision tree:

1. Does a standard type exist that accurately describes this resource?

   • YES > Use the standard type (sections 7.2–7.6)
   • NO > Continue to step 2

2. Is there a closely related standard type?

   • YES > Consider using the standard type with vendor specifics in properties
   • NO > Continue to step 3

3. Is this a vendor-specific resource with no standard equivalent?

   • YES > Use osiris.<vendor>.<type> namespaced type
   • NO > Use osiris.<organization>.<type> for organization-specific resources

Semantic alignment: Choose the type that best represents the resource’s role and function, not its implementation details:

Good: compute.vm (even if it's a bare-metal instance acting like a VM)
Bad: osiris.aws.ec2.metal (overly specific)

Good: network.loadbalancer (for any load balancer)
Bad: network.alb, network.nlb.kemp (too vendor-specific)

Good: building.hvac.ahu (for any air handler)
Bad: milanmxp.keller.21c (building specific equipment model, not function)

Balancing generals and specifics:

• Prefer general types when the resource fits a common category
• Use specific subtypes when meaningful distinctions exist (e.g. compute.vm.template vs compute.vm)
• Avoid excessive depth - if the type hierarchy exceeds 4 segments, consider whether details belong in properties

Examples:

7.7.2 When to use custom types

Use custom types when:

1. No standard type exists

   • The resource represents a vendor-specific service with unique semantics
   • Example: osiris.aws.lambda.edge for Lambda@Edge (distinct from standard Lambda)

2. Semantics differ significantly

   • Standard type exists but doesn’t capture critical distinctions
   • Example: osiris.azure.cosmosdb for CosmosDB if multi-model API selection is critical

3. Vendor-specific features are essential

   • Preserving vendor identity is important for consumers
   • Example: osiris.vmware.vsan for vSAN storage (specific to VMware ecosystem)

4. Organization-specific resources

   • Internal infrastructure components
   • Example: osiris.com.acme.widget for proprietary equipment

Namespace guidelines:

Documentation: When using custom types, producers SHOULD:

• Document the type semantics in generator documentation
• Provide examples showing typical usage
• Explain why standard types were insufficient
• Version the generator tool if type semantics change

7.7.3 Type mapping examples from well-known providers

This section provides guidance for mapping common provider resources to OSIRIS standard types.

Provider naming: The examples below use canonical provider names as defined in Chapter 4, section 4.3.3. Producers SHOULD use consistent lowercase identifiers (e.g. aws, azure, gcp, oci, ibm, ali, tc) for well-known providers.

AWS Resource mappings

Microsoft Azure Resource mappings

Cloudflare Resource mappings

Google Cloud Platform (GCP) Resource mappings

Oracle Cloud Infrastructure (OCI) Resource mappings

IBM Cloud Resource mappings

Alibaba Cloud Resource mappings

Tencent Cloud Resource mappings

VMware vSphere Resource mappings