Introducing KIT 2.0 Architecture - A New Era of Dataspace Innovation
Hello Tractus-X community,
We are excited to announce the launch of KIT 2.0 Architecture - a major redesign of how we visualize and organize our KIT ecosystem. This update brings a fresh perspective to understanding the layered architecture of Eclipse Tractus-X, making it easier than ever to explore and navigate our comprehensive collection of KITs.
What is a KIT?
KIT, short for Keep It Together, is an open-source toolbox with comprehensive documentation that enables multiple stakeholders (Business, Solution Providers, Developers) to build interoperable applications compatible with the Eclipse Tractus-X dataspace technologies, and support the compliance with industrial standards from standarization organizations (Catena-X e.V., IDTA, ISO/DIN, EDWG, Manufacturing-X, etc.) and in some cases enable regulatory compliance.
A KIT provides everything needed to implement and deploy specific business scenarios within a dataspace environment - from architectural guidance and API specifications to reference implementations and operational procedures. Each KIT serves as a complete, self-contained package that enables developers, operators, and business stakeholders to understand, build, and run solutions that are interoperable across the dataspace network.
What's New in KIT 2.0 Architecture?
The KIT framework has evolved significantly from version 1.0 to 2.0 to support the growing needs of multiple dataspaces and industries. This transition represents a fundamental shift in how we approach dataspace interoperability - moving from a single-industry focus to enabling multiple industries to leverage the same foundational technologies while maintaining the flexibility to address industry-specific requirements through modular extensions.
KIT 1.0
LegacySingle-industry focused approach designed specifically for the Catena-X automotive dataspace.
KIT 2.0
CurrentMulti-dataspace, multi-industry approach supporting diverse ecosystems including Manufacturing-X and beyond.
Interactive Hexagonal Design
The new architecture features a beautiful hexagonal layout that visually represents the four main layers of our KIT ecosystem:
Click in the architecture components to see a personalized views! Or continue scrolling if you want to know more!
Our KITs Architecture
Building the foundation for interoperable solutions across industries
Modular Reusable Architecture
Here is a detailed explana of the diagram above, and how this architecture improves reusability:
The network basis for industrial dataspaces, providing core components required for maintaining interoperability. These KITs ensure secure, sovereign data exchange using dataspace technology - exchanging "bytes" without concern for specific data formats.
Common capabilities and standards shared across all use cases within any industry, enabling the new use cases of tomorrow. These KITs define core data models, digital twin concepts, and cross-functional services that enable building multiple use cases while maintaining interoperability and data consistency.
Business scenarios and challenges applicable across multiple industries. These KITs solve concrete problems related to sustainability, quality, supply chain management, and other horizontal concerns that span industry boundaries.
Specialized solutions tailored to unique challenges of particular industries. These include dedicated implementations for Automotive, Shop Floor, Semiconductor, Construction, Chemical, and other vertical domains with industry-specific regulatory requirements and specialized functionality.
Standardized KIT Development Process
With KIT 2.0, we've established a comprehensive framework and clear guidelines for creating and maintaining KITs. Our Tractus-X Release Guidelines (TRGs) provide a structured approach to KIT development, ensuring consistency, quality, and interoperability across all KITs.
TRG 10 - Keep it Together (KIT)
The TRG 10 series defines the complete lifecycle and requirements for KIT development:
Active TRGs (Necessary for the new Webpage Structure)
- TRG 10.01 - KIT Architecture: Defines the architectural categories and layered classification of KITs within the Eclipse Tractus-X ecosystem
- TRG 10.02 - KIT Structure: Specifies the required folder structure, documentation organization, and content requirements for each KIT
- TRG 10.03 - KIT Lifecycle: Outlines the maturity levels (Incubating, Stable, Deprecated) and the progression criteria for KITs
Draft TRGs (Coming Soon)
- TRG 10.04 - KIT Graduation Process (Draft): Details the process for KITs to move from incubating to graduated status
- TRG 10.05 - KIT Deprecation Process (Draft): Describes the deprecation process for KITs that are no longer maintained or relevant
KIT Master Data - Single Source of Truth
All KIT metadata is centralized in a single source of truth - the KIT Master Data Overview. This comprehensive registry contains:
- Metadata: Version numbers, last updated dates, maturity levels, and graduation dates
- Architecture Classification: Which layer each KIT belongs to (Dataspace Foundation, Industry Core, etc.)
- Dataspace Assignments: Which dataspaces each KIT supports (Catena-X, Manufacturing-X, etc.)
- Links & Resources: Routes to documentation, repositories, and related materials
- Lifecycle Status: Current state (Incubating, Graduated, Deprecated) and progression history
File Location is at the /data folder:
/data/kitsData.js
In this way, the development, creation and usage of KITs is streamlined, transparent and easier to maintain.
KIT Datamodel
There is a metadata datamodel for every KIT defined as follows:
{
id: '<unique-kit-id>', // Unique identifier for the KIT
name: '<KIT NAME IN UPPERCASE>', // Display name
logo: <KitLogoComponent>, // React SVG component
logoHeight: <number>, // Logo height in pixels
logoWidth: <number>, // Logo width in pixels
route: '<route-to-kit-adoption-view>', // Path to KIT documentation
colors: {
primary: '<hex-color>', // Primary brand color
gradient: 'linear-gradient(...)' // CSS gradient definition
},
maturity: {
currentLevel: '<level>', // 'Sandbox' | 'Incubating' | 'Graduated'
graduationStatus: '<status>', // 'draft' | 'in progress' | 'in review' (for Incubating only)
graduatedAt: '<YYYY-MM-DD>', // Date when graduated (only if Graduated)
deprecatedAt: '<YYYY-MM-DD>' // Date when deprecated (only if deprecated)
},
deprecated: <boolean>, // true | false
domain: '<domain-category>', // e.g., 'Sustainability', 'Engineering', 'Supply Chain'
industries: ['<industry-id>', ...], // Array of industry IDs (optional for foundation KITs)
description: '<kit-description>', // Short description of the KIT
metadata: {
created: '<YYYY-MM-DD>', // Creation date
lastUpdated: '<YYYY-MM-DD>', // Last update date
latestVersion: '<version>', // Current version (semantic versioning)
new: <boolean> // true if recently added
}
}
Additionally, there is a Datamodel for Industries and for Dataspaces defined in a similar manner, more information can be found clicking on the button below!
KIT Statistics - Insights into the KIT Ecosystem
Thanks to the master data, now we can also provide detailed KIT Statistics that give insights into the current state of the KIT ecosystem:
Key Statistics Preview
Architecture Distribution & Growth Trends
Thanks to this we can now monitor the growth and evolution of the KIT ecosystem over time, providing valuable insights into adoption trends and areas of focus. And knowing how is the state of life from the KITs evolving during each release.
KIT 2.0 Content Structure and Artifacts
Now it is defined a clear structure for the content and the views
| Views | Stakeholders | Content |
|---|---|---|
| Adoption View | Business | Business Value, Motivation, Vision, Mission, Whitepapers, Semantic Models, Standards, Tutorials, Explanations why this use case is important, Context |
| Development View | DevelopersArchitects | Overall Architecture, Reference Implementations, API specifications, Policies, Algorithms, Functional Requirements, Sequence Diagrams, Process, Architecture Guidelines |
| Operator View | OperatorsService Providers | Non-Functional Requirements, Security Requirements, Recommendations, Restrictions |
| Documentation | Any Stakeholder | Extra Documentation and Links |
| Success Stories | OperatorsService ProvidersBusiness | Success Stories from Reference Implementations that used this KIT. Open Source and COTS. |
| Industry Extensions | Dataspace Adopters | One Folder per Industry. Extends the contents from the other views with regards to a specific industry and affiliated dataspace standards/requirements |
In addition to the view-specific content above, every KIT must include:
- Copyright Notice - Mandatory CC-BY-4.0 licensing information and contributor copyright statements at every file
- Changelog - Version history file following semantic versioning
And depending from what is available a KIT will position itself in one or another lifecycle level:
KIT Lifecycle
Understanding the KIT lifecycle is crucial for contributors and users alike. Each KIT in the Tractus-X ecosystem follows a structured maturity progression that ensures quality, completeness, and real-world validation before reaching production readiness.
The Three Maturity Levels
KITs progress through three distinct lifecycle stages, each with specific requirements and validation criteria:
Sandbox Level
The Sandbox level is the entry point for new KIT ideas. At this stage, the focus is on establishing a clear vision, mission, and business value proposition. This level serves as a preview of potential business innovation and allows for community feedback and validation.
- Conceptual phase with defined vision and scope
- Community interest validation
- Basic problem definition and domain identification
- Foundation for future development
- No strict standards mandatory, just a clear business vision
Incubating Level
Incubating represents the active development phase where KITs evolve from concept to functional implementation. This level includes three distinct sub-states that provide clear progression milestones:
- Draft: Initial development and structure setup, basic artifact creation
- In Progress: Active implementation, full artifact development, and testing
- In Review: Quality assurance, peer review, and compliance checking
During incubation, KITs must complete all mandatory artifacts, including comprehensive documentation, API specifications, reference implementations, and test cases.
Graduated Level
Graduated is the highest maturity level, indicating that the KIT has passed comprehensive testing, expert validation, and real-world case studies. These KITs are production-ready and have demonstrated business value through community adoption.
- All mandatory artifacts completed and validated
- Successful case study with community partner
- Expert testing and approval completed
- Proven business value and clear technical implementation
- Assigned code owner for ongoing maintenance
Lifecycle Management
All lifecycle transitions are tracked in the KIT Master Data and validated according to the TRG 10.03 - KIT Lifecycle guidelines. This ensures transparency and consistency across the entire KIT ecosystem.
Artifact Requirements by Maturity Level
Each maturity level has specific artifact requirements that must be fulfilled for a KIT to progress. The table below shows the comprehensive list of required artifacts for each lifecycle stage:
- Mandatory
- * Optional/Recommended
- In Development
- Expert Review Needed
| Artifact / Stage | Sandbox | Incubating Draft | Incubating In Progress | Incubating In Review | Graduated | Additional Info |
|---|---|---|---|---|---|---|
| General Requirements | ||||||
| Changelog | Version history and updates, is mandatory for all lifecycles | |||||
| Code Owner | * | Required for graduation - how to configure see TRG 10.02 - KIT Content Structure and see also TRG 10.05 - KIT Graduation Process | ||||
| All Files | ||||||
| Notice | Legal and compliance notice in every file as described in TRG 07.07 and TRG 07.08 | |||||
| KIT Icon | SVG KIT icon stored at /static/img/kits/<kit-id>/<kit-id>-kit.svg as described in TRG 10.02 - KIT Content Structure | |||||
| Adoption View | ||||||
| Vision / Mission | Core foundation document, which describe why it makes sense and what is the goal of the KIT | |||||
| Business Value(s) | This is necessary to show if there is a clear business value for the KIT | |||||
| Use Case / Domain explanation | Explains the Use Case (What is its context) and how it works | |||||
| Business Processes | May not be relevant for Network Services | |||||
| Tutorials / Videos | * | * | Educational content | |||
| Whitepaper | * | * | Research and analysis document | |||
| Development View | ||||||
| Architecture Overview | * | System design and architecture diagrams that describe the system and its contexts. | ||||
| Component/Sequence Diagrams | * | Implementation details on the components and services from a KIT and how they interact with each other | ||||
| Standards | * | Industry standards compliance, if industry specific like (Catena-X e.V. standards) shall be referenced in the Industry Extension under the industry branch | ||||
| API-Specification / Protocols | * | Technical interface definitions, required for developing microservices | ||||
| Logic / Schema | * | Required for documenting the context, diagrams which specify the system that can be built with the KIT | ||||
| Semantic Models / Data Structures | Described the Data Models and Data Structures handled by applications based on this KIT | |||||
| Test Cases | * | Described test cases how to validate the functionality of this KIT | ||||
| Operation View | ||||||
| Deployment Guide | How to set the system and bring it up and running | |||||
| Operation/Monitoring Guidelines | Guidelines for operating and maintaining the KIT in production environments | |||||
| Security Guidelines | Security best practices, threat models, and security configurations | |||||
| Success Stories | ||||||
| Reference Implementations | * | COTS or Open Source implementations that used this KIT to build an application successfully, showing clear adoption paths and demonstrating the value of the KIT | ||||
| Documentation | ||||||
| Extra Documentation / Links | * | * | * | * | A KIT can include additional documenation or links if is relevant for the users of the KIT | |
| Sample Data | * | Example datasets from this KIT to help users understand and implement the datamodels effectively at the systems | ||||
| Industry Extensions | ||||||
| At least one Industry Extension | * | Required for graduation - at least one industry extension with industrial standards compliance - see TRG 10.02 - Industry Extensions | ||||
KIT Template
Follow the KIT template to have an example of folder structure that can be followed following the KIT Framework Guide and the needed content for each view in order to achieve all requirements from the KIT Lifecycle.
KIT Office Hours - Get Expert Support
Need help developing your KIT or have questions about the KIT framework? Join our KIT Office Hours - a dedicated time for the community to get direct support from the KIT development team.
What are KIT Office Hours?
KIT Office Hours are regular community sessions where you can:
- Get guidance on KIT development and lifecycle progression
- Ask questions about TRG compliance and best practices
- Discuss your KIT architecture and implementation approach
- Receive feedback on your KIT graduation readiness
- Connect with other KIT developers and maintainers
How to Participate
Office hours are held regularly and open to all community members. Whether you're just starting with KIT development or preparing for graduation review, the team is here to help.
Every Thursday from 09:30 - 10:00 GMT+1
Check the Eclipse Tractus-X Community Calendar for upcoming KIT Office Hours sessions and join us!
Learn More
Want to dive deeper into the KIT framework? Explore our comprehensive documentation to understand the complete structure, artifacts, and requirements for building your own KITs.
All KITs are licensed under the non-code CC-BY-4.0 License.
All industry logos and trademarks are property of their respective organizations.