Release OSIRIS JSON Format Specification v1.0.0

Author: skhell

CODE_OF_CONDUCT.md

@@ -1,59 +1,77 @@
 # CODE_OF_CONDUCT.md
 
 ## Our commitment
-We want a community that is welcoming, inclusive and safe for everyone regardless of experience level, identity, background, or viewpoints. We value collaboration, clarity, and respect.
+We are committed to building a community that is welcoming, inclusive and intentionally safe for everyone regardless of experience level, identity, background, or viewpoints. **We value collaboration, clarity, and respect.**
 
+### Diversity, equity & inclusion
+We are committed to an inclusive, intentionally safe community. We respect and encourage participation from people of all backgrounds and identities. This includes (but is not limited to):
 
-## Scope
-This Code of Conduct applies in all project spaces (issues, PRs, discussions, chat, events) and also when someone represents the project in public spaces.
+- LGBTQIA+ people
+- People of all races, ethnicities, nationalities, and cultures
+- People with disabilities and neurodivergent people
+
+Harassment, discrimination and hate **have zero place** in this OSIRIS community. **We enforce this Code of Conduct and prioritize community safety.**
 
 
+## Scope
+This Code of Conduct applies in all project spaces (issues, pull requests, discussions, chat, events) and also in public spaces when someone represents the project.
+
 ## Expected behavior
 Please:
+
 - Be respectful and considerate in words and actions
 - Assume good intent and seek clarification before escalating
 - Give constructive feedback; focus on the work, not the person
-- Be mindful of tone—text is easy to misread
+- Be mindful of tone—text is easy to misread specially when conversation involve different races, ethnicities, nationalities, and cultures
 - Respect differing viewpoints and lived experiences
