08 — FEDERAL CLOUD · 2026
Concord
A pre-release check for Azure Government: one offline file that compares QA, staging and prod, shows which one has drifted, and never uploads anything.
- Built
- An offline pre-release check that compares QA, staging and prod on Azure Government.
- Stack
- A Bash preflight (az, jq, curl, python3) and one self-contained HTML console; seven test gates.
- State
- Released August 2026, and still being developed.
IN PROGRESS · UPDATED 2 OCT 2026
Released August 2026 and still in development; read-only by design.
Carter Barnes · cloud engineer, federal Azure · Contact








What it is
Releases in a regulated environment fail for a boring reason: QA, staging and prod have drifted, and nobody knows which of the three is wrong. Concord answers that question before the release, not during the incident.
You capture a bundle per environment with a shell script, drop the bundles into one HTML file, say which environment you are deploying to, and read the verdict from that environment's point of view. Nothing is uploaded, written or sent. It runs offline and it is read-only by design, which is the only way a tool like this gets near a federal environment at all.








How it works
- Capture
- A preflight script in Azure Government Cloud Shell, using nothing more exotic than az, jq, curl and python3. Each run ends in GO, GO with warnings, NO-GO or inconclusive, and bundles what it saw.
- Reconcile
- One self-contained offline HTML console, about 2 MB, with zero network requests once it has loaded.
- Views
- App services, variable comparison, security review, and a renewals ledger where anything expired anywhere is an automatic no-go.
- Topology
- Network, OAuth and RBAC maps drawn from captured data, not from a diagram someone maintains by hand.
- Gates
- Seven test gates guard every change to Concord itself, including a scored fixture pack of 51 planted defects with an answer key. All green or the change does not ship.
By the numbers
- 1 file
- the whole console, about 2 MB, offline
- 0 requests
- to the network once it has loaded
- 7 gates
- all green before a change ships
- 51/51
- planted defects found in the scored fixture pack
Decisions
- 01
Values resolve to entities, not to strings
Two environments can hold different literal text for the same setting and both be right, because each points at its own copy of the same thing. An environment name embedded in a value is only believed when blanking it makes the row agree. With that rule, the report shows real drift instead of every difference in text.
- 02
Judge drift from the target environment's point of view
'Different' is not a verdict. Different from the environment I am deploying into is. Judging from the target environment's viewpoint was the change that made people trust it.
- 03
Bad input is a UX problem, not an error case
Someone will drop the wrong JSON. The console names what was dropped in one sentence and says what to drop instead, and it quietly recovers BOM-prefixed and UTF-16 files and bare CLI arrays, because that is what the tooling actually produces.
What I learned
- 01
Two functions that both meant 'make this comparable'
A canonicalizer that could not see environment names inside values was the wrong function to compare with. The resolver's own identity function was the one that knew.








What went wrong
- 01
A redesign silently reverted the resolver
I installed a visual redesign and it quietly took the entity resolver with it. Nothing failed loudly; the tool just became subtly wrong again. Every redesign drop is now block-diffed by its section markers before it goes in.
Disclosure
Built on my own time and equipment; it contains no employer code or data. Every image uses the console's own synthetic example data.
