10 Examples

This chapter references complete, validated examples in the OSIRIS repository. All examples are available at:

https://github.com/osirisjson/osiris/tree/main/examples/v1.0

Each example is:

• Validated against the OSIRIS v1.0 schema
• Illustrative and intended to be schema-valid for testing and reference
• Informative where examples conflict with the specification, the specification is authoritative.

10.1 IT Minimal Cloud Provider infrastructure

10.1.0 Overview

This example demonstrates the absolute minimum valid OSIRIS document for a cloud provider. Showcasing alternative example of cloud platforms beyond the major hyperscalers.

It showcases:

• Minimal valid document for cloud provider
• Alternative cloud provider representation
• Simple droplet with required fields only
• Different provider naming and ID format

10.1.1 Scenario

A simplest cloud infrastructure on DigitalOcean:

• Single droplet (virtual machine)
• Provider specific ID format
• NYC3 region
• Used for: demonstrating non-hyperscaler providers, validation testing

10.1.2 Example

View

10.1.3 Key features demonstrated

Cloud provider:

• DigitalOcean instead alternative of major hyperscalers
• Shows OSIRIS supports any cloud platform
• Provider specific ID format

Use cases:

• Starting point for DigitalOcean infrastructure
• Template for other cloud providers
• Validation testing

10.2 IT Minimal Hyperscaler infrastructure

10.2.0 Overview

This example demonstrates the absolute minimum valid OSIRIS document for hyperscaler infrastructure. It represents a single virtual machine with minimal required fields, serving as the simplest possible starting point.

It showcases:

• Minimal valid OSIRIS document structure
• Single resource with only required fields
• Essential provider attribution
• Bare minimum metadata

10.2.1 Scenario

The simplest possible cloud infrastructure representation:

• Single EC2 instance (or equivalent VM)
• Required fields only (id, type, provider)
• Minimal metadata (timestamp only)
• No connections or groups
• Used for: testing, validation, learning the basic structure

10.2.2 Example

View

10.2.3 Key features demonstrated

Absolute minimum fields:

• Document structure: version, metadata, topology
• Resource minimum: id, type, provider
• Provider minimum: name only
• Metadata minimum: timestamp only

Use cases:

• Learning OSIRIS basics
• Testing schema validators
• Template for new documents
• Demonstrating required vs. optional fields

10.3 IT Simple Hyperscaler infrastructure

10.3.0 Overview

This example demonstrates a basic three-tier web application running entirely in AWS.

It showcases:

• Simple resource topology (compute, database, load balancer)
• Basic connection types (dependency, route)
• Standard cloud provider attribution
• Minimal but complete metadata

10.3.1 Scenario

A production web application with:

• Application Load Balancer (public-facing)
• EC2 instance running the web application
• RDS PostgreSQL database
• Direct dependencies: ALB > EC2 > RDS

10.3.2 Example

View

10.3.3 Key features demonstrated

Resource diversity:

• Network resource (load balancer)
• Compute resource (EC2 instance)
• Application resource (database)

Provider attribution:

• Consistent AWS provider naming
• Native type mapping (AWS::EC2::Instance)
• Regional and account context

Connections:

• route type for traffic flow (ALB > EC2)
• dependency type for application relationship (EC2 > RDS)
• Directional semantics with forward

Properties:

• Network configuration (IPs, VPCs, subnets)
• Instance specifications (type, image, platform)
• Database configuration (engine, storage, endpoint)

10.4 IT Hyperscaler infrastructure belonging with Resource Group and VNet membership

10.4.0 Overview

Hyperscaler environments often have hierarchical containers (e.g. Azure Resource Groups, GCP Projects, AWS VPCs). OSIRIS can represent this belonging using groups (recommended for inventory/reporting) without requiring traversal semantics.

10.4.1 Scenario

This example represents a multi-hyperscaler environment where infrastructure resources originate from different providers (e.g. AWS, Azure, GCP) but are described in a single OSIRIS document.

It demonstrates:

