2026 roadmap
OSIRIS is an Open Standard and a static snapshot format for describing infrastructure resources and their topological relationships at a point in time. This roadmap focuses on shipping a usable MVP first (spec + website), then building tooling and producers that generate and validate OSIRIS documents.
[!Info] Single-maintainer reality OSIRIS launched in February 2026 at the moment is currently maintained by a solo developer. Milestones are best-effort and may shift as the specification stabilizes and community input arrives.
Guiding priorities
- Spec-first stability: keep v1.0 coherent and evolve it using SemVer and the compatibility rules in the specification.
- Producer/consumer separation: build producers (source > OSIRIS) and consumers/tooling (OSIRIS > validation/usage) to reduce integration complexity.
- In-scope domains first: prioritize core IT domains (hyperscalers, public cloud providers, network, compute, storage, virtualization) with initial OT support where integration matters.
2026 delivery plan
Documentation, specification and website
- OSIRIS v1.0 specification published under
/spec/v1.0 - Schema reference and validation guidance (JSON Schema + rules)
- Public examples library (IT + OT) aligned to v1.0
- Core community pages (Code of Conduct, governance, maintainers)
OSIRIS is designed for interchange scenarios such as documentation, diagramming, inventories, and audit evidence.
Toolbox + On-prem producers
- OSIRIS Toolbox (initial): CLI + VS Code extension + validators + SDK baseline
- Validation: Level 1 (schema) and Level 2 (semantic) checks as primary workflow
- Cisco producer (initial): exporter/translator producing OSIRIS snapshots from Cisco network sources
- Arista producer (initial): exporter/translator producing OSIRIS snapshots from Arista networks sources
Producers and consumers have explicit responsibilities in OSIRIS and validation is a core interoperability requirement.
AWS + Azure producers
- AWS producer: generate OSIRIS documents from AWS inventories/topology sources
- Azure producer: generate OSIRIS documents from Azure inventories/topology sources
- Toolbox improvements driven by real producer output (diff/merge workflows, reporting)
OSIRIS enables cross-platform topology snapshots and comparison over time by using stable IDs and explicit relationships.
GCP + Cloudflare producers
- GCP producer: generate OSIRIS documents from GCP inventories/topology sources
- Cloudflare producer: generate OSIRIS documents from Cloudflare inventories/topology sources
- More examples derived from real producer runs (reference snapshots)
Consumers must remain forward-compatible by accepting unknown fields/types/namespaces and preserving extensions.
Cross-cutting work throughout 2026
verified Interoperability hardening
- Compatibility tests across v1.x releases (keep v1.0 documents valid within v1.x)
- Clear deprecation markers and migration guidance when needed
OSIRIS defines SemVer, forward-compatibility rules, and a deprecation lifecycle.
extension Extension ecosystem hygiene
- Document namespace guidance and recommended patterns for vendor/org extensions
- Encourage “standard types first”, extensions only when needed
Producers should prefer standard types and use extensions for vendor/org-specific data.
How to influence the roadmap
If you want to propose changes (new types, new producers, clarifications), join the discussion with:
Join the community to discuss.