Route Before You Build

The platform team’s recurring Tuesday

A product team arrives: “we’re building a thing — set us up.” Every platform team fields this weekly, and most answer it artisanally: a meeting, a whiteboard, a bespoke pile of decisions that lives in nobody’s head a quarter later. By the fifth team, the answers have drifted apart, and the estate is five snowflakes deep.

The pattern this lesson teaches — drawn from a real platform team’s routing framework, the strongest single artifact in this training’s source material — replaces the artisanal Tuesday with a deterministic routing system. Its design has three load-bearing ideas.

Idea 1: orthogonal axes, never collapsed

Every “set us up” decision is actually four independent questions, and the framework’s core rule is refusing to let them contaminate each other:

AXIS 1  workloadArchetype    WHAT is it?   application+database (default) |
                                           api | integration | data-platform | mixed
AXIS 2  topologyLane         what assurance/isolation/handoff shape?
                                           shared-standard | gov-moderate |
                                           enclaved-high | (specialized extensions)
AXIS 3  providerTarget       WHICH cloud/region family?
AXIS 4  referenceArchitecture what runtime shape serves it?

The rule matters because collapsed axes are how routing systems rot: “government workloads go on VMs” fuses lane with architecture; “APIs mean the shared cluster” fuses archetype with provider. Each fusion bakes one moment’s coincidence into policy. Kept orthogonal, a data-platform workload in the high-assurance lane on the sovereign cloud is just a coordinate — no rule needed to anticipate the combination.

Idea 2: typed intake, deterministic table

Routing inputs come from a six-question intake a product owner can answer with zero cloud knowledge (what kind of thing is it, who uses it, what data sensitivity, what assurance regime, expected scale, any hard constraints) — producing a small typed vector. That vector hits a decision table — rules keyed primarily on assurance level — and resolves to a named, pre-computed profile. Not a score, not a weighted rubric, not a conversation: a table lookup you can read, diff, and argue about in a PR.

The design virtue is reviewability of the rules themselves: when the table routes something surprisingly, the fix is a visible table edit with a commit message — versus the artisanal world, where the fix is “remember to decide differently next time.”

Idea 3: one decision-complete contract

Whatever profile wins, the output is always the same ten-field contract: archetype, lane, provider, reference architecture, compliance-monitoring mode, network posture, environment model, handoff rule, pipeline family, evidence model. Ten fields, and the receiving team’s every downstream question — which pipeline templates? what network shape? who provisions what? what evidence collects? — is answered by a field, not a meeting.

“Decision-complete” is the standard to hold it to: if any downstream step still needs a judgment call, the contract is missing a field. And because every workload emits the same shape, the contract becomes the interface the whole platform builds against — Lesson 6.1 shows the payoff, where starters, IaC, and handoff packets are generated from it (with a CI check that fails when generated surfaces drift from the source table — the full productization machinery lives there, not here).

Prompt first

Build the routing decision system for our platform, v1:
1. The six-question intake with typed answers (enumerate every allowed value)
2. The decision table: rules keyed on assurance first, resolving every
   realistic intake vector to one of 4-6 named profiles - flag any vector
   the table cannot resolve (those become explicit "talk to the platform
   team" rows, not silent gaps)
3. The ten-field contract each profile emits, with each field's allowed
   values and which downstream consumer reads it
Then route these three Meridian requests and show the contract for each:
(a) a crew-scheduling web app with a database, internal users, moderate
    sensitivity; (b) a read-only public API over outage data; (c) an
    analytics workspace ingesting meter telemetry for the data team.

The three sample routings are the artifact — and (c) should teach you something the source framework encoded deliberately: data-platform archetypes got routed to guided customization, never a push-button starter, because the framework’s designers knew where deterministic routing’s edge was. A routing system that knows its own limits and says “human, here” at them is mature; one that routes everything is lying somewhere.

Key takeaway

Route before you build: four axes kept orthogonal, a typed six-question intake, a deterministic table that resolves to named profiles, and one ten-field decision-complete contract that downstream tooling consumes. Reviewable rules beat remembered wisdom, defaults beat fusions, and a table that knows where to say “human, here” beats one that routes everything. Module 2 builds the thing the contract’s pipeline-family field points at.