• How a single topology can include heterogeneous resources across multiple providers.
• How cross-provider dependencies can be expressed using explicit connections.
• How cloud “ownership / belonging” containers (e.g. Resource Groups, Projects, VPC/VNet) can be represented for documentation purposes.

10.4.2 Example

View

10.4.3 Key features demonstrated

• Multi-provider attribution: resources include provider.name and native identifiers to preserve provenance and correlation.
• Cross-provider topology: connections can link resources even when they come from different vendors or platforms.
• Belonging or ownership modeling: hierarchical cloud containers (e.g. Azure Resource Group, GCP Project, AWS VPC or Azure VNet) can be represented using:
  • Groups (recommended for inventory/reporting and documentation)
  • contains connections (recommended when containment must be traversed as topology).
• Forward compatibility: consumers can ignore unknown resource fields and extension namespaces while still loading the document.

10.5 IT Multi-Hyperscalers environment

10.5.0 Overview

This example demonstrates infrastructure spanning AWS and Azure, showcasing:

• Multiple cloud providers in a single topology
• Cross-cloud resource relationships
• Provider-specific native types
• Unified representation of diverse infrastructure

10.5.1 Scenario

A distributed application with:

• Azure front-end (App Service)
• AWS compute tier (EC2)
• Azure database (SQL Database)
• Cross-cloud dependencies and data flows

10.5.2 Example

View

10.5.3 Key features demonstrated

Multi-provider resources:

• Azure resources (App Service, SQL Database, Redis)
• AWS resources (EC2)
• Mixed provider types in single topology

Cross-cloud connections:

• Azure > AWS dependency (frontend to API)
• AWS > Azure dependency (API to database)
• Demonstrates cloud interconnection patterns

Provider diversity:

• Azure native IDs use ARM resource paths
• AWS native IDs use standard format
• Provider-specific properties maintained

Complex relationships:

• Multiple connection paths
• Shared resources (Redis accessed by both frontend and API)
• Bidirectional connections for cache access

10.6 IT Hybrid infrastructure on Hyperscaler and On-Premise

10.6.0 Overview

This example demonstrates a hybrid environment combining cloud and on-premise infrastructure:

• AWS cloud resources
• Physical on-premise servers (MXP datacenter)
• Custom provider for on-premise equipment
• Hybrid connectivity and dependencies

10.6.1 Scenario

An enterprise hybrid deployment:

• AWS public cloud for web tier
• On-premise physical servers for legacy applications
• On-premise physical storage
• Hybrid connections (VPN, direct connect)
• Mixed virtualized and physical infrastructure

10.6.2 Example

View

10.6.3 Key features demonstrated

Hybrid topology:

• Cloud resources (AWS EC2, VPN)
• Physical on-premise servers (Dell R770)
• Physical storage infrastructure

Custom provider usage:

• provider.name: "custom" for on-premise equipment
• Required namespace field with reverse-domain notation
• Custom provider for equipment not from standard cloud vendors

Physical infrastructure details:

• Complete hardware specifications (CPU, memory, storage)
• Physical location (datacenter, rack, rack unit)
• Serial numbers and asset tags

Hybrid connectivity:

• VPN connection bridging cloud and on-premise
• Connections spanning environments

Grouping:

• Logical groups (cloud resources)
• Physical groups (datacenter site, rack)
• Hierarchical organization

10.7 IT Minimal On-Premise infrastructure

10.7.0 Overview

This example demonstrates the absolute minimum valid OSIRIS document for on-premise physical infrastructure. It represents a single physical server with custom provider attribution.

It showcases:

• Minimal valid document for on-premise equipment
• Custom provider with required namespace
• Physical server resource type (not virtual machine)
• Site-based identification pattern

10.7.1 Scenario

The simplest on-premise infrastructure representation:

• Single physical server in MXP datacenter
• Custom provider (non-cloud vendor)
• Required namespace field (osiris.it.mxp)
• Datacenter site attribution
• Minimal metadata (timestamp only)
• Used for: learning on-premise modeling, validation testing, template for datacenter exports

10.7.2 Example

View

10.7.3 Key features demonstrated

