New Use-Case ADRs​

This release 2026-3 introduces the first two use-case ADRs targeting the MX-Port Hercules configuration. Both use-cases specify how the network-ADRs from the Hercules baseline are composed into end-to-end data exchange scenarios.

ADR-101 – Energy Consumption & Load Management (0.1.0)​

ADR-101 specifies normative guidance for the Energy Consumption & Load Management use-case. It enables the exchange of energy production and consumption forecasts between Energy Companies (Data Providers) and Factory Operators (Data Consumers). The ADR defines a dedicated Forecast Service API (specified as an OpenAPI document), required AAS submodels (Digital Nameplate 3.0.1, EnergyFlexibilityDataModel 1.0.0, Time Series Data 1.1), and Shell Descriptor requirements for energy meter time series assets. It builds on the Hercules network-ADRs.

ADR-102 – Manufacturing as a Service (0.1.0)​

ADR-102 specifies normative guidance for the Manufacturing as a Service (MaaS) use-case. It covers three end-to-end scenarios — Supplier Capability Notification, Search/Request/Offer/Order, and Order Execution & Quality Control — and defines which IDTA submodel templates must be used for each. Suppliers act as Data Providers; platform applications and buyers act as Data Consumers. Both parties build on the Hercules network-ADRs (ADR-002, ADR-003, ADR-008, ADR-009).

Implementation report​

Other full or partial implementations may already exist in commercial or open-source repositories. Certifying such components may in the future be the activity of a Conformity Assessment Body or Certification Program.

Website Improvements​

ADR Graph Visualization​

The specification website now ships an interactive ADR Graph that renders the dependency network between all ADRs. The graph defaults to the latest released version and is synchronized with the Docusaurus version selector in the navbar. This makes it easier to understand how network- and use-case-ADRs compose into a coherent specification stack at a glance.

OpenAPI Rendering​

ADRs that reference an OpenAPI specification — like ADR-101 — now render the API contract directly on the documentation page. This removes the need to open the raw YAML file and makes the API surface immediately visible to readers.

Contributor Experience​

ADR Contribution Guide and Templates​

A new CONTRIBUTING.md provides step-by-step instructions for authoring both network-ADRs and use-case-ADRs, including a ready-to-use template and guidance on how to integrate OpenAPI specifications. The README.md has been updated with a contributor overview, and a CODE_OF_CONDUCT.md has been added.

REUSE 3.3 Compliance​

The repository is now compliant with the REUSE 3.3 specification. All source files carry SPDX copyright and license headers. Code is licensed under Apache-2.0; documentation is licensed under CC-BY-4.0. The LICENSES/ directory ships the full license texts, and REUSE.toml captures the per-path license annotations.

The last mile: From network-ADRs to solving business problems​

The Factory-X project has so far focused on publishing **network-ADRs ** that specify the technological foundation for data exchange in the context of the MX-Port Hercules. These ADRs lay out the protocols, APIs, and architectural decisions that enable interoperability and secure communication between components in the Factory-X ecosystem.

Now, this solid foundation is put to use as the foundation for **use-case ADRs **. These ADRs build on the network-ADRs to solve specific business problems and enable data exchange for value-creating processes. Use-case ADRs specify how the underlying technologies are applied in real-world scenarios, detailing the data flows, interactions, and decisions made to address particular use cases. Building on a broad foundation, use-case ADRs are lean and only extend the network-ADRs where necessary to solve the problem at hand.

Nomenclature​

The Hercules Use-Case ADRs will be numerated consecutively starting with ADR-101.

On Releases​

Like every Dataspace, Factory-X is build on the mutual agreement between participants to expose interfaces accordingly to specifications. A release like this one is a snapshot on a timeline of specifications and implementation projects. As such, it bundles Factory-X Architecture Decision Records (ADRs) at certain versions with software at certain versions. Releases use CalVer with YYYY-MM scheme. ADRs use SemVer.

State of the Spec​

In the MX-Port Concept Paper (link opens pdf), Factory-X has promised three separate sets of specifications. The ADRs (published and agreed by the consortium) map to one or more of these three "MX-Port Configurations". All ADRs in the 2025-12 release are published in the context of MX-Port "Hercules" that strives for interoperability with the Catena-X Dataspace.

The figure above explains the interconnection between the ADRs. ADR-009 and ADR-012 are exclusively there to hook the underlying technologies (AAS over HTTP and AAS over MQTT) into the extension points of the Dataspace Protocol.

Implementation Report​

The Factory-X project collaboratively develops software in the factory-x-contributions Github organization. Its purpose is to bridge the gap between paper and runnable code and thus to inform specification activities with the experience gained. The table below only lists the implementations that are driven from the Factory-X project.

Other full or partial implementations may already exist in commercial or open-source repositories. Certifying such components may in the future be the activity of a Conformity Assessment Body or Certification Program.

Adoption​

The published ADRs are all "network-ADRs". They don't (in themselves) solve a particular business problem but lay a common technological foundation. By adopting the aforementioned network-ADRs into use-case-ADRs, ecosystem participants can focus on what drives value: exchanging data to support value-creating business processes. The plumbing is taken care of.

I’m pleased to announce that Factory‑X’s Architecture Decision Records (ADRs) are now published on a static website built with the Docusaurus framework. The ADRs are pulled directly from the repository’s .md documents and presented in a clear, searchable format. To make navigation easier, entries are organized according to the different configurations of the MX port, so you can quickly find decisions relevant to a particular setup.

Serving the ADRs as a static site delivers fast page loads, reliable hosting, and straightforward version control, because the source remains the markdown files in the repo. This also makes it simpler for contributors to propose updates via pull requests and helps keep the documentation aligned with code changes. Whether you’re reviewing past decisions or onboarding to the codebase, the new site should make it easier to discover the rationale behind our architecture choices.

Enjoy browsing the ADRs, and please share any feedback or suggested improvements—pull requests and issues are welcome for clarifications, corrections, or new entries.