Reinventy Solutions Corp. · Technology intelligencePrivate control
ReinventyHERALD
Evidence-led daily edition
← Weekly EditorialOpinion & analysis

AI becomes business infrastructure

· By Antonio Sedino, CTRO · Reinventy Solutions Corp.

Industrial concept extracted from the hardware proposal. The open view illustrates the module layout; it is neither a photograph of a completed system nor a construction drawing.
Industrial concept extracted from the hardware proposal. The open view illustrates the module layout; it is neither a photograph of a completed system nor a construction drawing.

Ten Thor nodes per module, an expandable architecture, and Tin Man OS to govern models, resources and continuity. Sovereign Edge AI puts a practical question at the centre of the discussion: what does it take for artificial intelligence to become a capability a business can manage?

Inside Reinventy’s sovereign micro data center project

A growing share of a company’s value lives in its documents, procedures, code and people’s experience. Artificial intelligence can make that knowledge more accessible: helping teams read a specification, connect scattered information, prepare a simulation or support a designer. Doing this well requires giving AI a defined place in the organisation: deciding where it runs, which data it uses, which tools it can access and who is responsible.

The Reinventy Sovereign Edge AI project starts with this need. It proposes a modular micro data center combining computing, networking, management, protected power and cooling, with software designed to turn physical resources into usable services. The objective is to move from occasional access to computing power towards a deliberately engineered operational capability.

Project status. This editorial presents hardware specification SEA HW 001 and software specification SEA SW 001, revision 1.0, dated 20 October 2026. They define architecture, operations and a delivery path; the final bill of materials, construction drawings, new software components and system qualification on physical hardware remain to be completed. The images illustrate the design and do not establish that a system has already been built or its performance measured.

A complete module with ten compute nodes

The reference unit calls for ten compute nodes based on NVIDIA Jetson T5000 modules, referred to as Thor, each with 128 GB of nominal unified memory and an 8 TB local SSD in the candidate configuration. An integrated PC coordinates the unit; an internal network connects the nodes; liquid cooling, an APC online UPS with batteries and independent physical supervision complete the assembly.

The proposed layout makes the architecture easy to understand: control and networking at the top, ten compute trays in the centre, UPS and batteries at the bottom, and a dedicated technical area for the cooling circuit. This is also a maintenance decision. Identifying a node, reaching connections and replacing a part must be planned operations.

The system is conceived to grow from one to four modules, or from 10 to 40 Thor nodes. An external DGX can extend the options or provide a comparison platform; the base module must be able to operate locally without it and without a customer workstation remaining connected.

Reference hardware structure, figure H2 in the dossier. Connections represent proposed functions; memory and storage figures are nominal capacities. English edition.
Reference hardware structure, figure H2 in the dossier. Connections represent proposed functions; memory and storage figures are nominal capacities. English edition.

Ten nodes provide 1,280 GB of nominal memory and 80 TB of raw SSD storage; forty provide 5,120 GB and 320 TB. These resources are distributed. Each node must accommodate its own share of weights, cache, working data and services: their sum does not automatically become the memory of a single GPU. Software determines how much installed capacity can become useful work.

Two ways to work with LLMs

The first mode, coordinated specialists, assigns different tasks to complete models. One can read technical documents, another assist with code, and another prepare data for a domain application. A coordinator organises the activities, retains their results and assembles an answer with traceable provenance. Specialists may use different checkpoints or compatible adapters on the same base model.

Consider an engineering request: interpret a requirement, find relevant documents, prepare inputs for an authorised solver and produce a report. The LLM helps connect these steps. Numerical computation retains its own verification method, tools keep their permissions and human review remains identifiable. Work can become more specialised without granting a model authority to take any action it chooses.

The second mode, one distributed model, addresses a different requirement: running a model that exceeds a single node’s budget. The model retains one identity — weights, tokenizer, precision and transformations — while parts of its computation run across several Thor nodes. Sending the same question to ten assistants is insufficient: the execution graph must actually be distributed.

Two scenarios on the same hardware. A exchanges tasks and results between complete models; B exchanges tensors between partitions of one model. English edition.
Two scenarios on the same hardware. A exchanges tasks and results between complete models; B exchanges tensors between partitions of one model. English edition.

Pipeline parallelism assigns groups of layers to successive nodes. Tensor parallelism divides computation within a layer. Expert parallelism distributes the experts of a Mixture of Experts model. The choice depends on the model, runtime and network actually supported. Adding nodes may increase capacity or the number of requests served, while communication can still limit the latency of an individual answer.

