Sovereign AI Architecture Residency

Target picture and the three critical assumptions

Your initiative on one wall: workloads, users, data classes, regulatory framework. The assumptions named in the preliminary call are sharpened and translated into measurable verification criteria.

Requirements with veto power

Data protection, security and operations state their hard limits before the architecture is drawn: what must the system never do, which evidence up to VS-NfD should be preparable, who will carry operations?

Slice selection: a case that proves something

From your candidate workloads the use case is chosen that tests the riskiest assumption, not the most convenient one. The bar is set: how do we recognize on Friday that the slice holds?

First measurement run: baseline on lab hardware

Your target models run on the reserved GPU systems for the first time. Baseline measurement of throughput and latency as the reference for every decision of the week.

Day result: verified target picture and measurement plan

Target picture, hard limits, the selected slice and a measurement plan for the three critical assumptions exist in writing and are carried by the whole team.

Architecture design: the load-bearing decisions

Compute, network, storage, identity, registry, inference stack: the design takes shape on the wall, every layer with reasoning and an alternative. Azure Local and Azure Arc are planned in where they carry weight, in the version available at the time.

Sizing calculation against the baseline

The capacity model is calculated with the baseline values from day 1: how many cards of which class, from L40S to H100, for your peak loads? The gap between vendor claims and your own measurements is quantified.

Validation: assumptions one and two under test

The first two critical assumptions are checked on the hardware, for example quantization effects on your quality requirement or concurrency behavior under realistic load. Results flow straight back into the design.

The operating model switch

Connected, intermittently disconnected, or initiate the disconnected eligibility check: decided against the criteria catalog, with an honest framing of the eligibility prerequisites of Azure Local Disconnected Operations.

Day result: robust architecture design v1

The design exists in version 1, with a sizing calculation based on your own measurements and a documented operating model decision including open verification points.

Slice build: the foundation

Building the slice on the lab environment along the design: identity integration, network segment, registry connection with signature verification. Your team builds, the trainer keeps design and reality aligned.

Slice build: data and application logic

Your anonymized sample data meets the stack: preparation, indexing or integration depending on the case, plus the application layer. Where it honestly fits, patterns from Sovereign Assistant or VOXA serve as references.

First end-to-end run

The slice answers end to end for the first time: from authenticated request to a substantiated answer. Whatever jams is logged and prioritized instead of talked up.

Day result: end-to-end slice

The use case runs end to end on the lab environment. Deviations from the design are logged and scheduled for day 4.

Assumption three and the load test

The remaining critical assumption is tested, then the slice faces a load test against the bar from day 1: throughput, latency, behavior at the capacity limit. Every deviation gets a cause or a backlog item.

Operations and security drill

The slice is treated like production: a monitoring view is built, a model rollback is rehearsed, a prompt injection attempt is run against the protection layer. Results flow into the operations design.

Backlog prioritization

Everything open becomes a backlog with effort classes, dependencies and risks: the path from validated slice to productive platform, prioritized by the team, not the trainer.

Investment picture and make or buy

Sizing, operating model and backlog are condensed into an investment picture: self-build, Sovereign AI Appliance or a mixed path, with numbers and named uncertainties for the readout.

Day result: validated design with backlog

Architecture and operations design exist in a verified version, all three critical assumptions are answered with measurements, the backlog is prioritized.

Hardening the design

A final review round with swapped roles: the team attacks its own design, the trainer defends it, and vice versa. Whatever does not survive the attack is changed or documented as a risk.

Readout rehearsal

The executive readout is rehearsed once in full: key messages, measurements, investment picture, recommendation. The team decides who presents which part to its own leadership.

Document handover

Design, measurement protocols, backlog and readout deck are finalized and handed over. All artifacts belong to you and remain usable without BORDONARO.

Executive readout

90 minutes in front of your leadership level, on site in the lab or joining remotely: the validated design, a live demonstration of the slice, the investment picture and the recommendation with open risks. Questions are answered by the team, not just the trainer.

Final result: decision basis handed over

Your leadership has seen a validated design with measurements, a tested slice and a prioritized backlog. Next steps and the two follow-up sessions are scheduled.