Custom provider requirements:

• provider.name: "custom" for non-cloud equipment
• Required namespace field with reverse-domain notation
• Format: osiris.{country}.{organization} or osiris.{com}.{company}
• Example: osiris.it.mxp ( This example use ICAO code, MXP is referred to a Datacenter located in Milan.)

Physical infrastructure:

• Resource type: compute.server (not compute.vm)
• Distinguishes physical hardware from virtual machines
• Appropriate for bare-metal servers

ID construction:

• On-premise format: site::identifier
• Site code: mxp (Milan datacenter)
• Identifier: server-01 (simple, human-readable)
• Pattern enables easy organization by datacenter

Site attribution:

• provider.site: Datacenter or facility identifier
• provider.native_id: Internal asset tracking number
• Enables correlation with DCIM systems

Use cases:

• Starting point for on-premise OSIRIS modeling
• Custom provider namespace validation
• Template for datacenter asset exports
• Demonstrating physical vs. virtual resources
• Asset management system integration

10.8 IT On-Premise Network topology

10.8.0 Overview

This example demonstrates detailed network infrastructure with:

• Physical network equipment (switches, routers)
• Detailed interface configurations
• Physical connectivity (fiber optics, copper)
• Network hierarchy and segmentation
• Complex connection properties

10.8.1 Scenario

A datacenter network spine-leaf architecture:

• Spine switches (high-capacity core)
• Leaf switches (server connectivity)
• Physical fiber connections between tiers
• Server network interfaces
• Detailed transceiver and cable specifications

10.8.2 Example

View

10.8.3 Key features demonstrated

Detailed network equipment:

• Switch specifications (Arista DCS-7050SX3-48YC12)
• Port configurations and capabilities
• Software versions (EOS 4.29.2F)
• Management information

Physical connectivity types:

• physical.fiber connections (100G QSFP28)
• physical.copper connections (10G SFP+)
• Different media types in same topology

Interface details:

• Source and target interface names
• Port numbers and types
• Transceiver specifications (vendor, part number, serial)
• Cable specifications (type, length, connector)

Network-specific properties:

• Layer 1 specifications (speed, duplex)
• VLANs and trunking
• Network bonding/teaming
• MTU configurations

Hierarchical grouping:

• Logical tiers (spine, leaf)
• Physical pods
• Nested groups (fabric containing layers)
• Network segmentation

10.9 OT Minimal infrastructure

10.9.0 Overview

This example demonstrates the absolute minimum valid OSIRIS document for Operational Technology (OT) infrastructure. It represents a single environmental sensor, showcasing the simplest OT device representation.

It showcases:

• Minimal valid OT document structure
• OT-specific resource type (ot.sensor.environmental)
• Custom provider for OT equipment
• Physical facility monitoring device
• Bridge between IT documentation and OT systems

10.9.1 Scenario

The simplest OT infrastructure representation:

• Single environmental sensor in MXP datacenter
• Temperature and humidity monitoring device
• Custom provider with namespace (non-IT vendor)
• Datacenter facility monitoring system
• No network connections shown (monitoring only)
• Used for: learning OT modeling, demonstrating IT/OT distinction, validation testing

Real-world context: Environmental sensors are ubiquitous in:

• Datacenters (temperature, humidity monitoring)
• Server rooms (thermal monitoring)
• Industrial facilities (environmental control)
• Building management systems (HVAC monitoring)
• Cold storage facilities (temperature tracking)

10.9.2 Example

View

10.9.3 Key features demonstrated

OT resource types:

• ot.sensor.environmental - Distinguishes OT from IT resources
• Operational Technology namespace (ot.*)
• Physical monitoring equipment
• Facility management systems integration

IT vs OT distinction:

• IT resources: compute.*, network.*, storage.*
• OT resources: ot.sensor.*, ot.camera.*, ot.access.*
• Clear domain separation
• Enables IT/OT convergence modeling

Minimal OT requirements:

• Smallest valid OT document
• Required fields: id, type, provider (with name and namespace)
• Custom provider for non-cloud OT vendors
• Site attribution for physical location