This distinction opens an interesting possibility: using the same infrastructure for a set of specialised services or for experiments with larger models. The best plan may even use fewer nodes than are available if that provides a better balance of quality, response time and energy.

A model’s journey: from catalogue to service

The proposed process begins with a model record: origin, revision, licence, architecture, tokenizer, weight format and supported context. A model must suit the task, work with the backend and be usable under its licence. These three checks determine entry into the operational process.

The packager produces packages or shards with manifests and integrity digests. The planner assesses memory on each node, conversation cache, concurrent sessions, available operators, networking and the energy budget. A plan exceeding the limits is rejected with an understandable reason. Where quantisation is adopted, it must identify the change in weight representation and the quality comparison performed.

Proposed lifecycle for a distributed model. Conversion produces a candidate; qualification requires evidence tied to a model, runtime, hardware and usage profile. English edition.
Proposed lifecycle for a distributed model. Conversion produces a candidate; qualification requires evidence tied to a model, runtime, hardware and usage profile. English edition.

In the software design, Tin Man OS Foundry is the laboratory for configuring, simulating and comparing plans. The controller on the integrated PC admits jobs and reserves resources; workers on the Thor nodes perform computation; the gateway exposes the service to applications. Tensors follow the runtime’s data path without passing through the development console. This separation allows the laboratory and execution environment to evolve with clear responsibilities.

Sovereignty means being able to operate and recover

Local deployment can reduce the transfer of sensitive data to external services and allows access, retention and updates to be designed around the company’s needs. To make that autonomy practical, the dossier requires locally available models and licences, restorable backups, separation between authorised contexts and procedures tested without Internet access.

One potential benefit is reproducibility: associating a result with a particular model version, identified tools and data, and an execution plan. Another is the freedom to allocate resources to confidential or specialist workloads. Economic comparisons with external services will need real workloads and must include hardware, energy, maintenance and support. The project also retains dependencies on component supply chains and the software it uses.

Continuity depends on operational details. If a request times out, the controller must establish what happened before repeating it. If a specialist becomes unavailable, a qualified replica may be available. If a required shard of a distributed model is lost, that model stops and needs the recovery procedure defined for it. Making these states explicit is part of service quality.

Power and cooling are part of the product

The initial design envelope is 2.5–3.0 kW of load power per module, subject to verification against the final bill of materials. Power drawn from the grid also includes UPS losses and battery charging. Battery runtime will depend on the configuration and the manufacturer’s discharge curves. The dossier reports no measured battery runtime for the proposed system.

The proposed protection also covers pumps, networking and control. During a power outage, the system will need to reduce admission of new jobs, complete or drain accepted work and shut down in an orderly manner. Liquid cooling transfers heat to the exchanger and the surroundings; the technical room still needs appropriately sized cooling. Physical interlocks remain independent of language models and their availability.

Applications give capacity its purpose

For a business, value appears in its processes: searching organisational knowledge, helping developers, preparing technical inputs, comparing alternatives and producing traceable reports. The project envisages integration with Alchemi and AEROMAG through versioned services and artefacts. Opportunities include domain specialists and research support, while preserving separate scientific validation for solvers, simulations and experimental results.

The programme focuses on inference and selected adaptations. A more specialised Reinventy model would require its own datasets, licences and evaluations; pretraining a frontier model needs a separate plan. This progression allows work to begin with useful, measurable tasks, building knowledge of system behaviour before extending the ambition.

From a two-Thor bench to an operational system

The delivery path grows through evidence: two Thor nodes to verify correctness and distribution costs, four to compare topologies, ten to integrate a module, then multiple modules to measure the benefit of federation. The dossier calls for comparisons using the same model and profile, measuring time to first token, generation consistency, quality, concurrency, energy and recovery from faults.

Sovereign Edge AI’s potential lies where these disciplines meet. A module that can be procured and maintained, identifiable models, recoverable jobs and verifiable results can give a business a foundation for its own services. The goal is AI the organisation knows how to use, govern and develop: a capability that becomes part of its operational assets.

Sources and images

Editorial basis: Reinventy documents SEA HW 001 and SEA SW 001, revision 1.0, 20 October 2026, used as the basis for this editorial. The cabinet concept comes from the original DOCX. The diagrams have been redrawn from the original source with English labels; they show proposed architectures.

Technical cross-checks: NVIDIA Jetson Thor — component specifications — https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-thor/ and vLLM — parallelism and scaling — https://docs.vllm.ai/en/stable/serving/parallelism_scaling/ , consulted on 25 October 2026. These sources describe components and methods; qualification of the Reinventy system will follow the tests set out in the dossier.