Back to Web Applications

Internal toolConfiguration

Atlas: the map of what depends on what.

An enterprise order platform is configured in thousands of places, and many of them have to agree with each other exactly. Nothing wrote that down. Atlas is the captured dependency graph of that configuration: every component, every entity, every edge between them, so a change shows what it touches before anyone makes it.

Where it lives: Control TowerWho reads it: Omniscope
Scale
69 components, 2,300+ entities
Captured
Nightly, from the config repository
Direction
One way, never written back
Role
Requirements, model, capture, validation

The captured graph

Dependency chain

The platform's configuration as a graph, captured rather than drawn: every component sized by the entities it holds, and the edges between them. The lit path is a dependency chain, a setting that must hold identically in three components or orders fail in silence.

Hover a component to see everything it touches. On a touchscreen, tap it.

Node size: entities in the component

Illustrative layout. The scale is the captured graph; the labels shown are generic.

  • Order: 151 entities, 9 connections
  • Inventory: 85 entities, 7 connections
  • Fulfilment: 57 entities, 6 connections
  • Payment: 60 entities, 5 connections
  • Item: 44 entities, 5 connections
  • Customer: 46 entities, 5 connections
  • Promising: 52 entities, 4 connections
  • Carrier: 31 entities, 4 connections
  • Search: 47 entities, 4 connections
  • Tax: 22 entities, 4 connections
  • Geo: 12 entities, 2 connections
  • Returns: 18 entities, 3 connections
  • Email: 11 entities, 2 connections
  • Pricing: 24 entities, 3 connections
  • Parcel: 20 entities, 3 connections
  • Cart: 35 entities, 2 connections
  • Barcode: 13 entities, 1 connections
  • Facility: 26 entities, 2 connections
  • Organisation: 28 entities, 3 connections
  • Supply: 21 entities, 2 connections
  • Shipment: 19 entities, 3 connections
  • Store: 22 entities, 3 connections
  • Device: 15 entities, 1 connections
  • Receipt: 25 entities, 3 connections
  • Trade: 17 entities, 3 connections
  • Monitor: 10 entities, 2 connections
  • Scheduler: 16 entities, 2 connections
  • Notification: 14 entities, 1 connections
  • Messaging: 11 entities, 1 connections
  • Employee: 18 entities, 3 connections
01

Why it exists

A configuration change used to be made and then watched. Nobody could say beforehand what else it touched, because the wiring lived in the memory of whoever had set it up, and in a vendor register nobody read. When three components had to hold the same value and one drifted, nothing failed loudly. Orders simply stopped, somewhere downstream, for a reason no screen showed.

The question

What it took

  • What else does this setting touch?

    Ask around, then change it and see

  • Which configuration governs this entity?

    Open every component's screens in turn

  • Do these three components still agree?

    Three exports and a spreadsheet

  • What changed here, and when?

    The repository history, if you knew where to look

Every answer was in the configuration. None of them was in one place, and none could be asked before the change instead of after.

02

A map you can ask questions of.

Six things Atlas does, each one a question that used to cost an afternoon.

  • Lookup

    Search any entity, see what it depends on and what depends on it, and click through to each neighbour.

  • Graph

    The whole platform as a force-directed map: drag, pan, zoom, and a shortest path between any two components.

  • Dependency chains

    The sets of settings across components that must agree exactly, named and checked as one thing rather than three.

  • Nightly capture

    Rebuilt every night from the configuration repository at a known commit. One direction only: Atlas reads the repository and never writes to it.

  • Companion to the Config Checker

    Atlas says how a configuration is wired. The Checker says whether it is live. Diagnosing takes both, so they sit side by side.

  • Read by agents

    Omniscope answers what depends on this from the same graph, so an AI agent reads the map instead of guessing.

03

How a chain breaks.

Three components each hold their own copy of one setting. While the copies agree, an order flows through all three. When one drifts, the order stops there, and nothing says why.

One dependency chain

Live

  1. 01

    Order

    Reason code, as accepted

    RETURN_DAMAGED

  2. 02

    Fulfilment

    Reason code, as routed

    RETURN_DAMAGED

  3. 03

    Inventory

    Reason code, as booked

    RETURN_DAMAGED

All three copies agree. The order flows through the chain.

Values are illustrative. The mechanism is real: a chain fails silently at the first component that disagrees, which is why the map names chains instead of leaving them to memory.
  1. 01

    Capture

    Every night the configuration repository is read at a known commit and turned into components, entities and the references between them.

    Forecloses: No stale map

  2. 02

    Model

    An entity model decides what counts as a dependency: a reference by key, a shared code list, a setting that another component reads.

    Forecloses: No edge without a reason

  3. 03

    Validate

    The captured graph is checked against the vendor's own dependency register, so the map agrees with the platform rather than with a hunch.

    Forecloses: No invented dependency

  4. 04

    Serve

    The same graph feeds the Lookup, the Graph and Omniscope's tools, so a person and an agent read one map.

    Forecloses: No two versions of the truth

A change is now made with its blast radius in view, and a chain is a thing with a name rather than three settings someone hopes still match.

04

My role

I built Atlas because I was the one being asked what a change would touch, and I could not answer without an afternoon.

  • 01Wrote the requirements from the questions that kept arriving: what does this touch, what governs this, do these still agree.
  • 02Designed the entity model: what a component is, what an entity is, and what counts as a dependency between them.
  • 03Built the nightly capture from the configuration repository, one way, at a known commit.
  • 04Validated the captured graph against the vendor's own dependency register and fixed the model where they disagreed.
  • 05Shipped it inside the Control Tower and exposed it to Omniscope, so the same map serves a person and an agent.

Given it again, I would name the dependency chains first and capture the graph second. The chains are the reason the map is trusted, and they were found by reading it rather than designed into it.

05

What changed

2,300+

Configuration entities, mapped and connected

The wiring of the platform's configuration is a map anyone can read, rebuilt every night, and the settings that must agree are named and checked as one.

Before
After
Change it, then watch
See what it touches, then change it
Whoever remembered the wiring
A map anyone can read
Three settings checked by hand
One named chain, checked as one
An agent guessing at dependencies
An agent reading the graph

69

Components in the graph

Nightly

Capture, at a known commit

0

Writes back to the repository

06

Built with

  • TypeScript
  • Next.js
  • JSON
  • Git
  • Vercel