ID construction:

• OT format: site::device-identifier
• Site code: mxp (example of a datacenter location)
• Device identifier: sensor-temp-01
• Human-readable, location-aware naming

Use cases:

• Starting point for OT infrastructure modeling
• Template for building management systems
• Facility monitoring system exports
• Environmental monitoring integration
• IT/OT convergence documentation

10.10 OT Cross connection with IT Network

10.10.0 Overview

IT/OT network convergence with security segmentation:

• Separate IT and OT network segments
• Industrial firewall
• SCADA equipment
• Secure cross-segment connectivity

10.10.1 Scenario

• IT Zone: Enterprise servers, users
• OT Zone: SCADA, PLCs, HMI
• Firewall: Paloalto at boundary

10.10.2 Example

View

10.10.3 Key features demonstrated

• Zone-based segmentation
• Industrial firewall configuration
• SCADA/ICS equipment
• Security policies in connection properties
• Logical grouping by network segment

10.11 OT Industrial printer

10.11.0 Overview

Zebra ZT620 industrial printer connected to network infrastructure.

10.11.1 Scenario

Warehouse label printing:

• Thermal transfer printer
• Network connectivity
• Integration with WMS

10.11.2 Example

View

10.11.3 Key features demonstrated

• Industrial equipment specifications
• Network integration
• PoE considerations
• OT device on IT network

10.12 OT Security camera

10.12.0 Overview

IP security camera system with:

• Axis IP cameras
• Network Video Recorder (NVR)
• PoE network switches

10.12.1 Scenario

• Multiple cameras (entrance, server room)
• Central NVR for storage
• RTSP video streams

10.12.2 Example

View

10.12.3 Key features demonstrated

• PoE power requirements (class 4)
• Video stream specifications
• flow connection for RTSP streams
• NVR storage capacity

10.13 OT Door access control

10.13.0 Overview

Physical security access control system with:

• Access control panel/controller
• Door card readers
• Network-connected locks

10.13.1 Scenario

• ot.access.controller - Central panel
• ot.access.reader - Card/biometric readers
• ot.access.lock - Electronic door locks

10.13.2 Example

View

10.13.3 Key features demonstrated

• OT-specific resource types
• control connection type
• Physical location tracking
• Controller to reader relationships

10.14 Summary

About example generators

The examples in this repository include generator metadata showing hypothetical parser names. These parsers are planned for future development and do not yet exist in the v1.0 release.

Current Status: Examples are hand-crafted for documentation and validation.

Future Parsers: The OSIRIS project will begin developing reference parsers for well known hyperscalers and brands:

• AWS (osiris-aws-parser)
• Azure (osiris-azure-parser)
• Cloudflare (osiris-cloudflare-parser)
• GCP (osiris-gcp-parser)
• OCI (osiris-oci-parser)
• IBM (osiris-ibm-parser)
• Alibaba Cloud (osiris-ali-parser)
• Tencent Cloud (osiris-tc-parser)
• Proxmox (osiris-proxmox-parser)
• VMware (osiris-vmware-parser)
• Arista (osiris-arista-parser)
• Cisco (osiris-cisco-parser)
• Ciena (osiris-ciena-parser)
• Nokia (osiris-nokia-parser)

To create your own parsers follow the implementation guidelines on chapter 11.

10.14.1 Common patterns

ID construction:

• Hyperscaler and Cloud Providers: provider::native-id (e.g. aws::i-0abc123)
• On-premise: site::identifier (e.g. mxp::srv-r770-001)
• Consistent formatting across all examples

Provider attribution:

• Standard providers use lowercase names (aws, azure)
• Custom providers require namespace field
• Native types preserve vendor format (AWS::EC2::Instance)

Network Connection directionality:

• forward: Unidirectional flow (A > B)
• bidirectional: Symmetric relationship (A <-> B)
• reverse: Reverse flow (B > A)

Properties structure:

• Type-specific properties in properties object
• Vendor extensions in extensions object
• Labels and metadata in tags object