# Blueprintr: full content
> Every recently-published public blueprint as raw markdown.
---
# Data centre fabric — spine, leaf and the overlay on top
URL: https://blueprintr.io/orgs/blueprintr/network-topologies-example
> A 100G leaf-and-spine fabric drawn twice: the physical pods, spines and border once, then the EVPN/VXLAN overlay of tenants, VRFs and VNIs that rides on it. Every switch opens on its interfaces, addre…
# AMS1 — a fabric you can reason about one device at a time
> \[!TLDR] What this blueprint is
> Halyard's Amsterdam data centre network, from the two transit circuits down
> to a 25G port in a rack. Click **any switch** for its interface allocation,
> addressing, and the commands that tell you whether it is healthy. The
> **Overlay** tab draws the same fabric a second way — as tenants and VNIs
> rather than boxes and cables — because the two pictures answer different
> questions and neither is complete on its own.
**Site:** AMS1 · **Underlay:** `10.254.0.0/16` · **Out-of-band:**
`10.255.0.0/16` · **Owner:** Network Engineering · **On-call:** `#net-ams1`
## The one rule this design is built around
**No single device matters.** Not a spine, not a leaf, not a firewall. Every
decision below follows from that, and every operational procedure exists to
prove it is still true.
| Layer | What it does | Losing one costs you |
| --------------------------------------------------------- | -------------------------------------------- | ------------------------- |
| [Spines](stratum:c_777e319fd9f3486f827834ae41f53913) | underlay transport and EVPN route reflection | 25% of east–west capacity |
| [Leaves](stratum:c_e7cd96e6e46d4146a6a323c2080a3522) | VTEPs, anycast gateways, host attachment | half a pod's bandwidth |
| [Border pod](stratum:c_93dc9ff57e0847d591547599c46490d9) | the outside world, the DCI, policy handoff | one path off site |
| [Out-of-band](stratum:c_60b7c130b3344503b2f28d1c7bcbd9b5) | recovery when the fabric is wrong | your ability to fix it |
## Reading the picture
The four spines carry **no tenant state at all** — no VRF, no SVI, no VTEP. A
packet crossing the fabric is encapsulated at the ingress leaf and decapsulated
at the egress leaf; the spine only ever sees underlay addresses. That is what
lets a spine be upgraded on a Tuesday afternoon.
Each pod is a leaf pair plus its racks and owns one BGP ASN. Pods are
interchangeable: the same segments and the same anycast gateway addresses exist
on every pair, so a workload can be scheduled anywhere without a network change.
Capacity is therefore added as a **whole pod**, never by hanging more racks off
an existing pair. The thresholds that trigger that are in
[capacity and growth](stratum:c_fad7c92f108c4c7d899fd5afabe96f58).
The links are drawn once where a second parallel curve would add ink rather than
meaning; the real port-by-port allocation is on each device's **Interfaces**
tab.
## What is deliberately not here
* **No host-level detail.** The fabric's contract with a server is the
[host attachment standard](stratum:c_d1445aba68954ab1b9ca7ff5156313fe) — two links, two leaves,
LACP, no silent fallback. Everything above that is the platform team's.
* **No firewall rule base.** [FW-1](stratum:c_b73a8dd2a41144ba9fbab09111a8ac35) shows zones and posture; the
rule base lives in the security estate, where it can be reviewed on its own
cadence.
* **No second site.** AMS2 appears as the DCI cloud. Route targets cross
selectively — `prod` and `shared` yes, `nonprod` and `dmz` no.
## Where to start
| If you are… | Start at |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Attaching a new host | [host attachment standard](stratum:c_d1445aba68954ab1b9ca7ff5156313fe) |
| Making any change | [fabric change runbook](stratum:c_1daa1211bc904083b809a931f2dd8228) |
| Planning an upgrade | [rolling upgrades](stratum:c_c6772e353b5f4d82bda51ab5a92b2511) |
| Adding a segment or tenant | [VNI and segment plan](stratum:c_dfd531e4b3494eea91e063d7ca1eccbd) and [VRF design](stratum:c_4fec65983b6c4a21aa568d17578cb759) |
| Wondering why it is shaped this way | [VRF and route-leak design](stratum:c_4fec65983b6c4a21aa568d17578cb759) |
The hierarchical campus this fabric serves is the sibling
[Network site topology](/blueprintr/network-site-topology); the
circuits between sites are in
[Global WAN network diagram](/blueprintr/global-wan-diagram).
---
# Securing your account
URL: https://blueprintr.io/josh/securing-your-account
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# Creating a stratum
URL: https://blueprintr.io/josh/creating-a-stratum
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# Finding your way around the dashboard
URL: https://blueprintr.io/josh/finding-your-way-around-the-dashboard
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# Importing existing content
URL: https://blueprintr.io/josh/importing-existing-content
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# Connecting an AI agent
URL: https://blueprintr.io/josh/connecting-an-ai-agent
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# The editor's three steps
URL: https://blueprintr.io/josh/the-editor-s-three-steps
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# Reading a blueprint
URL: https://blueprintr.io/josh/reading-a-blueprint
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# Drawing in Vellum
URL: https://blueprintr.io/josh/drawing-in-vellum
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# Setting up a documentation site
URL: https://blueprintr.io/josh/setting-up-a-documentation-site
> Four slides on what a folium is, how its page tree works, and where everything else is configured.
---
# Publishing your first blueprint
URL: https://blueprintr.io/josh/publishing-your-first-blueprint
> A five-slide walkthrough of the authoring loop, from the rail to a stratum.
---
# Three independent choices
URL: https://blueprintr.io/josh/three-independent-choices
> Ownership, visibility and filing are decided separately — and only one of them changes the URL.
---
# How SCIM reaches Blueprintr
URL: https://blueprintr.io/josh/how-scim-reaches-blueprintr
> Your directory pushes to the SSO service; Blueprintr pulls from it. And the one direction SCIM will not reverse.
---
# Two keys, two servers
URL: https://blueprintr.io/josh/two-keys-two-servers
> Why a personal key and an organisation key are not one credential with different permissions.
---
# Import vs connect
URL: https://blueprintr.io/josh/import-vs-connect
> Import copies content in once and it becomes yours; a connector leaves it where it is and renders it live per viewer.
---
# Change request lifecycle
URL: https://blueprintr.io/josh/change-request-lifecycle
> Open, then approved and merged, rejected, or withdrawn — and why the docs agent files one rather than writing the page.
---
# Continuum managed vs yours
URL: https://blueprintr.io/josh/continuum-managed-vs-yours
> A refresh rewrites the Continuum-managed half of a canvas and never touches the shapes you drew.
---
# SSO vs SCIM
URL: https://blueprintr.io/josh/sso-vs-scim
> SSO decides who may sign in; SCIM decides who is a member. Without SCIM a leaver keeps the membership and the seat.
---
# Stratum binding vs linking
URL: https://blueprintr.io/josh/stratum-binding-vs-linking
> A stratum is bound to exactly one shape, and can be linked to from anywhere.
---
# Teams structure
URL: https://blueprintr.io/josh/teams-structure
> What belongs at the organisation level and what belongs to a team.
---
# Publishing states
URL: https://blueprintr.io/josh/publishing-states
> Draft, published version, and the next draft — what readers see while you edit.
---
# Visibility model
URL: https://blueprintr.io/josh/visibility-model
> What decides who can read a blueprint or folium: status first, then visibility, capped by organisation policy.
---
# How Blueprintr fits together
URL: https://blueprintr.io/josh/how-blueprintr-fits-together-2
> Vellum draws a diagram, a blueprint wraps it with strata, files and prose, and one publish makes it readable four ways.
---
# Anatomy of a stratum
URL: https://blueprintr.io/josh/anatomy-of-a-stratum
> One shape on a diagram surface, bound to a stratum holding five tab kinds.
---
# Sixty thousand devices — the telemetry model
URL: https://blueprintr.io/orgs/blueprintr/telemetry-model-example
> What a fleet of connected heat pumps sends and where it lands: the device registry, an ingest path for a good connection and one for a bad one, the measurement schema and its cardinality budget, and h…
# Thornhill — sixty thousand devices
**2.05 million series. 2.95 billion points a day. Thirty-four measurements,
argued over.**
> [!TLDR] What this blueprint is
> Time-series modelling, which is a different discipline from the relational
> work in [`data-model-example`](/blueprintr/data-model-example): the decisions here are about
> cardinality, partitioning, rollups and retention. Click **any component**
> above for what it does and how it fails. The expensive mistake is the
> four-slide deck on **Podium**.
## The shape of it
A [heat pump](stratum:shc_telemetry_model_example_pump) and an [electricity meter](stratum:shc_telemetry_model_example_meter) talk to a
[hub](stratum:shc_telemetry_model_example_hub) in the house. The hub aggregates a minute at a time, names
everything in Thornhill's own vocabulary, signs it, and sends it two ways:
[live over MQTT](stratum:shc_telemetry_model_example_mqtt) when the connection is good, and
[in batches](stratum:shc_telemetry_model_example_batch) from [a fourteen-day buffer](stratum:shc_telemetry_model_example_buffer) when it
is not. [The stream](stratum:shc_telemetry_model_example_stream) validates and deduplicates;
[raw readings](stratum:shc_telemetry_model_example_raw) keeps thirty days and
[the rollups](stratum:shc_telemetry_model_example_rollup) keep a decade.
## The four decisions that explain most of it
| | |
|---|---|
| **A tag must be bounded and immutable** | Firmware version is neither. Tagging readings with it split every device's history at every upgrade and cost **3.1×** over four months — with nothing broken and no alert. See [the cardinality budget](stratum:shc_telemetry_model_example_cardinality). |
| **Two clocks, always** | `measured_at` is the device's, `received_at` is ours. They differ by days after an outage, and conflating them makes every historical chart change shape when a device catches up. |
| **Duplicates are the normal case** | MQTT is at-least-once and the batch path overlaps the live one on purpose. The primary key absorbs it: `DO NOTHING`, never `DO UPDATE`. |
| **Nothing is aggregated at write time** | Rollups are derived and re-derivable, because their definition always changes. Each carries `n` — an hour built from three readings must not look like an hour built from sixty. |
## Where the identity is not
Readings are keyed by `device_id` and hold no name and no address. The
device-to-property-to-account chain lives in
[the registry](stratum:shc_telemetry_model_example_registry) — sixty thousand rows next to a table of
billions — because one-minute domestic energy data reveals when a household is
in, asleep and away. Numeric is not anonymous; see
[the privacy position](stratum:shc_telemetry_model_example_privacy).
## Reading the drawing
| | |
|---|---|
| Solid | the live path |
| Dashed | the catch-up path, and control traffic |
| Dotted | a read, or something that does not block ingest |
| Numbers | the order a reading travels |
## Where to go next
| If you want… | Go to |
|---|---|
| What a device actually sends | the **What a device sends** tab |
| The schema, with the reasons in it | the **Measurement model** tab |
| Late, duplicate and wrong data | the **Late and wrong** tab, and [its runbook](stratum:shc_telemetry_model_example_late) |
| The mistake that tripled the bill | the **Podium** tab |
| Naming, units, retention, privacy | the **Handbook** tab |
| Cardinality at a smaller scale | [`multi-tenant-saas-example`](/blueprintr/multi-tenant-saas-example) |
| Where the exports land | [`lakehouse-platform`](/blueprintr/lakehouse-platform) |
---
# Multi-tenant SaaS — one platform, four hundred tenants
URL: https://blueprintr.io/orgs/blueprintr/multi-tenant-saas-example
> How one deployment serves four hundred customers without leaking between them: the control plane and the two data planes, tenant routing, isolation the database enforces rather than the code, per-tena…
# Sandgate — one platform, four hundred tenants
**One deployment. Four hundred customers. One isolation boundary that has to
hold on every single query.**
> [!TLDR] What this blueprint is
> The tenancy drawing every B2B SaaS team argues about and almost none of them
> has. Click **any component** above for what it does, who owns it and how it
> fails. The isolation itself is on the **Isolation** tab, and the decision
> that produced all of it is the four-slide deck on **Podium**.
## The shape of it
A request arrives at [the edge](stratum:shc_multi_tenant_saas_example_gateway), where
[the resolver](stratum:shc_multi_tenant_saas_example_resolver) decides which tenant it belongs to — once, from
the host or a signed claim, never from the body. [The registry](stratum:shc_multi_tenant_saas_example_registry)
says which data plane that tenant lives on. 391 tenants share
[one Postgres](stratum:shc_multi_tenant_saas_example_pgpool) with row-level security on every table; nine have
[their own](stratum:shc_multi_tenant_saas_example_pgsilo), running the same image against the same schema.
## The three things worth knowing before you read anything else
| | |
|---|---|
| **Isolation is enforced by the database, not by the code** | Every pooled table has `tenant_id NOT NULL` and a forced RLS policy. A forgotten filter returns *zero rows* instead of somebody else's — a bug report rather than a breach. |
| **Every shared resource is fair per tenant** | Worker queues, connection pools, rate limits, search. "Fair to jobs" is what caused [the March incident](stratum:shc_multi_tenant_saas_example_noisy); fairness has to be designed in per tenant, everywhere. |
| **Pooled and siloed run the same image and schema** | Only the connection string differs. The redundant `tenant_id` column in a siloed database is a very cheap price for one codebase and one test suite. |
## What it costs to be the other way
A siloed tenant costs about **78×** a pooled one, and a migration that takes
four minutes pooled takes ninety siloed — and can fail at tenant 214. That is
the whole argument for pooled-by-default, and it is the deck on the **Podium**
tab.
## Reading the drawing
| | |
|---|---|
| Solid line | the request path |
| Dashed | a control-plane relationship, not on the request path |
| Dotted | a call that does not block the response |
| Numbers | the order in which a request is decided |
## Where to go next
| If you want… | Go to |
|---|---|
| How a request finds its tenant | the **Routing** tab |
| The actual policy, in SQL | the **Isolation** tab, and [pooled Postgres](stratum:shc_multi_tenant_saas_example_pgpool) |
| What happens when one tenant is loud | the **Noisy neighbour** tab and [its runbook](stratum:shc_multi_tenant_saas_example_noisy) |
| The tenancy decision in four slides | the **Podium** tab |
| Rules, schema conventions, migrations | the **Handbook** tab |
| How isolation is proved | [six tests](stratum:shc_multi_tenant_saas_example_isolation_tests) |
| A domain modelled in this much depth | [`data-model-example`](/blueprintr/data-model-example) |
| Cardinality at a much larger scale | [`telemetry-model-example`](/blueprintr/telemetry-model-example) |
---
# The order model — twelve entities and the events that change them
URL: https://blueprintr.io/orgs/blueprintr/data-model-example
> The same retailer modelled from the inside: twelve operational entities with their keys and constraints, the events that move an order between them, the star schema the warehouse reads, and a dictiona…
# The order model
**Twelve entities, five subject areas, one sentence per table about what it is
allowed to know.**
> [!TLDR] What this blueprint is
> The ERD that normally exists as a screenshot in a wiki page nobody edits.
> Click **any entity** above for its columns, its keys, its constraints and the
> failure it was shaped by. The systems that pass this data around are in
> [`integration-map-example`](/blueprintr/integration-map-example).
## The five subject areas, and who owns each
| Area | Owner | Holds |
|---|---|---|
| Customer | Commerce Platform | who is buying, and where they say to send it |
| Catalogue | Merchandising | what can be bought, and what it costs when |
| Order | Commerce Platform | what was bought — the state of record |
| Fulfilment | Supply Chain Systems | what left the building, and what came back |
| Finance | Finance Systems | what money moved, append-only |
Ownership is not decoration: it decides who approves a migration, and it is why
a column that lives in the wrong area is a design problem rather than a
preference.
## The four decisions that explain most of the model
| | |
|---|---|
| **Snapshots where reproduction matters** | An [order line](stratum:shc_data_model_example_orderline) holds the SKU, description and price *as they were*. Reprinting a 2023 invoice must produce the 2023 invoice, so the model copies rather than joins. |
| **Money is append-only** | [Payments](stratum:shc_data_model_example_payment) and [refunds](stratum:shc_data_model_example_refund) are never updated. A correction is another row, which is what lets reconciliation compare what happened rather than what a row currently says. |
| **No stock lives here** | Only [reservations](stratum:shc_data_model_example_reservation) — promises against stock that has not moved. The warehouse owns the physical count, and every attempt to hold a copy produced two numbers that disagreed. |
| **Impossible beats checked** | Overlapping [prices](stratum:shc_data_model_example_price) fail *silently*, so they are prevented by an exclusion constraint. Order totals fail *loudly*, so they are checked nightly instead. |
## Reading the drawing
| | |
|---|---|
| Solid line | a foreign key the database enforces |
| Dashed | a relationship that exists through an event, not a constraint |
| Dotted | a snapshot — copied at a moment, never re-joined |
| `1..N` | cardinality as the constraints actually allow it |
The dotted line from [addresses](stratum:shc_data_model_example_address) to
[shipments](stratum:shc_data_model_example_shipment) is the one to look at twice: it is the model's
single deliberate denormalisation, and it is there because a customer fixing a
typo once changed the delivery address printed on a six-month-old invoice.
## Where to go next
| If you want… | Go to |
|---|---|
| The ERD with keys and cardinality | the **Entities and keys** tab |
| Actual DDL | the **Schema** tab |
| How an order moves between states | the **Events** tab |
| The reporting model | the **Warehouse** tab, and [the star schema](stratum:shc_data_model_example_warehouse) |
| Column-level documentation | the **Dictionary** tab |
| What is enforced and what is merely checked | [invariants](stratum:shc_data_model_example_invariants) |
| Which systems move this data | [`integration-map-example`](/blueprintr/integration-map-example) |
---
# Order to cash — the eleven systems that touch an order
URL: https://blueprintr.io/orgs/blueprintr/integration-map-example
> Every system an order passes through between the checkout and the ledger, and every hop between them: its transport, its schedule, its retry rule, its owning team, and what happens to the order when t…
# Order to cash at Kestrel Outdoor
**Eleven systems, sixteen hops, four of them outside our network.**
> [!TLDR] What this blueprint is
> The landscape drawing that usually exists as a photograph of a whiteboard.
> Click **any system** above for what it is, who owns it, which hops it takes
> part in and how it fails. The hops themselves are in the
> **Register** tab; the same order's data is modelled in
> [`data-model-example`](/blueprintr/data-model-example).
## The shape of it
An order is created in one of two [channels](stratum:shc_integration_map_example_web), lives its whole life
in [the order service](stratum:shc_integration_map_example_oms), and is told to the rest of the landscape
through [the event bus](stratum:shc_integration_map_example_bus). Money is settled by
[a PSP](stratum:shc_integration_map_example_psp) and recorded in [the ERP](stratum:shc_integration_map_example_erp). Goods are moved by
[a warehouse](stratum:shc_integration_map_example_wms) and [a carrier](stratum:shc_integration_map_example_carrier) that belong to other
companies. Everything else — [notifications](stratum:shc_integration_map_example_notify),
[the service desk](stratum:shc_integration_map_example_crm), [reporting](stratum:shc_integration_map_example_dw) — is a reader.
## The three things worth knowing before you read anything else
| | |
|---|---|
| **One system of record per fact** | The order's state is the order service's. Stock is the warehouse's. Everything else holds a copy, and a copy is never authoritative. |
| **Asynchronous unless somebody is waiting** | Three hops are synchronous and each has a written reason. The other thirteen are allowed to lag, which is why a warehouse outage is a backlog rather than an outage. |
| **Four hops leave the building** | The commerce platform, the PSP, the 3PL and the carriers. All four are designed for on the assumption that they will eventually be wrong — see [what we do not control](stratum:shc_integration_map_example_boundaries). |
## Where the money and the goods disagree
Payment is authorised at checkout and **captured at dispatch**, and dispatch
happens at a warehouse Kestrel does not operate. So the capture depends on
somebody else's webhook arriving, and roughly forty orders a month sit in a
state where one of the two has happened and the other has not.
That is not a defect to be designed out; it is the cost of not holding
customers' money for goods that have not moved. It is handled by a
[three-way reconciliation](stratum:shc_integration_map_example_reconcile) at 06:00 every morning, which is
the most important scheduled job in this landscape and the one most likely to be
mistaken for housekeeping.
## Reading the drawing
| | |
|---|---|
| Solid line | synchronous, or a publish |
| Dashed | an inbound webhook — someone else's timing |
| Dotted | a read-only feed |
| Number | position in an order's life, roughly |
## Where to go next
| If you want… | Go to |
|---|---|
| Every hop in one table | the **Register** tab |
| One order's whole life | the **One order** tab |
| What happens when a hop breaks | [failure modes](stratum:shc_integration_map_example_failures) |
| The rules a new hop is held to | the **Handbook** tab |
| The forty-five minutes this all feeds | the **Podium** tab |
| The data underneath it | [`data-model-example`](/blueprintr/data-model-example) |
---
# Platform assessment — Windlass, before the Series C
URL: https://blueprintr.io/orgs/blueprintr/platform-assessment-example
> An advisory engagement's findings pack. The client's estate was drafted by AI from their own documentation and corrected by hand, and all sixteen findings are pinned to the shape each one concerns wit…
# Windlass — platform assessment, August 2026
> [!TLDR] What this blueprint is
> Larkhill Advisory's four-week assessment of the Windlass platform, delivered
> as the working document rather than as a PDF. The drawing above was
> **drafted by Blueprintr's AI import** from Windlass's own Confluence,
> READMEs and Terraform, then corrected by hand. Click any shape: sixteen of
> them carry a finding with a severity, the evidence behind it and a
> remediation with an effort estimate.
**Client:** Windlass, field-service management SaaS · **By:** Larkhill
Advisory · **Fieldwork:** 4–29 August 2026 · **Readout:** 1 September 2026 ·
**Commissioned by:** the CTO, ahead of a Series C
## The headline
The platform is doing considerably more than it was built for and it is held
together by a small number of people. **Nothing here stops a Series C. Two
findings would stop a bad quarter from being recoverable.**
| Severity | Count | Findings |
|---|---:|---|
| Critical | 2 | [No tested restore](stratum:shc_platform_assessment_example_pg_main), [deploys need a window](stratum:shc_platform_assessment_example_web) |
| High | 6 | [Redis](stratum:shc_platform_assessment_example_redis), [scheduling](stratum:shc_platform_assessment_example_scheduler), [attachments](stratum:shc_platform_assessment_example_files), [templates](stratum:shc_platform_assessment_example_notify), [rate limits](stratum:shc_platform_assessment_example_alb), [accounting](stratum:shc_platform_assessment_example_accounting) |
| Medium | 6 | [Search](stratum:shc_platform_assessment_example_search), [pricing](stratum:shc_platform_assessment_example_pricing), [routing](stratum:shc_platform_assessment_example_routing), [SMS](stratum:shc_platform_assessment_example_sms), [replica lag](stratum:shc_platform_assessment_example_pg_replica), [job retries](stratum:shc_platform_assessment_example_jobs) |
| Low | 2 | [CDN headers](stratum:shc_platform_assessment_example_cdn), [payments SDK](stratum:shc_platform_assessment_example_payments) |
The scale those ratings are against is on
[how severity was decided](stratum:shc_platform_assessment_example_severity), and the ratings only mean what
they mean against it.
## Reading the drawing
The four **red** edges are findings, and they are the only lines that cross
the estate: [scheduling reading the monolith's database](stratum:shc_platform_assessment_example_scheduler),
[the routing call inside the request](stratum:shc_platform_assessment_example_routing), [SMS sent without a
retry](stratum:shc_platform_assessment_example_notify), and [the unreconciled accounting
sync](stratum:shc_platform_assessment_example_accounting), drawn dashed because it is nightly and dotted
around because nothing documents it. Everything else the monolith reads and
writes is one arrow between the Application and Data frames — thirty lines
would have made the four that matter invisible.
## The finding that is not on the drawing
**Nobody owns the [data tier](stratum:shc_platform_assessment_example_data).** Seventy engineers, nine
product squads, a platform squad of five whose remit is CI and infrastructure
code. Five of the sixteen findings live in that tier and three of the last six
incidents originated there.
The remediation is a name, this week. It is the cheapest recommendation in the
report and it has the widest effect.
## How the drawing was made, and why that matters
The AI import read 214 Confluence pages, 61 READMEs, 38 decision records and
the whole Terraform repository, and returned 27 connected shapes with the
prose filed behind them — as a **proposal**, accepted shape by shape. Twenty-
three survived unchanged.
The four that did not are the interesting part:
| Draft said | Truth | Became |
|---|---|---|
| [Scheduling](stratum:shc_platform_assessment_example_scheduler) is an independent service | It shares the monolith's database | [Finding 4](stratum:shc_platform_assessment_example_scheduler) |
| A reporting service exists | Decommissioned in 2024 | Deleted from the drawing |
| No accounting integration | [It exists and moves financial data nightly](stratum:shc_platform_assessment_example_accounting) | [Finding 14](stratum:shc_platform_assessment_example_accounting) |
| Two services, one box each | Three deployments | Corrected |
The draft was not wrong about what it read. The documents were wrong, and the
gap between them is itself a finding — see
[the AI draft](stratum:shc_platform_assessment_example_ai_draft).
## The recommendation is the order
| Horizon | Months | What |
|---|---|---|
| [1 · Stop the bleeding](stratum:shc_platform_assessment_example_horizon_1) | 0–3 | Four items, none of them architecture, none of them requiring a decision |
| [2 · Make it deployable](stratum:shc_platform_assessment_example_horizon_2) | 3–9 | The ability to change things at all |
| [3 · Then split it](stratum:shc_platform_assessment_example_horizon_3) | 9–18 | The architecture, once it is safe to change |
A team that starts at horizon 3 ends up with several services sharing one
untested database.
## The tabs
| Tab | What it holds |
|---|---|
| **The estate** | This — the platform, with a finding on every shape that has one |
| **Findings** | All sixteen in one table, and the severity scale |
| **Where it should go** | The whiteboard from the readout, exported from Excalidraw |
| **Readout** | The deck presented on 1 September, with the presenter's notes |
| **The report** | The written report: scope, summary, an explanation of the platform, risk, recommendations |
---
# Multi-region failover, tested every quarter
URL: https://blueprintr.io/orgs/blueprintr/region-failover-example
> Two AWS regions with recovery objectives on every service, a twelve-step failover runbook drawn as a diagram, and the evidence from the last real failover attached to the steps it exercised. The runbo…
# Quayside — eu-west-1 active, us-east-1 standby
> [!TLDR] What this blueprint is
> The runbook and the diagram are the same document. Every service above
> carries its **recovery objective and recovery point** in its stratum; the
> **Failover runbook** tab is the procedure drawn as twelve steps, each one
> opening on what it actually took during the last real failover; and the
> evidence from that failover — the timeline, the DNS configuration, the
> database events, the latency trace — is attached to the steps it exercised.
**Platform:** Quayside, container visibility for freight forwarders ·
**Operated by:** Quayside Platform Engineering · **Last failover:** 18 July
2026, a planned test of production · **Next:** 17 October 2026
## The objectives that matter
| Service | Recovery time | Recovery point | Why that number |
|---|---|---|---|
| [Tracking API](stratum:shc_region_failover_example_ew1_api) | 30 min | 60 s | Customs filing deadlines; customers' own fallback procedures start at 30 minutes |
| [Customs documents](stratum:shc_region_failover_example_ew1_docs) | 30 min | 15 min | Documents regenerate from the entry record, so bucket lag is survivable |
| [Event workers](stratum:shc_region_failover_example_ew1_track) | 4 h | 60 s | The [feeds](stratum:shc_region_failover_example_carriers) queue. Late data beats no platform |
| [Session cache](stratum:shc_region_failover_example_ew1_cache) | none | none | Rebuilt, not recovered |
Different services get different numbers. A design that gives everything the
same objective has not asked the question.
## What was achieved, last time
| | Objective | 18 July 2026 |
|---|---|---|
| Recovery time, tracking API | 30 min | **24 min 10 s** |
| Recovery point | 60 s | **9 s** |
| Customer-visible errors | — | 2 min 40 s |
| Verification checks passed | 12 of 12 | 11, then 12 after a 4-minute live fix |
The full account is on the **Game day** tab, including the one check that
failed and the [finding that is still open](stratum:shc_region_failover_example_findings).
## Reading the drawing
The two regions are **not** mirrors, and drawing them as mirrors would be the
first thing this diagram got wrong. [eu-west-1](stratum:shc_region_failover_example_ew1) runs 34 tasks and
takes every write; [us-east-1](stratum:shc_region_failover_example_ue1) runs four, holds a
[headless database replica](stratum:shc_region_failover_example_ue1_rds) and an
[empty cache](stratum:shc_region_failover_example_ue1_cache), and costs about 19% of the active region.
The red edges are replication: [Aurora Global](stratum:shc_region_failover_example_ew1_rds) for the
database, cross-region replication for [documents](stratum:shc_region_failover_example_ew1_s3). They are
the only two things that carry state across the Atlantic, and their lag is
where both recovery points come from.
## The two decisions worth arguing about
**[Automatic failover is switched off](stratum:shc_region_failover_example_route53).** The health check
pages a human; a human flips the record. Three of the eight unhealthy events
in three years would have triggered a failover that was the wrong answer.
**The standby is [us-east-1](stratum:shc_region_failover_example_ue1), not another European region.**
Engineers are in that region every week for other reasons, so its quotas,
certificates and IAM policies are exercised by ordinary work. The cost is
data residency: eleven customers are contractually EU-only and their records
are [excluded from replication](stratum:shc_region_failover_example_ue1_s3), which means they are
unavailable during a failover. That is stated in their contracts and on the
status page.
## The tabs
| Tab | What it holds |
|---|---|
| **Both regions** | This — the estate, with objectives on every service |
| **Continuum — both regions** | The same two regions from a read-only scan |
| **Failover runbook** | Twelve steps; each opens on its timing and its evidence |
| **The cutover** | A sequence of the flip itself, and the health-check states |
| **Game day — 18 July** | What the last real failover found |
| **Service register** | Every objective in one table, and how each is measured |
---
# Datacentre exit — Halverstone, wave 3 in flight
URL: https://blueprintr.io/orgs/blueprintr/datacentre-exit-example
> A migration programme mid-flight: the client's own draw.io estate annotated wave by wave, the landing zone the workloads land in, a cutover runbook and a rollback point on every workload, and the stee…
# Halverstone Group — datacentre exit, month 8 of 14
> [!TLDR] What this blueprint is
> The live artefact of a migration programme, not a proposal. The drawing
> above is **Halverstone's own draw.io export**, imported unchanged; the only
> thing Marchmont added was a wave number on each box. Click any workload for
> its cutover runbook, the person at Halverstone who owns it, and the time on
> cutover day after which it cannot be moved back.
**Client:** Halverstone Group, specialty insurer · **Delivered by:** Marchmont
Partners · **Reported:** monthly to steering, last on 3 September 2026 ·
**Hard date:** the Farnborough colo contract ends 31 March 2027
## Where the programme is today
| | Workloads | State |
|---|---:|---|
| [Wave 1 — foundations](stratum:shc_datacentre_exit_example_wave_1) | 22 | Cut over 18 April. Complete, one rack outstanding |
| [Wave 2 — broker-facing](stratum:shc_datacentre_exit_example_wave_2) | 14 | Cut over 20 June. Complete, rebuilt rather than lifted |
| [Wave 3 — claims and documents](stratum:shc_datacentre_exit_example_wave_3) | 9 | **In flight.** Window 19–20 September |
| [Wave 4 — policy and actuarial](stratum:shc_datacentre_exit_example_wave_4) | 14 | Not started. Method decision due 14 November |
| [Two exceptions](stratum:shc_datacentre_exit_example_stays) | 2 | Move into a [managed cage](stratum:shc_datacentre_exit_example_st_cage) on 14 February 2027 |
Thirty-six of sixty-one workloads are out of the two halls. Nine move in
seventeen days. The fourteen that have not started are the hard ones, and
they have one usable weekend in March with one weekend of fallback behind it.
## Reading the drawing
| Colour | Means |
|---|---|
| Green | Moved and running in [eu-west-1](stratum:shc_datacentre_exit_example_aws_lz) |
| Yellow | In this month's cutover window |
| Blue | Planned, wave 4 |
| Red | Not going to AWS — see [the exceptions](stratum:shc_datacentre_exit_example_stays) |
The two halls are [DC1 Croydon](stratum:shc_datacentre_exit_example_hall_croydon), an owned room with a
single power feed, and [DC2 Farnborough](stratum:shc_datacentre_exit_example_hall_farnborough), fourteen
contracted racks with a contract that ends. Croydon has no invoice that stops
and is therefore the harder of the two to finish.
## What is on each workload
Every box on the drawing opens on the same four facts, because those are the
four an exit runs on:
1. **Which wave moves it**, and whether that wave has happened.
2. **Who at Halverstone owns it** — a named role that signs the verification.
3. **How it moves** — lifted, rebuilt, or not moving at all.
4. **Its rollback point** — the time on cutover day after which the old estate
can no longer be given the data back.
Point 4 is the one that is usually missing from a migration plan. It is
different for every workload: 14:00 for the
[claims workbench](stratum:shc_datacentre_exit_example_claims), 20:00 for
[imaging](stratum:shc_datacentre_exit_example_imaging) because a queue can be replayed, and about four
hours for [policy admin](stratum:shc_datacentre_exit_example_policy_admin) because a bound policy is a
contract of insurance.
## The tabs
| Tab | What it holds |
|---|---|
| **Current estate** | This — the client's drawing, annotated |
| **Waves** | The programme's status in one picture; each wave opens on its plan |
| **Landing zone** | The design the workloads land in |
| **Continuum — landing zone scan** | The same accounts from a read-only scan, for comparing design against reality |
| **Steering readout** | The deck presented on 3 September, with the presenter's notes on each slide |
| **Exit handbook** | The standards Halverstone keeps after Marchmont leaves |
## Why this is a blueprint rather than a status report
A programme reported in slides forks the moment the pack is emailed. This one
updates in place: the wave colours on the drawing change when a wave lands,
the [RAID log](stratum:shc_datacentre_exit_example_raid) is a stratum Halverstone can open, and the
[decision log](stratum:shc_datacentre_exit_example_decisions) is the same document the auditor will read
in 2028.
---
# Rivulet — a webhook relay, explained
URL: https://blueprintr.io/orgs/blueprintr/tech-explanations-example
> What a project README wants to be and cannot: one architecture drawing whose every box opens on the component behind it, the state machine that defines the delivery guarantee, the schema that implemen…
# Rivulet
**A self-hosted webhook relay. One binary, one PostgreSQL, no broker.**
> [!TLDR] What this blueprint is
> The README this project would have if a README could hold a diagram whose
> boxes open. Click **any component** above for what it does, why it is shaped
> that way, and what it costs. The **Docs** tab is the reference you keep in a
> second tab; the **Podium** tab is the five-minute version for a brown-bag.
```bash
docker run -d -p 8080:8080 \
-e RIVULET_DATABASE_URL='postgres://…' \
-e RIVULET_SIGNING_SECRET='…' \
ghcr.io/rivulet/rivulet:1
```
## The problem
Your service needs to tell a few hundred customers that something happened.
Their endpoints are slow, occasionally down, and sometimes return 200 after
doing nothing. You do not want any of that in your request path, and you
especially do not want it in your codebase.
The usual answer is a retry loop bolted onto the application, which works right
up until one customer's endpoint starts taking thirty seconds and takes
everybody else's webhooks with it.
## What Rivulet does
| | |
|---|---|
| **Accepts** | `POST /v1/events` returns `202` in ~2 ms, once the row is durable |
| **Stores** | [PostgreSQL](stratum:shc_tech_explanations_example_pg) is the only store — it is also the queue |
| **Delivers** | [Workers](stratum:shc_tech_explanations_example_workers) claim due work with `SKIP LOCKED`, POST it, and record every try |
| **Retries** | [Twelve attempts over ~26 hours](stratum:shc_tech_explanations_example_retries), exponential with full jitter |
| **Isolates** | A [circuit breaker per endpoint](stratum:shc_tech_explanations_example_breaker) — one bad subscriber affects only itself |
| **Never hides** | Terminal failures become [dead letters](stratum:shc_tech_explanations_example_dlq) you can search and replay |
## The guarantee, stated plainly
**At least once, in order per subscriber, never lost, never silent.**
Not exactly-once — nothing that speaks HTTP can promise that, because a request
that times out may or may not have been processed and the network will not tell
you which. Rivulet gives you at-least-once plus a stable `rivulet-id`; your
handler deduplicates on it in three lines of SQL. That whole trade, including
what ordering costs you, is in [the delivery guarantee](stratum:shc_tech_explanations_example_guarantee).
## The one interesting decision
There is no broker. PostgreSQL is the queue, claimed with
`SELECT … FOR UPDATE SKIP LOCKED`, because one store means one consistency
story and one backup. It does about **4,000 deliveries a second** on modest
hardware, and past that you should use a broker — a boundary that is measured
rather than hand-waved, in
[ADR 1 — why Postgres, not a broker](stratum:shc_tech_explanations_example_adr_postgres).
The other decision worth reading is
[ADR 2 — one row per attempt](stratum:shc_tech_explanations_example_adr_attempts), which is why the console
can tell you what a subscriber's endpoint returned at 02:14 three weeks ago.
## Where to go
| If you want to… | Go to |
|---|---|
| Run it in five minutes | **Docs → Quickstart** |
| Understand the delivery semantics | [the delivery guarantee](stratum:shc_tech_explanations_example_guarantee) |
| Tune retries | [retries and backoff](stratum:shc_tech_explanations_example_retries) |
| Deploy it properly | **Docs → Deployment** |
| Operate it | [operating Rivulet](stratum:shc_tech_explanations_example_operating) and **Docs → Operating** |
| Verify a signature | **Docs → API reference** |
| Read the schema | [schema](stratum:shc_tech_explanations_example_schema) |
| Send a patch | [contributing](stratum:shc_tech_explanations_example_contributing) |
## Non-goals
No payload transformation, no fan-in from other queues, no subscription UI, no
hosted version, and no exactly-once. Each of those has a one-line reason in
[contributing](stratum:shc_tech_explanations_example_contributing), because a project that cannot say what it
will not do eventually does all of it badly.
---
# Ship it — from commit to production
URL: https://blueprintr.io/orgs/blueprintr/devops-example
> The whole delivery path for a service: trunk-based branches, the four gates that cannot be waived, a signed supply chain, Argo CD as the only deploy path, progressive rollout across two regions, and t…
# From your branch to production, in about 42 minutes
> [!TLDR] What this blueprint is
> The path a change takes at Fernway from a branch to serving real traffic, and
> every gate, artefact and signal on the way. Click **any box** for what it
> does, what it costs and what it refuses. If you are new here, start with the
> **Podium** tab — it is the same story in six slides and it is what your buddy
> would walk you through on day four.
**Owner:** Platform Engineering · **Audience:** every engineer ·
**Deploys:** ~40/day · **Lead time:** 42 min p50 · **Change failure rate:** 1.2%
· **Time to restore:** 6 min p50
## The four sentences that are the whole system
1. **`main` is always deployable.** Branches live hours; work that is not ready
ships dark behind a [flag](stratum:shc_devops_example_flags).
2. **Four gates, none waivable.** Tests, scans, signature, and thirty green
minutes on [staging](stratum:shc_devops_example_stage).
3. **Only [Argo CD](stratum:shc_devops_example_argocd) deploys.** No human and no CI job writes to
production; git is the desired state and the reconciliation loop is the only
write path.
4. **Nothing goes to 100% at once.** [Progressive rollout](stratum:shc_devops_example_progressive)
across two regions, with automated analysis between every weight increase.
## Where the time goes
| Stage | Duration | Blocking |
|---|---|---|
| CI — [build](stratum:shc_devops_example_build), [test](stratum:shc_devops_example_test), [scan](stratum:shc_devops_example_scan) | 5 min p95 | yes |
| [Image](stratum:shc_devops_example_image), [sign](stratum:shc_devops_example_sign), push | 90 s | yes |
| Deploy to [staging](stratum:shc_devops_example_stage) + integration and e2e | 12 min | yes |
| Staging soak | 30 min | yes — this is the deliberate cost |
| Progressive rollout to [prod-eu](stratum:shc_devops_example_prod_eu) | 25 min | — |
| [prod-us](stratum:shc_devops_example_prod_us) | +30 min | — |
The 30-minute soak is 70% of the lead time and it is the reason the change
failure rate is 1.2%. It is a stated trade, revisited quarterly in
[the four numbers](stratum:shc_devops_example_metrics_that_matter), and it has survived every
review so far.
## What happens when it goes wrong
**[Revert the commit.](stratum:shc_devops_example_rollback)** Argo reconciles and production is
back in about four minutes. Do not fix forward under pressure — a revert is a
version that has already run in production, and a hotfix written during an
incident is the least-reviewed code you will ship all year.
The one change that cannot be reverted is a destructive migration, which is why
[database changes](stratum:shc_devops_example_db_changes) uses expand/contract with the contract
step days later, alone, with a DBA present.
## Where to go next
| If you are… | Start at |
|---|---|
| New here | the **Podium** tab, then [branching and review](stratum:shc_devops_example_branching) |
| Adding a service | [environments and promotion](stratum:shc_devops_example_environments) |
| Changing a schema | [database changes](stratum:shc_devops_example_db_changes) |
| On call this week | [alerting and on-call](stratum:shc_devops_example_page) and [rollback](stratum:shc_devops_example_rollback) |
| Fixing a broken pipeline | [break-glass](stratum:shc_devops_example_break_glass) |
| Asked "why is it so slow" | [the four numbers](stratum:shc_devops_example_metrics_that_matter) |
The cluster all of this deploys onto is documented separately in
[Kubernetes platform reference](/blueprintr/kubernetes-reference).
---
# Client design pack — Brightwater Foods managed platform
URL: https://blueprintr.io/orgs/blueprintr/design-sharing-example
> The whole artefact a consultancy hands a client: the proposed design, the options that were rejected and why, the risks, what it costs, the whiteboard it came from, the deck it was presented with, and…
# Brightwater Foods — managed platform, version 1.0
> [!TLDR] What this is
> The design pack Arbor Digital presented to Brightwater Foods on 2 July. Not a
> summary of it — **it is the deliverable**. The proposal, the options we
> rejected, the risks, the commercial shape, the whiteboard it came from, the
> deck it was walked through with, and the handbook Brightwater keep afterwards
> are all tabs above. Click any box on the diagram for the detail behind it.
**Client:** Brightwater Foods Ltd · **Prepared by:** Arbor Digital ·
**Version:** 1.0, 2 July · **Status:** presented, awaiting sign-off ·
**Recommended option:** B
## The brief, in the client's words
Four things, all lifted from the discovery workshop and the plant-manager
session. Everything in this pack traces to one of them:
1. One platform for ERP and WMS, one version, all sites.
2. No plant stoppage during migration.
3. Somebody to run it 24×7 who is not one person's mobile number.
4. Nothing production-critical left in a comms room at a food plant.
## What we propose
Four Brightwater sites on a dual-carrier [SD-WAN overlay](stratum:shc_design_sharing_example_sdwan) into a
single-tenant [platform](stratum:shc_design_sharing_example_erp) that Arbor hosts and operates, with
[24×7 service](stratum:shc_design_sharing_example_servicedesk), [evidenced restores](stratum:shc_design_sharing_example_db) and a
[DR site](stratum:shc_design_sharing_example_dr) 100 km away. WMS converges onto one version as a side
effect of the move; ERP moves **as-is** and is upgraded later, separately.
| Question | Answer | Detail |
|---|---|---|
| Why not refresh in place? | It leaves group ERP in a single-feed room at a food plant | [options considered](stratum:shc_design_sharing_example_options) |
| Why not public cloud? | More expensive at this scale, and needs skills a three-person team does not have | [options considered](stratum:shc_design_sharing_example_options) |
| What worries you most? | EDI cutover with 34 trading partners | [risk register](stratum:shc_design_sharing_example_risks) |
| How long? | 16 weeks, plus 4 weeks hypercare | [migration plan](stratum:shc_design_sharing_example_migration) |
| What does it cost? | Four separate numbers, deliberately not bundled | [commercial summary](stratum:shc_design_sharing_example_commercials) |
| Who does what? | | [RACI](stratum:shc_design_sharing_example_raci) |
| What have you assumed? | Eight assumptions, seven exclusions, one of them unowned | [assumptions and exclusions](stratum:shc_design_sharing_example_assumptions) |
## How to read the tabs
| Tab | What it is | Who it is for |
|---|---|---|
| **Proposed design** | This — the architecture and the case for it | Everyone |
| **Client walkthrough** | The deck, with the presenter's notes attached to each slide | Whoever presents it next |
| **Options and cost** | The three options priced and compared | Sponsor and FD |
| **Workshop board** | The 14 May whiteboard, transcribed not tidied | Anyone asking "where did this come from" |
| **Handover** | The service handbook Brightwater keep after go-live | Brightwater IT and plant leads |
## Why this is a link and not a PDF
A design pack emailed as a PDF forks the moment it is opened. Three weeks later
there are five versions, the sponsor is reading the second one and the FD has
one with a price that changed. This pack is one surface: it updates in place,
every version is in the history, and the [sign-off record](stratum:shc_design_sharing_example_signoff) says
which version each audience has actually seen.
That is the point of the [sign-off record](stratum:shc_design_sharing_example_signoff) being a stratum
Brightwater can open rather than a table in our internal tracker.
---
# Lakehouse, ingest to dashboard
URL: https://blueprintr.io/orgs/blueprintr/lakehouse-platform
> Meridian's analytics estate from Track event to executive dashboard: three feeds into a bronze/silver/gold lake, nightly models, Redshift and Athena — with a podium tour, a live Continuum warehouse sc…
# Meridian lakehouse — from Track event to dashboard
> [!TLDR] What this blueprint is
> The analytics estate Data Platform runs in account 555566667777. Track's event stream and Aurora CDC (from the [landing zone](/blueprintr/aws-landing-zone)) plus nightly partner SFTP drops land in a bronze/silver/gold lake on S3; Glue conforms it, Step Functions orchestrates it, Redshift and Athena serve it. The **Pipeline tour** tab walks it in six slides; the **Continuum — analytics account** tab is a live read-only scan of this account — that is where "Continuum on the warehouse" lives, and it wins any argument with the drawing.
**Owner:** Data Platform · **Account:** [555566667777](stratum:shc_lakehouse_platform_analytics_account) · **Region:** eu-west-1 · **All times:** Europe/Amsterdam
## The seven hops
Freshness is promised per hop, not as one blurry end-to-end number. Click any hop's shape (or the links below) for the full table — SLA, typical latency, how it is measured, when it pages, who owns it.
| # | Hop | Cadence | Freshness SLA | Stratum |
|---|---|---|---|---|
| 1 | Track events → bronze | stream, 15 min flush | ≤ 15 min | [Hop 1 — events to bronze](stratum:shc_lakehouse_platform_firehose) |
| 2 | Aurora CDC → bronze | stream, 15 min flush | ≤ 15 min | [Hop 2 — CDC to bronze](stratum:shc_lakehouse_platform_msk_connect) |
| 3 | Partner drops → bronze | nightly | in bronze by 05:00 | [Hop 3 — partner drops](stratum:shc_lakehouse_platform_sftp_drops) |
| 4 | Bronze → silver | hourly at :10 | complete by :45 | [Hop 4 — bronze to silver](stratum:shc_lakehouse_platform_jobs_silver) |
| 5 | Silver → gold | nightly at 04:30 | complete by 05:30 | [Hop 5 — silver to gold](stratum:shc_lakehouse_platform_jobs_gold) |
| 6 | Gold → warehouse | nightly load | loaded by 06:00 | [Hop 6 — gold to warehouse](stratum:shc_lakehouse_platform_serving) |
| 7 | Warehouse → dashboards | 06:30 + 15 min ops feed | fresh by 06:30 | [Hop 7 — warehouse to dashboards](stratum:shc_lakehouse_platform_dashboards) |
## Why it is shaped this way
- **S3 is the source of truth; the warehouse is a cache.** Everything in [Redshift](stratum:shc_lakehouse_platform_redshift) can be rebuilt from the [gold](stratum:shc_lakehouse_platform_gold) and [silver](stratum:shc_lakehouse_platform_silver) buckets — losing the cluster is an inconvenience, not an incident. The reasoning (and the rejected all-in-Redshift design) is in the [decision log](stratum:shc_lakehouse_platform_decision_log).
- **Bronze is append-only, so everything is replayable.** No layer ever edits data in place; backfills are "write it again, then swap" — the [backfill runbook](stratum:shc_lakehouse_platform_backfill_runbook) is short because the invariants are strong.
- **Contracts, not tribal knowledge.** Every dataset has a producer, a schema version, a freshness SLA and a breaking-change process — the **Data contracts & SLAs** tab holds the registry, and the [freshness monitor](stratum:shc_lakehouse_platform_freshness_mon) measures the SLAs the contracts declare.
- **Quality gates fail loudly and small.** A bad partition goes to [quarantine](stratum:shc_lakehouse_platform_dq_gates) and pages; it never silently reaches a dashboard, and it never blocks the healthy partitions around it.
- **Costs have guardrails, not vibes.** Athena queries die at 500 GB scanned, the workgroup alarms at 60 TB/month, and the staging warehouse pauses outside working hours — see [cost guardrails](stratum:shc_lakehouse_platform_cost_guard).
## Reading order
1. This tab, sources to consumers — the shape of the pipeline.
2. **Pipeline tour** — the same story as a six-slide podium walk, with presenter notes.
3. **Data contracts & SLAs** — the dataset registry, the tiering ladder and an example contract.
4. **Continuum — analytics account** — the live scan beside the drawing.
Upstream: the events bucket and the Aurora replication slot belong to the [multi-account AWS landing zone](/blueprintr/aws-landing-zone); the producers that emit Track events run on the [Kubernetes platform](/blueprintr/kubernetes-reference).
---
# Zero-trust access review
URL: https://blueprintr.io/orgs/blueprintr/zero-trust-review
> Meridian's quarterly entitlement review: the draw.io flow the team actually runs, each step carrying its live ServiceNow ticket, the access topology it polices, and the controls and evidence that prov…
# Quarterly access review — the flow, with its tickets attached
> [!TLDR] What this blueprint is
> The entitlement review Meridian runs every quarter, drawn by Identity & Security in draw.io and imported here unchanged — same shapes, same ids. Click any step: its stratum is the **live ServiceNow record for the 2026-Q3 run** (ticket, owner, dates, state), plus the tooling and the definition of done. The **Execution plane** shows the systems behind those boxes; genuine ServiceNow / PagerDuty / NetBox tabs are attached by Continuum Link after the Lab seed.
**Owner:** Identity & Security · **Cadence:** quarterly ([why not monthly](stratum:shc_zero_trust_review_decision_log)) · **This run:** 2026-Q3, [REQ0031907](stratum:shc_zero_trust_review_start), opened 2026-08-03, closes 2026-08-28
## The run at a glance
| Step | Ticket | State (2026-08-24) |
|---|---|---|
| [Export entitlements](stratum:shc_zero_trust_review_step_export) | RITM0048201 | Closed complete |
| [Group by owner](stratum:shc_zero_trust_review_step_group) | RITM0048202 | Closed complete |
| [Owner reviews](stratum:shc_zero_trust_review_step_review) | RITM0048203 | Closed complete — 49/49 owners |
| [Attest & sign](stratum:shc_zero_trust_review_step_attest) | RITM0048204 | Closed complete — 1,743 retained |
| [Revoke access](stratum:shc_zero_trust_review_step_revoke) | RITM0048205 | Closed complete — 141 revoked |
| [Escalations](stratum:shc_zero_trust_review_step_escalate) | RITM0048208 | Closed complete — 6 recovered |
| [Auto-revoke](stratum:shc_zero_trust_review_step_autorevoke) | RITM0048209 | Closed complete — 2 owners, 31 lines |
| [Apply changes](stratum:shc_zero_trust_review_step_apply) | RITM0048206 | Closed complete — diff clean |
| [Evidence pack](stratum:shc_zero_trust_review_evidence) | RITM0048207 | Closed complete — archived |
| [Quarter close](stratum:shc_zero_trust_review_quarter_close) | REQ0031907 | In progress — sampling underway |
## Why it is shaped this way
- **The diamond defaults to revoke.** "Still needed?" is answered with evidence or the access goes — the argument is [D-02 in the decision log](stratum:shc_zero_trust_review_decision_log). Doubt is not a retention criterion.
- **Silence is an outcome, not a delay.** The exception lane runs on a clock: [day-5 gate](stratum:shc_zero_trust_review_gate_silent), [manager escalation](stratum:shc_zero_trust_review_step_escalate), [auto-revoke at day 10](stratum:shc_zero_trust_review_step_autorevoke). Nobody can stall the quarter by not answering.
- **Every step leaves a record.** Each box is a ServiceNow item under one REQ; the [evidence pack](stratum:shc_zero_trust_review_evidence) is assembled from those records, not reconstructed afterwards. Tickets live in ServiceNow, not the platform tracker — that is [D-03](stratum:shc_zero_trust_review_decision_log).
- **The review reads from the same sources it fixes.** The [export](stratum:shc_zero_trust_review_step_export) and the [apply](stratum:shc_zero_trust_review_step_apply) steps hit the identical six systems, so the closing diff proves the revocations landed — see [Entitlement sources](stratum:shc_zero_trust_review_sources).
## Reading order
1. This tab — the flow and its tickets, left to right.
2. **Execution plane** — the orchestration hosts behind every box and the real Continuum Link join that puts provider tabs on the step.
3. **Access topology** — where the entitlements actually live and get enforced.
4. **Controls & evidence** — the control matrix this run satisfies, and how a failed attestation becomes a revocation within 24 hours.
5. **Review checklist** — the literal checklist an operator copies into next quarter's ticket.
The estates under review are documented in their own blueprints: [Multi-account AWS landing zone](/blueprintr/aws-landing-zone) (the access model and guardrails), [Azure hub-and-spoke, end to end](/blueprintr/azure-hub-spoke) (the identity spoke), and [Network site topology](/blueprintr/network-site-topology) (the campus the firewalls guard).
---
# Global WAN network diagram
URL: https://blueprintr.io/orgs/blueprintr/global-wan-diagram
> Meridian's seven-site WAN across EMEA, AMER, APAC and the Middle East: the original Excalidraw workshop design beside the Vellum topology that was built, with every circuit, route preference and failo…
# Meridian global WAN — design record and production truth
> [!TLDR] What this blueprint is
> Seven sites across four operating regions, the circuits between them, and the route policy that decides which path carries traffic. The Excalidraw canvas above is the Q1 workshop design; **As built** is the production topology beside it. Click a site or circuit on either surface for addressing, ownership, service identifiers, failure behaviour and the evidence expected during a test.
**Owner:** Network Engineering · **NOC channel:** `#netops` · **Routing domain:** AS 65010 · **Address plan:** on-premises `10.0.0.0/11`
## What the workshop decided
| Decision | Why it survived design review | Detail |
|---|---|---|
| Rotterdam remains the route hub | Both cloud on-ramps and the largest campus already terminate there; moving the hub would add failure modes, not remove one | [RTM workshop cluster](stratum:shc_global_wan_diagram_ws_rtm) |
| MPLS remains the EMEA primary | Predictable loss and QoS for warehouse voice/scanner traffic; branches are close enough that latency is uninteresting | [EMEA transport](stratum:shc_global_wan_diagram_mpls_rtm_ham) |
| Leased circuits carry intercontinental primary traffic | Replication volumes make deterministic capacity cheaper than debugging peak-hour internet paths | [Atlantic](stratum:shc_global_wan_diagram_lease_rtm_ewr) · [APAC](stratum:shc_global_wan_diagram_lease_rtm_sin) |
| SDWAN is an independent backup | Every backup circuit uses a carrier and physical entrance distinct from the primary; a second logical service over the same duct is not resilience | [backup policy](stratum:shc_global_wan_diagram_sdwan_ctrl) |
| Singapore relays Dubai's leased path | The measured demand does not justify a second Europe–Middle East circuit; direct internet overlay remains available for interactive flows | [SIN–DXB](stratum:shc_global_wan_diagram_lease_sin_dxb) |
The LAN side deliberately stops at each site prefix. Rotterdam's core, access switches, WLAN and desk ports live in [Network site topology](/blueprintr/network-site-topology); this blueprint begins where the site route leaves the campus edge. Together they are one network split at an ownership seam, not two competing diagrams.
## How to compare design with reality
1. Start with the hand-drawn surface and open the stratum on the path being discussed.
2. Switch to **As built** and find the named edge device. Its stratum is the configuration and operational source of truth.
3. Use **Circuits & routing** for service ids, BGP preference and prefix filters.
4. Use **Operations** when a path is impaired; a green carrier portal does not close an incident.
> [!IMPORTANT] A line is not a service record
> The canvas explains topology. The circuit register owns provider ids, demarcations, committed bandwidth and support clocks; the failover runbook owns what “working” means. A diagram without those strata would be decoration.
---
# Kubernetes platform reference
URL: https://blueprintr.io/orgs/blueprintr/kubernetes-reference
> The reference for track-prod, Meridian's EKS platform: a clickable Vellum topology with strata across the estate, mermaid sequences for the control loops, the platform handbook as a long-form folium,…
# track-prod — how the platform hangs together
> [!TLDR] What this blueprint is
> The reference for `track-prod`, the EKS cluster that runs Meridian Track. The topology above is clickable — nearly every shape carries a stratum with its real configuration. **Control loops** tells the platform's behaviour over time as mermaid sequences, **The concepts** embeds the long-form platform handbook, and **Add-ons & versions** is the upgrade ledger.
**Owner:** Platform Engineering · **On-call:** `#track-oncall` · **Cluster:** `track-prod`, EKS 1.31 · **Runs in:** [production account 777788889999](/blueprintr/aws-landing-zone)
## Where you are standing
The cluster lives in the prod VPC's app subnets (`10.40.8.0/21`, AZ a + b) of the landing zone. Everything from the [ALB](stratum:shc_kubernetes_reference_alb) inwards is this blueprint; everything around it — the subnets, the transit gateway, ECR, Aurora, Redis — belongs to [Multi-account AWS landing zone](/blueprintr/aws-landing-zone) and is only pinned here where the two touch.
## How to read the topology
| Region of the diagram | What it is | Start with |
|---|---|---|
| Top band | The [AWS-managed control plane](stratum:shc_kubernetes_reference_control_plane) — the brain, not a place workloads run | [kube-apiserver](stratum:shc_kubernetes_reference_api) |
| Left column | The [request path](stratum:shc_kubernetes_reference_ingress) from the internet to a pod | [ingress-nginx](stratum:shc_kubernetes_reference_nginx) |
| Centre | [Tenancy](stratum:shc_kubernetes_reference_tenancy) — team namespaces with quota + NetworkPolicy walls | [team-track](stratum:shc_kubernetes_reference_ns_track) |
| Right column | The [GitOps loop](stratum:shc_kubernetes_reference_argo) and the [platform add-ons](stratum:shc_kubernetes_reference_repo) | [Argo CD](stratum:shc_kubernetes_reference_argo) |
| Bottom band | The [three node pools](stratum:shc_kubernetes_reference_node_pools) all of it schedules onto | [app pool](stratum:shc_kubernetes_reference_pool_app) |
## Two loops to keep in your head
```
request: client → CloudFront → ALB :443 → ingress-nginx → Service track-api → pod
gitops: merge to track-deploy → Argo CD sync → kube-apiserver → controllers → new pods → ALB targets healthy
```
The solid edges above draw the first loop; the dashed violet edges draw the second. Both are unpacked step by step in the **Control loops** tab — that tab is the one to read before your first deploy.
## Reading order
1. This tab, clicking as you go — the shape of the platform.
2. [Control loops](?tab=1) — what actually happens when you merge, and how the platform scales itself.
3. [The concepts](?tab=2) — the platform handbook: workloads, networking, storage, tenancy, operations.
4. [Add-ons & versions](?tab=3) — what is installed, at which version, and who upgrades it.
Your first deploy is a guided walk, not a reading exercise — the deck in [Engineer onboarding](/blueprintr/engineer-onboarding) does it click by click. The shipment events the platform emits are consumed downstream in [Lakehouse, ingest to dashboard](/blueprintr/lakehouse-platform), and the quarterly review of who holds access here is part of [Zero-trust access review](/blueprintr/zero-trust-review).
---
# Your first two weeks
URL: https://blueprintr.io/orgs/blueprintr/engineer-onboarding
> Meridian's new-engineer onboarding in one link: a two-week journey map with a stratum on every milestone, the engineering handbook as a folium, and four podium decks — dev environment, first deploy, r…
# Your first two weeks at Meridian — start here
> [!TLDR] One link
> This blueprint IS Meridian's engineer onboarding. The map above is your fortnight: click any day card for what "done" means, who to ping and the links you need. The other tabs hold the reading (one folium — the engineering handbook) and the doing (four podium decks). If you bookmark one thing this week, bookmark this.
**Owner:** Developer Experience · **Audience:** every new engineer, any team · **Format:** [why one link instead of a wiki](stratum:shc_engineer_onboarding_decision_one_link) · **Your buddy:** [what they're for](stratum:shc_engineer_onboarding_buddy_programme)
## How the tabs work
| Tab | What it is | When to use it |
|---|---|---|
| **The two weeks** | The journey map above, a stratum per milestone | All fortnight — it is the checklist |
| **The reading** | The Meridian engineering handbook, as a browsable folium | Week 1, ~90 minutes total |
| **Podium — reading a blueprint** | How to read this site: tabs, strata, foliums, Continuum | Day 2, ten minutes |
| **Podium — dev environment** | Laptop → running stack, with the commands in the notes | Day 3, follow along |
| **Podium — your first deploy** | How a change ships: trunk, PR, preview, Argo CD, prod | Days 4–8 |
| **Podium — on-call basics** | Rotation, pages, triage, the escalation ladder | Day 9, before you shadow |
## The reading list
Four blueprints describe the estate you now work on. Day 2 is set aside for skimming them; deep-read the one your team owns.
| Blueprint | What you'll learn | Owner |
|---|---|---|
| [Multi-account AWS landing zone](/blueprintr/aws-landing-zone) | Four accounts, one transit gateway, why workloads have no internet gateways of their own | Cloud Foundation |
| [Kubernetes platform reference](/blueprintr/kubernetes-reference) | `track-prod` — the cluster your code actually runs on, and why only Argo CD deploys | Platform Engineering |
| [Network site topology](/blueprintr/network-site-topology) | The Rotterdam campus from edge router to your desk port | Network Engineering |
| [Lakehouse, ingest to dashboard](/blueprintr/lakehouse-platform) | Where Track's events go after production | Data Platform |
## The rules of the fortnight
- **Week 1 expects no output.** It is [deliberately all plumbing](stratum:shc_engineer_onboarding_week_1): access, orientation, a running stack, one small contained change. Calibration, not productivity.
- **Week 2 expects one small, real thing shipped** — to production, [with safety nets](stratum:shc_engineer_onboarding_week_2) at every step and your buddy alongside.
- **Stuck for 30 minutes = ask.** A step that takes you longer than that is a bug in the step. Your buddy first, then `#dev-experience`.
- **You maintain this.** Day 10's retro turns your fresh-eyes friction into PRs against this very blueprint — that contract is [the maintenance strategy](stratum:shc_engineer_onboarding_decision_one_link).
Reference strata, for the whole fortnight: the [accounts & access checklist](stratum:shc_engineer_onboarding_accounts_checklist) (every grant, who gives it, how fast), the [tooling directory](stratum:shc_engineer_onboarding_tooling_directory) (every URL in one table), and the [buddy programme](stratum:shc_engineer_onboarding_buddy_programme).
---
# Network site topology
URL: https://blueprintr.io/orgs/blueprintr/network-site-topology
> Rotterdam HQ from WAN hand-off to desk port: redundant perimeter, core, distribution and access layers, with a real port map and addressing record behind every device and live Continuum Link tabs besi…
# Rotterdam HQ — from the carrier hand-off to the desk
> [!TLDR] What this blueprint is
> The complete managed path through Meridian's Rotterdam campus: two external hand-offs, an HA firewall pair, a dual-chassis core, three distribution blocks and paired access switches serving office, operations and warehouse users. Open **any named device** for its authored port map, management address, owner and recovery path. The Continuum Lab appends live SolarWinds, PagerDuty, ServiceNow and NetBox tabs to those same strata.
**Site:** RTM-HQ · **Campus summary:** `10.20.0.0/16` · **Owner:** Network Engineering · **NOC:** `#netops` · **Availability target:** 99.95% for a working path from an occupied access port to WAN
## How to read the layers
| Layer | Responsibility | Failure boundary |
|---|---|---|
| [External hand-offs](stratum:shc_network_site_topology_wan_edge) | Internet transit and Meridian's corporate WAN | either carrier/path may fail without isolating the site |
| [Perimeter](stratum:shc_network_site_topology_perimeter) | BGP, security policy, NAT, VPN termination | either firewall or room may fail |
| [Campus core](stratum:shc_network_site_topology_campus_core) | active gateways, OSPF backbone, inter-VLAN routing | either chassis may fail; never both in one change |
| [Wing distribution](stratum:shc_network_site_topology_wing_2) | route summarisation, DHCP relay, access aggregation | one wing, not the whole campus |
| Access pairs | 802.1X, PoE, endpoint attachment | one floor/cabinet; use [access-port triage](stratum:shc_network_site_topology_access_triage) |
The paired paths are drawn once where a second parallel curve would add ink rather than meaning. Exact members and port ids live in each device's **Port map** tab; NetBox's live tab is the source-of-truth view of the same record.
## The LAN/WAN seam
This blueprint ends at the purple **Global WAN — RTM handoff** cloud. The MPLS core, international leased circuits, SD-WAN backups and seven branch sites on the far side are the sibling [Global WAN network diagram](/blueprintr/global-wan-diagram). Rotterdam is its hub; this campus is what hangs behind that hub.
## What is live, and what is authored
- The topology and authored strata explain intent: why the layers exist, what every port should connect to, and how humans operate the site.
- **SolarWinds Orion** supplies current reachability, interface state, errors and utilisation.
- **PagerDuty** supplies current/on-record incidents and service ownership.
- **ServiceNow** supplies changes, incidents and lifecycle work.
- **NetBox** supplies intended device, address, circuit and cable records.
Those provider tabs are seeded through the genuine Continuum Link pipeline, not copied into this file. Anonymous readers see the persisted panels as pure database reads.
---
# Azure hub-and-spoke, end to end
URL: https://blueprintr.io/orgs/blueprintr/azure-hub-spoke
> Meridian's corporate Azure estate: a firewalled hub and four peered spokes reached over ExpressRoute from Rotterdam. The Continuum tab carries a scanned hub-and-spoke environment whose Routing view sh…
# Meridian's Azure estate — the corporate half
> [!TLDR] What this blueprint is
> The hub-and-spoke network Meridian's corporate IT runs on: one firewalled hub VNet in westeurope, four peered spokes — identity, workload, data, shared services — and an ExpressRoute circuit back to the Rotterdam campus. Click any shape for its stratum. The **Continuum — Azure estate** tab is a scanned hub-and-spoke environment beside the drawing, and its Routing view shows which peering actually carries each flow.
**Owner:** [Network Engineering](stratum:shc_azure_hub_spoke_vnet_hub) · **Region:** westeurope (DR: northeurope, reserved) · **IP plan:** [10.64.0.0/11](stratum:shc_azure_hub_spoke_ip_plan) · **Sibling estate:** [AWS landing zone](/blueprintr/aws-landing-zone)
## The hub and four spokes
| VNet | CIDR | Purpose | Stratum |
|---|---|---|---|
| vnet-hub-weu | 10.64.0.0/16 | ER gateway, Azure Firewall, Bastion — transit only, no workloads | [Hub VNet](stratum:shc_azure_hub_spoke_vnet_hub) |
| vnet-identity-weu | 10.65.0.0/16 | AD DS domain controllers + Entra Connect | [Identity spoke](stratum:shc_azure_hub_spoke_vnet_identity) |
| vnet-workload-weu | 10.66.0.0/16 | Corp apps + file services behind an internal LB | [Workload spoke](stratum:shc_azure_hub_spoke_vnet_workload) |
| vnet-data-weu | 10.67.0.0/16 | Private endpoints for Azure SQL + Azure Files | [Data spoke](stratum:shc_azure_hub_spoke_vnet_data) |
| vnet-shared-weu | 10.68.0.0/16 | Log Analytics, Recovery Services, backup storage | [Shared services spoke](stratum:shc_azure_hub_spoke_vnet_shared) |
## Why it is shaped this way
- **Spokes peer with the hub and nothing else.** There is no spoke↔spoke peering anywhere in the estate. Anything crossing between spokes transits [Azure Firewall](stratum:shc_azure_hub_spoke_afw) — which is why the diagram's peering star and the red forced-tunnel edges tell two different stories, and why the [Routing & security tab](?tab=1) exists.
- **Internet egress is forced through the firewall.** Every spoke route table sends `0.0.0.0/0` to the firewall's private IP. No spoke resource holds a public IP; the estate's entire internet surface is [one SNAT address](stratum:shc_azure_hub_spoke_afw).
- **Hybrid traffic is trusted; internet and east–west traffic is not.** Campus flows ride [ExpressRoute](stratum:shc_azure_hub_spoke_er_circuit) through the [gateway](stratum:shc_azure_hub_spoke_ergw) without inspection — a deliberate, recorded trade-off ([decision A-03](stratum:shc_azure_hub_spoke_decision_log)), not an accident.
- **PaaS has no public front door.** Azure SQL and Azure Files resolve to [private endpoints](stratum:shc_azure_hub_spoke_pe_sql) in the data spoke; public network access is disabled on both — see [SQL](stratum:shc_azure_hub_spoke_sql) and [Files](stratum:shc_azure_hub_spoke_st_files).
- **Identity is its own blast radius.** [dc1/dc2](stratum:shc_azure_hub_spoke_dc1) and [Entra Connect](stratum:shc_azure_hub_spoke_aadconnect01) live in a spoke owned by Identity & Security, reached only over [Bastion](stratum:shc_azure_hub_spoke_bastion), and reviewed quarterly in [Zero-trust access review](/blueprintr/zero-trust-review).
## Reading order
1. This tab, top to bottom — the shape of the estate.
2. [Routing & security](?tab=1) — the UDRs, the NSGs, and which peering actually carries traffic.
3. [Operations](?tab=2) — patching, backup, circuit failover, alerting.
4. **Continuum — Azure estate** — the scanned environment; its Routing view is the proof beside the drawing.
The customer-facing half of Meridian's cloud is the sibling blueprint [Multi-account AWS landing zone](/blueprintr/aws-landing-zone). The campus the ExpressRoute circuit lands in is documented in [Network site topology](/blueprintr/network-site-topology), and who holds which role here is re-checked every quarter in [Zero-trust access review](/blueprintr/zero-trust-review).
---
# Multi-account AWS landing zone
URL: https://blueprintr.io/orgs/blueprintr/aws-landing-zone
> Meridian's three scanned AWS accounts — network, production and non-production — behind one transit gateway, with centralised inspection and egress and every subnet documented down to CIDR, tags and r…
# Meridian landing zone — how the estate hangs together
> [!TLDR] What this blueprint is
> The three AWS accounts in Meridian's scanned landing-zone data plane, the transit gateway that joins them to the Rotterdam datacentre, and the guardrails around all of it. Click any shape for its stratum — subnets carry their CIDR, tags and what is running in them; **Continuum — three-account scan** is the genuine read-only replay behind all three accounts, not a second hand-drawn view.
**Owner:** [Cloud Foundation](stratum:shc_aws_landing_zone_decision_log) · **Primary region:** eu-west-1 · **DR region:** eu-central-1 · **IP plan:** [10.32.0.0/11](stratum:shc_aws_landing_zone_ipam)
## The three accounts in the scan
| Account | Id | Purpose | Stratum |
|---|---|---|---|
| Network | 444455556666 | Transit gateway, Direct Connect, inspection + egress VPCs | [Network account](stratum:shc_aws_landing_zone_network_account) |
| Production | 777788889999 | Meridian Track (customer-facing SaaS) | [Production account](stratum:shc_aws_landing_zone_prod_account) |
| Non-production | 123456789012 | Staging + load-test environments | [Non-production account](stratum:shc_aws_landing_zone_nonprod_account) |
> [!INFO] Where the fourth account went
> Meridian still has a management account (`111122223333`) for Organizations, Identity Center, IPAM and organisation-wide security services. It is a **control plane, not a scanned workload/network account**, so it stays off this lead diagram and out of the three-account Continuum replay. Its ownership and controls remain documented in [Management account](stratum:shc_aws_landing_zone_mgmt_account) and on the **Account structure** tab.
## Why it is shaped this way
- **All traffic transits one gateway.** Spoke VPCs have no peering and no internet gateways of their own; the [transit gateway](stratum:shc_aws_landing_zone_tgw) is the only path between accounts, to on-premises, and out to the internet. One choke point means one place to inspect, meter and cut.
- **East–west and egress traffic is inspected.** TGW route tables force spoke→spoke and spoke→internet flows through the [inspection VPC](stratum:shc_aws_landing_zone_vpc_inspection); the [egress VPC](stratum:shc_aws_landing_zone_vpc_egress) owns the only NAT gateways and internet gateway in the estate. A workload account cannot opt out — see the [guardrails](stratum:shc_aws_landing_zone_scps).
- **The datacentre is a spoke, not a hub.** Rotterdam connects over [Direct Connect with VPN failover](stratum:shc_aws_landing_zone_dx). Nothing on-premises is load-bearing for the cloud estate; the WAN itself is documented in [Global WAN network diagram](/blueprintr/global-wan-diagram).
- **Accounts are the blast-radius unit.** Prod and non-prod share nothing but the network path. Account vending is a pipeline, not a wiki page — see the [runbook](stratum:shc_aws_landing_zone_account_vending).
## Reading order
1. This tab, top to bottom — the shape of the estate.
2. **Account structure** — the OU tree and what applies where.
3. **IP addressing** — the /11 plan and how subnets are carved.
4. **Continuum — three-account scan** — the genuine replay of the network, production and non-production accounts beside the drawing.
The Azure half of Meridian's estate (identity + corporate workloads) is the sibling blueprint [Azure hub-and-spoke, end to end](/blueprintr/azure-hub-spoke). The platform running inside `track-prod` is documented in [Kubernetes platform reference](/blueprintr/kubernetes-reference), and the analytics stack it feeds in [Lakehouse, ingest to dashboard](/blueprintr/lakehouse-platform).
---
# Getting Started Overview
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/getting-started-overview
_No text content._
---
# Cloud Architecture Example
URL: https://blueprintr.io/orgs/blueprintr/cloud-architecture-example
> Basic Enterprise Azure Environment
# **Basic Enterprise Azure Environment**
This blueprint describes a typical enterprise landing zone: an on-premises estate extended into Azure over a private circuit, with identity, workloads and shared services separated into their own spokes around a single inspection point.
Connectivity terminates in the hub. An ExpressRoute circuit with private peering carries corporate traffic to the ExpressRoute Gateway, and a route table steers everything that arrives - north-south from on-premises and east-west between spokes - through the Azure Firewall before it reaches a workload. Nothing routes spoke-to-spoke directly; the firewall is the only path.
The identity spoke carries the hybrid footprint. Two domain controllers replicate with one another and extend the on-premises forest into Azure, serving AD DS and DNS to the VNets so authentication and name resolution survive independently of the circuit. Alongside them, Entra Connect synchronises the directory to Entra ID, giving the same accounts a cloud identity for Microsoft 365 and SaaS.
The workload spoke holds general services. An internal load balancer fronts the line-of-business application server, and a file server publishes the SMB shares users consumed on-premises. Backup and unstructured data land in a storage account, and Azure Monitor with Log Analytics collects firewall, VM and platform telemetry into a single workspace.
---
# Azure vWAN with Azure Firewalls
URL: https://blueprintr.io/josh/azure-vwan-with-azure-firewalls
> Typical architecture for vWAN with AFW - this is a test
Combining Azure Virtual WAN (vWAN) and Azure Firewall creates a **Secured Virtual WAN Hub**.
This integration provides a centralized, highly scalable architecture that brings together networking, routing, and security.
**Key features of this combination:**
* **Unified Routing & Security:** Centralizes traffic routing and inspection for branch offices (SD-WAN, Site-to-Site VPN, ExpressRoute), remote users (Point-to-Site VPN), and Azure Virtual Networks (VNets).
* **Comprehensive Protection:** Azure Firewall secures both East-West (VNet-to-VNet) and North-South (Internet/On-premises-to-VNet) traffic flows with built-in threat intelligence and intrusion detection.
* **Simplified Management:** Reduces operational overhead by allowing you to manage security policies centrally via Azure Firewall Manager while the underlying infrastructure automatically scales with your traffic demands.
---
# This was oogly, now it's boogly
URL: https://blueprintr.io/liammcleod/this-was-oogly-now-it-s-boogly
Boogly
---
# Test Vellum
URL: https://blueprintr.io/liammcleod/test-vellum
> Test optional line
---
# Podium test (Liam)
URL: https://blueprintr.io/josh/podium-test-liam
_No text content._
---
# The Blueprintr dashboard
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/the-blueprintr-dashboard
_No text content._
---
# From organisation to Atrium
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/from-organisation-to-atrium
_No text content._
---
# Portfolios and folders
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/portfolios-and-folders
_No text content._
---
# Ways to import into Blueprintr
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/ways-to-import-into-blueprintr
_No text content._
---
# The settings hub
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/the-settings-hub
_No text content._
---
# The publish wizard
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/the-publish-wizard
_No text content._
---
# How a webhook delivery works
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/how-a-webhook-delivery-works
_No text content._
---
# How an embed resolves visibility
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/how-an-embed-resolves-visibility
_No text content._
---
# The SSO sign-in flow
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/the-sso-sign-in-flow
_No text content._
---
# Organisations, teams and roles
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/organisations-teams-and-roles
_No text content._
---
# Blueprintr's AI tools
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/blueprintr-s-ai-tools
_No text content._
---
# How a podium presents a diagram
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/how-a-podium-presents-a-diagram
_No text content._
---
# How a folium is built
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/how-a-folium-is-built
_No text content._
---
# Anatomy of a blueprint
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/anatomy-of-a-blueprint
_No text content._
---
# How strata work
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/how-strata-work
_No text content._
---
# Inside the Vellum editor
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/inside-the-vellum-editor
_No text content._
---
# How Blueprintr fits together
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/how-blueprintr-fits-together
_No text content._
---
# Getting Started with Blueprintr
URL: https://blueprintr.io/orgs/blueprintr-docs/getting-started/getting-started-with-blueprintr
> A placeholder article for the Blueprintr Docs knowledge base.
---
# Oogly 3
URL: https://blueprintr.io/jaja/oogly-draft-9zxrt4
Boogly
---
# Oogly 2
URL: https://blueprintr.io/jaja/oogly-draft-zgftac
Boogly
---
# Embed Test
URL: https://blueprintr.io/freetest1/embed-test
> This should embed nicely
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed porta eros id odio faucibus, quis convallis velit porttitor. Ut ultrices vel dolor ut eleifend. Vivamus turpis velit, ultricies vel facilisis at, egestas id nisi. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Quisque magna orci, efficitur eu auctor eget, blandit non enim. Curabitur condimentum sapien pellentesque lacus aliquam, nec commodo nulla rhoncus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Nullam sit amet consectetur quam, nec laoreet leo. Donec a euismod mi.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed porta eros id odio faucibus, quis convallis velit porttitor. Ut ultrices vel dolor ut eleifend. Vivamus turpis velit, ultricies vel facilisis at, egestas id nisi. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque habitant morbi tristique senectus et netus et malesuada [fames](stratum:c_d854933721b440379535a5f3a0e287bd) ac turpis egestas. Quisque magna orci, efficitur eu auctor eget, blandit non enim. Curabitur condimentum sapien pellentesque lacus aliquam, nec commodo nulla rhoncus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Nullam sit amet consectetur quam, nec laoreet leo. Donec a euismod mi.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed porta eros id odio faucibus, quis convallis velit porttitor. Ut ultrices vel dolor ut eleifend. Vivamus turpis velit, ultricies vel facilisis at, egestas id nisi. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Quisque magna orci, efficitur eu auctor eget, blandit non enim. Curabitur condimentum sapien pellentesque lacus aliquam, nec commodo nulla rhoncus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Nullam sit amet consectetur quam, nec laoreet leo. Donec a euismod mi.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed porta eros id odio faucibus, quis convallis velit porttitor. Ut ultrices vel dolor ut eleifend. Vivamus turpis velit, ultricies vel facilisis at, egestas id nisi. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Quisque magna orci, efficitur eu auctor eget, blandit non enim. Curabitur condimentum sapien pellentesque lacus aliquam, nec commodo nulla rhoncus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Nullam sit amet consectetur quam, nec laoreet leo. Donec a euismod mi.
---
# Testing
URL: https://blueprintr.io/premiumtest1/testing
_No text content._
---
# Zero-Trust Network Access
URL: https://blueprintr.io/liammcleod/zero-trust-network-access
> Simple model demonstrating AWS implementation of a concept known as ZTNA.
---
# Aspen Web Stack
URL: https://blueprintr.io/liammcleod/aspen-web-stack-
> Web stack used by the platform formerly known as Aspen by Network Diagnostics.