Blog Post
From Blueprint to Operational Platform
How RESCALE’s Architecture Evolved
The first architecture of a technology platform is always built with some uncertainty. Components may still be conceptual, interfaces may not yet be final, and the eventual deployment environment may still be under development. This was also the case for RESCALE. Its first High-Level Architecture established the main domains, components, users, and information flows required to build the platform. As development and integration progressed, those early assumptions could be tested against real implementations. The final RESCALE architecture reflects what was learned during that process. It keeps the original structure where it remained effective, while adding the services, interfaces, repositories, deployment views, and trust mechanisms that became clear through implementation.
From a Conceptual Model to a Complete Architectural View
RESCALE follows the 4+1 architectural view model, which describes a platform from several complementary perspectives.
The Logical View explains the functional structure of the platform. The Process View shows how users and components interact during workflows such as assessment, TBOM generation, and validation. The Scenario View connects the architecture to the two pilot environments. These views were already central to the first architecture. The final version expands them and introduces more detailed Development and Physical Views. The Development View maps the architectural components to actual services, software repositories, libraries, and implementation artefacts. The Physical View shows how these services are deployed across the available environments and infrastructure.
This makes the architecture useful to a wider group of stakeholders. Developers can see where functionality is implemented, integration teams can understand service dependencies, and infrastructure teams can examine how the platform operates in practice.
Clarifying the Three Main Domains
The final architecture retains RESCALE’s three-domain structure.
- The Assessment Domain contains the static and dynamic testing capabilities. These components analyse software and hardware and produce the structured guarantees used by the rest of the platform.
- The Management Domain coordinates users, artefacts, workflows, and repositories. It includes the Dashboard, State Manager, identity and access management, and TrustOR.
- The Security and Trust Domain contains the services that maintain trust over time. These include Continuous Security Assurance, Event Captors, the Ledger Adapter, the permissioned ledger, and the Certification Authority Client.
Keeping these responsibilities separate allows each part of the platform to evolve without placing every function inside a single large service. Assessment tools can focus on testing, management components can coordinate evidence, and trust services can protect and monitor that evidence.
New Components and Clearer Trust Boundaries
Several additions in the final architecture reflect the progress made during implementation.
- TrustOR is shown explicitly within the Management Domain because of its central role in TBOM generation and validation. The repository layer has also expanded to include SBOMs, HBOMs, SSCGs, DSCGs, Bills of Vulnerabilities, TBOMs, and Hardware Fingerprints.
- The Event Captor appears as a separate component because collecting operational events is different from analysing them. It gathers information from monitored systems and provides it to Security Assurance.
- The Certification Authority Client was added to protect the boundary between externally signed evidence and internal RESCALE workflows. The external Certification Authority remains outside the platform, while the client-side validation and use of signed artefacts take place within RESCALE.
- Trust Storage also became more clearly defined. Complete supply-chain documents remain in the platform repositories, while the ledger stores compact integrity evidence. This distinction prevents the blockchain layer from becoming a general document store and keeps sensitive information under organisational control.
Documenting How the Components Communicate
The final architecture also provides a clearer description of the interfaces between services.
REST and HTTP are used for much of the communication between the Dashboard, State Manager, TrustOR, assessment modules, and other platform services. OpenID Connect and Keycloak support authentication and authorisation. Repository access uses internal database connections, while the Ledger Adapter provides a dedicated interface for blockchain operations. The architecture documents the direction of each interface, the protocol in use, and the type of information being exchanged. These exchanges include CycloneDX documents, combined SBOM and SSCG submissions, DSCGs, TBOM metadata, security alerts, and operational events.
This level of detail turns the architecture into an integration reference rather than a conceptual overview. Partners can use it to confirm that their services follow the same communication model and that the implemented platform remains aligned with the original objectives.
A Shared Blueprint for the Final Platform
The final High-Level Architecture records the transition from a research concept to an integrated technical platform. It shows which early decisions remained valid, which components were added, and how the trust and security mechanisms fit into the wider system. By completing the 4+1 views and documenting concrete interfaces, repositories, and deployment relationships, RESCALE provides a common technical language for its partners. The architecture now describes not only what the platform was intended to become, but how its major functions have been implemented and connected.