-- Follow project guidelines (including CONTRIBUTING.md)
-
+- Follow project guidelines (including [CONTRIBUTING](https://github.com/osirisjson/osiris/tree/main/CONTRIBUTING.md))
 
 ## Unacceptable behavior
 Examples include:
+
 - Harassment, discrimination, or hateful language
 - Personal attacks, insults, or deliberate intimidation
 - Sexualized language or unwelcome sexual attention
 - Doxxing or sharing private information without consent
 - Threats of violence or encouragement of self-harm
 - Persistent disruption, trolling, or bad-faith participation
 - Spamming the project with low-effort issues/PRs (including mass AI-generated noise)
-
+- Unsolicited advertising or self-promotion, including company marketing, referral links, SEO content, press releases, or “buy my product” messages unrelated to the project
+- Link phishing/spam (repeatedly posting promotional sites, Discord/Telegram servers, newsletters, or other services and applications)
+- Recruiting or sales outreach to community members (e.g. DMs or “let’s hop on a call” pitches) without prior consent
+- Astroturfing or coordinated promotion (e.g. fake endorsements, sockpuppets, review brigading)
 
 ## Enforcement
-Project maintainers may take any action they deem appropriate, including:
+Project maintainers may take any action they deem appropriate to protect the community and the project, including:
+
 - Private warning
 - Request for changes/remediation
-- Temporary ban from discussions or contributions
-- Closing or reverting contributions
+- Temporary restrictions (limits on participation or a time-limited ban)
+- Closing, hiding, or reverting contributions
 - Permanent ban
 
 When possible, enforcement aims to be:
+
 - Proportionate to impact
 - Consistent
 - Focused on restoring a healthy, productive environment
 
-
 ## Enforcement guidelines (impact-based)
 Maintainers may use an escalating response depending on severity:
 
-1. **Correction** — Clarify expectations; request change in behavior.
-2. **Warning** — A formal warning; continued behavior may lead to restrictions.
-3. **Temporary restrictions** — Time-limited ban or limits on participation.
-4. **Permanent action** — Removal from the community/project spaces.
+- **Correction** — Clarify expectations; request a change in behavior.
+- **Warning** — A formal warning; continued behavior may lead to restrictions.
+- **Temporary restrictions** — Time-limited ban or limits on participation.
+- **Permanent action** — Removal from the community/project spaces.
 
+## Reporting
+If you experience or witness unacceptable behavior, please report it privately to the maintainers.
 
-## Attribution
-This Code of Conduct is inspired by the Contributor Covenant (commonly used in open source communities).
-You can find it here:
+- Preferred: open a private report to maintainers (e.g. via GitHub)  
+- Optional: email the maintainers at **community@osirisjson.org**
+
+Reports are handled as confidentially as possible, and we will take action when needed.
 
-- https://www.contributor-covenant.org/version/2/1/code_of_conduct/
+## Attribution
+This Code of Conduct is inspired by the Contributor Covenant (commonly used in open source communities):  
+https://www.contributor-covenant.org/version/2/1/code_of_conduct/

CONTRIBUTING.md

@@ -1,5 +1,5 @@
 # CONTRIBUTING.md
-Thanks for your interest in contributing to OSIRIS! This project is maintained by volunteers; please help keep the signal high and the workload sustainable.
+OSIRIS is developed in public and warmly welcomes contributions of any size: questions, clarifications, examples, reviews and tooling improvements. As an open source project, we believe in giving back to our contributors and are happy to help with guidance on PRs, technical writing and turning any feature idea into a reality.
 
 ## Quick principles
 - **Quality > volume.** A few well-scoped contributions beat many low-impact issues/PRs.
@@ -8,37 +8,39 @@ Thanks for your interest in contributing to OSIRIS! This project is maintained b
 
 ---
 
-## Ways to contribute
-### 1. Improve docs (high impact)
-- Fix unclear sections that block users
-- Add examples that are minimal, correct and validated
-- Add diagrams or troubleshooting notes
-
-### 2. Report bugs (actionable issues only)
-Before opening an issue:
-- Search existing issues/PRs first
-- Confirm it’s reproducible on the latest version (or `main`)
-- Reduce to a minimal reproducible case
-
-**A good bug report includes:**
-- What you expected to happen
-- What actually happened (include exact error output)
-- Steps to reproduce (minimal)
-- Environment (OS, versions, runtime, etc.)
-- Any relevant logs/config/files (redact secrets)
-
-### 3. Propose enhancements
-For anything non-trivial, open a discussion first (or an issue) that includes:
-- Problem statement
-- Why it matters (who benefits / what pain it removes)
-- Proposed solution(s)
-- Tradeoffs and alternatives
-
-### 4. Code contributions
-- Pick an existing issue or open one first for alignment
-- Keep PRs small and focused (one concern per PR)
-- Add/update tests where applicable
-- Update docs/examples if behavior changes
+## What you can contribute
+### Documentation (recommended starting point)
+Documentation improvements are always valuable and usually the fastest to review:
+- fixing typos and broken links
+- clarifying wording where the spec is ambiguous
+- improving explanations and navigation between pages
+- expanding “how to validate” or “how to read an OSIRIS document” guidance
+
+
+### Examples
+You can contribute by:
+- proposing new example scenarios
+- improving readability and consistency of existing examples
+- adding comments or accompanying notes that help readers understand why certain fields are present
+
+### Specification and schema
+For spec/schema-related contributions:
+- open an issue describing the change and motivation
+- include a minimal example that demonstrates the problem
+- propose the smallest change that preserves compatibility
+
+## How to keep contributions easy to review
+- Prefer small, focused PRs.
+- Avoid mixing unrelated changes (e.g., refactor + new feature in the same PR).
+- Keep language precise (normative statements should use MUST/SHOULD/MAY only where appropriate).
+- If a change could affect compatibility, call it out explicitly in the PR description.
+
+## Contributors
+This project is currently maintained by a single lead maintainer. Contributors will be listed here and in the maintainer page over time.
+
+## Code of Conduct
+Participation in the OSIRIS community is governed by the Code of Conduct.  
+[Read the Code of Conduct](https://github.com/osirisjson/osiris/tree/main/CODE_OF_CONDUCT.md)
 
 ---
 

README.md

@@ -1,32 +1,46 @@
-# OSIRIS JSON Format Specification
+# OSIRIS JSON format specification
 OSIRIS (Open Standard for Infrastructure Resource Interchange Schema) defines a vendor-neutral JSON format for describing infrastructure resources, their properties and their topological relationships across heterogeneous IT and OT environments.
 
-OSIRIS is designed to normalize infrastructure data exported from diverse domains, including public hyperscalers, cloud platforms, private Data Centers, network devices, virtualization platforms and where applicable Operational Technology (OT) assets. OSIRIS focuses on describing what exists and how it relates, enabling cross-platform visibility and portable consumption by tools without requiring consumers to implement vendor-specific parsers.
+---
 
-OSIRIS is an interchange schema and is not intended to be:
-- A real-time monitoring or telemetry protocol
-- An infrastructure-as-code deployment language
-- A configuration management system
+## The challenge
+Modern infrastructure spans multiple stacks and providers: hyperscalers (AWS, Azure, GCP etc.), public clouds providers, on-prem datacenters, hybrid networks and complex OT environments integration.
 
-Instead, OSIRIS is optimized for interchange scenarios where infrastructure topology must be communicated between systems: 
-- generating high quality documentation
-- producing accurate diagrams
-- feeding CMDBs, IPAMs or DCIMs
-- supporting audit workflows
-- enabling cross-platform analytics
+While some platforms export inventories (often as JSON), the representations are inconsistent across vendors even for equivalent concepts like identity, properties and relationships.
+Accurate topology documentation is expensive and fragile. Teams rely on partial, inaccurate documentation and hand-drawn diagrams. Critical context lives in people's heads.
 
-By providing a stable interchange schema, OSIRIS allows the ecosystem to develop reusable parsers (vendor > OSIRIS) and consumers (OSIRIS > application-specific models) independently as an Open Standard, fostering interoperability and reducing duplicate and complexity effort.
 
+## The solution
+OSIRIS normalizes exports from hyperscalers and cloud providers, on-prem datacenters (compute, storage, network) and supports OT inclusion where applicable (initial v1.0 scope).
+Designed for cross-platform visibility and portable consumption by tools (diagramming, inventory, audit) without requiring each consumer to implement vendor-specific parsers.
 
-## What problem this solves
-The modern infrastructure landscape span multiple technology stacks and providers, including hyperscalers and continuously evolving private and public cloud platforms, on-premises data centers featuring compute virtualization platforms, storage and network systems and continuously increasing OT integration. While many systems started offering a comprehensible export format for resource inventories and configurations, the exported representations differ significantly across vendors and products, even when JSON is used. In OT environments the gap is even bigger due to legacy systems and vendor specific protocols.
+---
 
-The absence of a vendor-neutral interchange format means the infrastructure management ecosystem lacks a common language and producing a comprehensible hybrid cross-platform view typically requires bespoke translation layers that are costly to build and difficult to sustain.
+## Design principles
+OSIRIS is a static snapshot interchange format. It captures what exists and how it relates at a point in time. It was not designed as a real-time monitoring system, a deployment tool, or an Infrastructure-as-Code engine.
+
+#### What OSIRIS IS
+Optimized for scenarios where documentation and topology must be exchanged between systems and teams.
+
+- **Reliable, flexible infrastructure snapshots**
+Capture “what exists” and “how it relates” at a point in time.
+
+- **Documentation-ready outputs**
+Enable consistent inventories, technical summaries and system context.
+
+- **Diagram-friendly topology**
+Provide normalized relationships for automated visualization and diagram generation.
+
+- **Feeding CMDB / IPAM / DCIM workflows**
+Export normalized data into systems of record and asset management tools.
+
+- **Audit support**
+Assist evidence collection and traceability by standardizing structure and relationships.
 
 
 ## Get started
-Visit https://osirisjson.org/en/get-started for more informations
+Visit https://osirisjson.org/docs for more informations.
 
 
 ## Contribute
-Visit https://osirisjson.org/en/get-involved for more informations
+OSIRIS is developed in public and warmly welcomes contributions of any size, visit https://osirisjson.org/docs/en/get-involved/community for more informations.

specification/v1.0/CHANGELOG.md

@@ -1,6 +1,14 @@
 # Changelog
 All notable changes to this project will be documented in this file.
 
+# [1.0.0] - 2026-02-01
+### Updated
+- Specification to Stable release
+- README
+- CODE_OF_CONDUCT
+- CONTRIBUTING
+
+
 # [1.0.0-draft.17] - 2026-01-30
 ### Added
 - Appendices (A-D)

specification/v1.0/OSIRIS-JSON-v1.0.md

@@ -2,10 +2,10 @@
 | Field     | Value |
 | --------- | ----- |
 | Authors   | Tia Zanella [skhell](https://github.com/skhell) |
-| Revision  | 1.0.0-DRAFT |
+| Revision  | 1.0.0 |
 | Creation date      | 14 December 2025 |
-| Last revision date | 30 January 2026 |
-| Status    | Draft |
+| Last revision date | 01 February 2026 |
+| Status    | Stable |
 | Specification ID | OSIRIS-1.0 |
 | Schema URI | [OSIRIS-1.0](https://osirisjson.org/schema/v1.0/osiris.schema.json) |
 | License   | [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) |
@@ -1355,7 +1355,7 @@ Metadata objects **SHOULD** be concise. Large amounts of auxiliary data (e.g. fu
   "timestamp": "2025-12-18T14:30:00Z",
   "generator": {
     "name": "osiris-aws-parser",
-    "version": "2.1.0"
+    "version": "1.0.0"
   },
   "scope": {
     "name": "Production multi Hyperscalers topology",
@@ -1378,7 +1378,7 @@ Metadata objects **SHOULD** be concise. Large amounts of auxiliary data (e.g. fu
   "timestamp": "2025-12-18T14:30:00Z",
   "generator": {
     "name": "osiris-aws-parser",
-    "version": "0.9.0"
+    "version": "1.0.0"
   },
   "scope": {
     "name": "Hybrid production topology",