Beyond the silos: The soul behind OSIRIS JSON

For twenty years, my mission has been to bridge the gap between siloed tribal knowledge and operational clarity. I’ve evolved from the manual era of painstakingly mapping fragmented topologies to building a solution that delivers a comprehensive, end-to-end snapshot of the infrastructure landscape. My goal building OSIRIS JSON is simple: to provide the big-picture visibility that empowers IT and OT professionals to make the right decisions with confidence.

In the world of infrastructure, we often settle for fragments. We see a server here, a cloud instance there, a facility sensor somewhere else. But my goal, no matter with who and for who I have been working for, has always been to achieve an end-to-end view of the entire infrastructure, seeing how every piece breathes together in one interconnected map, this for a very simple reason to achieve multiple goals:

1. eradicate silos, feudal thinking and critical context living in people heads embracing open standard Documentation as Code (Docs as Code) culture
2. providing an easy way for architects and IT/OT professionals to understand end-to-end the infrastructure in a fast up-to-date state in time
3. allowing fast troubleshooting maintaining a clear up-to-date infrastructure documentation and topology
4. allowing fast snapshot in time end-to-end of the infrastructure without complications or third-party scanning softwares making OSIRIS JSON a great allies under audit sessions
5. provide an accurate standardized baseline for LLMs allowing to understand the infrastructure landscape providing enhanced reasoning and automation

The human side of the infrastructure struggle

In December 2025 with a big ambition and a bit of crazyness I began writing the OSIRIS JSON Specification. It is the result of the experience gained by travelling, exploring, entertaining conversations to Senior Managers, IT/OT professionals, but also by getting closer and work with factory workers and their managers with whom I had a great opportunity to learn about different contexts that enriched me personally and helped shape the original idea by having the opportunity to see and understand that also this type of organization and visibility was lacking not just in the Information Technology area but also in the OT side under facility systems or in cross-scenarios and even in designing, maintaining, and sometimes failing within heterogeneous stacksfrom hyperscale public clouds to the complex, gritty intersections of IT and Facility OT.

Throughout this journey, I’ve encountered a recurring, deeply human problem: The impassable mountain of tribal knowledge. Some phrases everyone of us have been listening: Oh don’t touch that please we are aware it’s outdated but Karl made it and he left the company! Documentation is not important let’s focus on business needs or the false believe everything is fine All services are perfectly configured in Microsoft Azure nothing to be worried about. or you are called in an ARM or SBB approval meeting and somebody draw some lines in Microsoft Paint to represent the topology seeking for immediate approval because the stakeholders are in rush! Some weeks after when you are called to analyze with operations a major outage you discovered someone have misconfigured thing in the system architecture and you don’t know where to start troubleshoot because there is not accurate documentation or topology. All of us had or have a Karl in the organization.

We struggle against corporate silos that make a unified view feel nearly impossible! We build bespoke, fragile integrations that break the moment a vendor changes their mind, and we know specially in IT this happen on a regular basis.

Even in scenarios where I produced rigorous documentation, the presence of team silos often meant that the “truth” of the infrastructure remained hidden or fragmented. I realized that if we can’t see our world, we can’t truly care for it making the right decisions with confidence.

I firmly believe that the clarity of systems infrastructure MUST NOT depend on who you are, who you know or which department you sit in. It is and MUST be a shared truth that belongs to everyone. - Tia Zanella - Founder and Lead Maintainer of OSIRIS JSON

What is OSIRIS JSON?

OSIRIS JSON is a vendor-neutral JSON interchange schema designed to be a universal language for infrastructure topology designed to include IT and OT environments.

Rather than wasting time and money developing every software integrations from scratch to learn a hundred different vendor-specific dialects, OSIRIS JSON separates the responsibilities:

1. The OSIRIS JSON producers translate the messy, fragmented data of the real world into a clean OSIRIS JSON document.
2. The OSIRIS JSON consumers read that document to provide a clear, point-in-time view of what exists and how it all relates. With the OSIRIS JSON document the consumers can produce topologies, diff, high quality automated documents and more.

A humble first step

In this first release, OSIRIS JSON is intentionally a static snapshot format. It is a “digital polaroid” of your infrastructure a moment in time. You can run directly from your notebook or in complex scenario demand it to an automation to produce scheduled results. It doesn’t try to do everything at once, but it provides something essential: a consistent foundation. By defining how resources and their relationships are documented regardless of team boundaries or vendor lock-in. In an open community culture we take the first step toward that end-to-end dream.

OSIRIS JSON is more than code; it is a perseverance commitment to transparency, high quality documentation and the firmly belief that even the most complex systems can be understood if we wear the right glasses.

Tia Zanella - Founder and Lead Maintainer of OSIRIS JSON