After years of dealing with incompatible infra exports I created and published OSIRIS v1.0.0 a vendor-neutral JSON interchange format for point-in-time infrastructure snapshots and documentation: highlighting resources and their relationships (topology diagram), with an extension mechanism that can cover OT environments as well.
Project: https://osirisjson.org/
Schema: https://osirisjson.org/schema/v1.0/osiris.schema.json
Examples: https://osirisjson.org/docs/en/osiris-examples/01-it-infrastructure
The recurring problem
If you’ve ever tried to build tooling around infrastructure data (diagramming, inventory, audit, drift/diff, documentation), you’ve likely seen the same issue:
- Every vendor exports data differently (even when it’s JSON).
- Every tool ends up writing its own parsers and mappings, most of them if not all are closed source.
- Relationships (what is connected to what, where it lives, how it depends) are the first thing that becomes inconsistent or implicit.
- Over time, you either rebuild integrations repeatedly, or you rely on undocumented tribal knowledge that lives in people heads and most of time not so well organized so you receive vague answers to your infinite questions.
The result is fragmented, tool-specific pipelines that are expensive to maintain and cause you lot of pain to have a single point of view of the infrastructure.
What OSIRIS is
OSIRIS is a vendor-neutral JSON format for describing infrastructure resources and their topological relationships across heterogeneous IT and OT environments. OSIRIS generate a static snapshot interchange format.
A snapshot describes:
- what exists (resources)
- how it relates (connections / relationships)
- at a specific time (point-in-time)
It is designed to be:
- vendor-neutral (the schema is the contract)
- tool-friendly (consumers don’t need vendor-specific parsers)
- extensible (namespaced extensions for vendor or domain-specific fields, including OT)
What OSIRIS is not (in v1.0.0)
OSIRIS is not:
- infrastructure-as-Code
- configuration management
- telemetry/metrics/streaming events
It’s a format you can export, validate, store, diff and consume.
Producer/Consumer split (the key idea)
Instead of every tool implementing every vendor format, OSIRIS separates responsibilities:
- Producers translate source data into OSIRIS documents (hyperscalers or public cloud providers inventory APIs, network device outputs, OT gateways, CMDB exports, etc.)
- Consumers read OSIRIS documents (diagram generators, inventory platforms, auditors, diff tools, documentation systems)
This keeps vendor-specific logic in one place and allows multiple tools to share the same snapshot format.
What’s included today
- Specification & documentation: https://osirisjson.org/
- Canonical core JSON Schema (v1.0): https://osirisjson.org/schema/v1.0/osiris.schema.json
- Examples: https://osirisjson.org/docs/en/osiris-examples/01-it-infrastructure
- A validation approach that starts with schema-level validation, leaving room for richer semantic validation later.
What I’d love feedback on
If you work with infra data, I’d appreciate critiques on:
1) Core model: Are “resources + relationships” sufficient and ergonomic for real topologies?
2) Extensibility: Is the extension/namespacing approach practical and future-proof?
3) Adoption path: Which first producer would be most useful to you (cloud inventory, device CLI, Terraform state, etc.)?
What’s next
I’m working on:
- development guidelines for contributors
- initial core/SDK work to make producers and consumers easier to build
If you want to review the spec/schema or suggest a first producer target, comments are welcome.
OSIRIS: https://osirisjson.org/
Top comments (0)