I am writing this on a Tuesday in late March, twenty-eight weeks and roughly two hundred and eighty commits into building DuranteOS. Studio has been live for seventy-four days. The Hexagonal migration is essentially complete. Sixty-seven days of MCP-shaped tool-call traffic is behind me — the W21 essay covered what that taught.

The four prior dispatches — W18 vertical integration, W19 procurement-as-benchmark, W20 counter-sovereignty, W21 unbundling — described the same architectural problem from four angles. Microsoft default Claude. Anthropic banned from federal procurement. The lawsuit filed Monday Mar 9. The DOD's "unacceptable risk to national security" filing Wednesday Mar 18. The preliminary-injunction hearing fast-tracked to today, the same day this essay publishes.

The architectural problem the dispatches kept circling is a routing problem. When the substrate vendor my product depends on can be banned from a vertical of customers in a single twenty-four-hour press cycle, which model do we route to? stops being a price-performance question and becomes a governance question. The routing layer needs to know about more than capability and cost. It needs to know about jurisdictional exposure, partner-channel availability, and policy posture — for every call.

This is the architecture I want to commit to before the hearing's outcome lands. The shape of the thing has been forming since November; the procurement decisions of the last three weeks made it load-bearing rather than aspirational.

The Cockburn angle: sovereignty as a port-level concern

Alistair Cockburn's hexagonal lens from W15 treats every external dependency as a driven adapter implementing a port. Studio's Provider port abstracts the agent runtime away from any specific vendor's API quirks; the W21 MCP essay extended the same lens to MCP servers as adapters supplying capability through a uniform contract.

Sovereignty-class routing is the next move in the same direction. The port stays the same — the agent runtime still calls provider.chat(req, ctx) — but the adapter selection logic that picks which provider serves any given call gets new constraints. The adapter is no longer chosen by capability and cost alone. It is chosen by capability, cost, and the sovereignty constraints declared by the request context.

Five axes. Two of them (capability, cost) were already first-class in Studio's Provider port. The other three are what the procurement decisions of the last six weeks made non-optional.

The Cockburn discipline is that each axis should be expressed as adapter metadata declared at registration time, not as conditional logic scattered through the routing layer. The runtime queries the registry for adapters that satisfy the request's constraints across all five axes, picks the cheapest qualified adapter, and routes. The hexagonal boundary holds because the routing logic is uniform across all providers — what varies is the metadata each adapter declares, not the routing code.

The Greg Young angle: every routing decision is an event

Greg Young's central move with CQRS and Event Sourcing — the framing I borrowed in W9 for the memory layer — is to treat the current state as a left-fold over an append-only event stream. Applied to routing: every routing decision is a discrete event, the current routing-policy state is a projection of the event stream, and any specific past decision can be reconstructed exactly.

That property matters more for sovereignty-class routing than it does for capability-and-cost routing. The audit question that was hypothetical six months ago is now operational: show me which provider this call routed to, why, and what alternatives the policy considered.

The event-sourced shape:

type RoutingDecision = {
  id: string;
  request_id: string;
  timestamp: string;
  candidates_considered: AdapterId[];
  candidates_rejected: { adapter: AdapterId; reason: RejectReason }[];
  candidate_chosen: AdapterId;
  decision_rationale: {
    capability_match: boolean;
    cost_within_ceiling: boolean;
    sovereignty_class_qualified: boolean;
    partner_channel_qualified: boolean;
    policy_posture_qualified: boolean;
  };
  policy_version: string;
};

Each decision is a triple of (which providers were considered, why each rejected one was rejected, why the chosen one was chosen). The decision is committed to the event log before the actual provider call fires. If the call later fails or produces a regulatory question, the decision and its rationale are queryable years later — and replayable against any subsequent policy version to ask "given today's policy, would this call have routed differently?"

The audit property is not a hypothetical. The DOD's filing against Anthropic on Wednesday Mar 18 explicitly raised "behavior of the model under specific operational scenarios" as a procurement concern. If a customer of mine is federal-adjacent and asks "which calls did your product route through which providers, and were any of those routes incompatible with our procurement framework at the time," the event-sourced log is the answer that does not require me to reconstruct decisions from memory or logs that were not designed for the question.

What the request-context shape looks like

The other side of the architecture is the request itself. For sovereignty-aware routing to work, every request has to declare its constraints — and the constraints have to be inheritable from the customer profile, not re-typed per call.

The shape Studio is converging toward:

type RequestContext = {
  customer_id: string;
  tenant_policy: {
    sovereignty_constraints: SovereigntyClass[];   // e.g., ["non-federal-banned", "EU-data-residency"]
    partner_channel_constraints: PartnerChannel[]; // e.g., ["any-channel"] or ["accenture-only"]
    policy_posture_requirements: {
      no_training_on_data: boolean;
      max_prompt_retention_days: number;
      eu_data_residency: boolean;
    };
    cost_ceiling_per_call_usd: number;
  };
  call_type: "chat" | "image" | "audio" | "embedding";
  capability_requirements: { context_tokens?: number; multimodal?: boolean };
};

The tenant_policy block is set once per customer at onboarding and inherited by every request from that customer. The runtime does not need to ask the operator "are you federal-procurement-restricted?" on every call — the answer is a property of the customer's tenant profile.

This is what sovereignty-aware routing actually looks like in code. Not a special case. Not a sidebar. A first-class field set on the customer's tenant profile and inherited by every call from that customer, evaluated by the routing layer against adapter metadata, recorded as an event.

What I have built so far, what I have not

Honest current state, twenty-eight weeks in:

Half the architecture is in production. Half is still in design or partial implementation. Writing this essay before the back half ships is the discipline that keeps the design honest. If I write it after, the version I commit to in code is the version that gets retconned into the essay; the version I commit to here is the one I have to defend in the retro.

Three pitfalls I am committing to avoid in advance

The three pitfalls are predictable enough that committing in advance to avoid them costs less than discovering them on a Friday afternoon when a customer is on the phone.

What this implies if you are building a routing layer

Three suggestions, each costly enough that I considered cutting them and was wrong each time.

One. Make sovereignty class a first-class axis, not a special case. The procurement decisions of Q1 2026 made this non-negotiable. Treating it as a TODO inside the cost-and-capability routing logic is how you discover the architecture is wrong on a customer's call.

Two. Event-source the routing decisions. The audit question is not hypothetical. Customer questions about which calls routed to which providers — and why — will become routine within twelve months for any product selling to government-adjacent or regulated-industry buyers. The event log is the answer that does not require reconstruction.

Threes. Inherit the customer policy at the request layer, not at the call site. Routing decisions made on data the operator entered ad-hoc are routing decisions the operator forgets to enter. Customer-tenant policy is set once at onboarding, propagated to every request from that customer, evaluated automatically. The discipline scales because the operator does not have to think.

The architecture I want Studio to commit to is not a moonshot. It is the same hexagonal-port pattern Cockburn described twenty-one years ago, with three new axes the procurement decisions of Q1 2026 made first-class, and an event-sourced log of decisions in the shape Greg Young has been arguing for since 2010. Old patterns. Concrete additions. The combination is what survives the procurement decade.

The retrospective on this architecture ships at the end of June, after another quarter of operating it. By then we will know whether the five-axis routing held, whether the event-sourced log produced the audit answers I expect it to produce, and whether any of the three pitfalls I named in advance turned out to be correct or wrong about. Either result is more useful than continuing to operate without commitment to the shape.

The Tuesday DOD hearing happens today as I publish this. By Friday's dispatch, the outcome will reshape parts of the architecture — but the shape of the architecture is the part that does not change. That is what I want on the record now, before any specific outcome makes the shape look obvious in retrospect.