Case Study 01 — The First City: Imperium

A City Survey engagement · 14–17 August 2026 Radical Edge Solutions · The City Survey

Subject: Imperium — Radical Edge Solutions' own platform, named by founder ruling (Gate 1A, 2026-08-17): a production Medicare-industry SaaS platform, roughly 18 months old, built almost entirely by AI under the direction of a domain expert who does not write code. Three live districts, ~1,600 automated tests, a documented build protocol, and real users. The program is the exclusive property of RES; the subject platform is subject matter, not stakeholder.

This was not a rescue. The city was in better condition than most. That is what makes it a useful first engagement — the survey had to find things a healthy city hides, not step over rubble.

Why this city was chosen first

The owner is the author of the instrument. That is a conflict, and it is disclosed rather than managed away — an inspector auditing his own client is exactly the arrangement the survey exists to distrust.

It was accepted for one reason: calibration requires a city whose defects are already partly known. An instrument is not proven by finding problems in a stranger's app. It is proven by finding specific, pre-identified defects without being told where they are — and by what it misses.

What the survey does

Fourteen districts. Three levels, always in this order:

The engagement ran in two deliberate phases, and closed at 14 of 14 districts, all three levels. Seven districts went first — Works Department, Bedrock, Ports, Walls & Gates, Lamps, Firehouse, Watchtower — with the rest deferred on purpose: a fourteen-district fix list all at once compels an owner into mass remediation, and mass remediation is itself destabilizing. The remaining seven were then surveyed to close the engagement complete.

The headline finding

The owner could not independently verify any claim made by anyone building his software.

Asked at interview whether he could check a worker's claim himself, without asking another worker, he answered: "No." Asked what he therefore accepts on faith: "Everything."

The remarkable part is what came next. The survey then found the same shape six separate times — and in every instance the city already held the answer:

• A five-tier documentation library, fully stocked. The owner did not know it existed.
• A load test naming precisely what would break at peak volume. It never reached him.
• An incident log recording a slowdown he had personally reported and did not recall.
• Automated gates verifying the codebase continuously, reporting to nobody.

This was never a missing control. It was a missing window. Every fact existed. None had a path to the person accountable for the business.

The finding that justified the engagement on its own

Production point-in-time recovery was set to six hours against a documented seven-day requirement — a 28× gap, in place since the project was created, never once checked in 78 days.

Not a hard problem. Not a subtle one. A single live read that nothing and nobody performed. The runbook asserted the requirement; no code, no test, and no human ever compared it to reality.

Fixed within the hour it was found. Raised to 30 days, the platform maximum.

Then the drill was actually run — the first time in the platform's life — and it produced a second finding the setting alone would never have revealed: raising retention does not create history retroactively. The real recoverable window on the day of the fix was roughly 8–12 hours, not 30 days. The number in the console was a ceiling, not a depth.

What remediation looked like

The owner authorized a remediation block. Over roughly two days:

Twelve changes shipped. Every one behind the platform's existing gates — tests, build, CI, and the owner's own merge approval.

The second engagement, inside the first

A survey finding was then fixed wrongly, twice, in ways that mattered.

The observability dashboard shipped reading one district's data while presenting itself as the fleet-wide view. A partial picture wearing the costume of a complete one — which is precisely the disease the page had been built to cure. Left alone, it would have converted "I don't know" into a false all-clear, and made the original finding worse.

It was not caught by the test suite, the type checker, the build, or the author's written claim of verification. It was caught by an independent automated reviewer — which went on to find six defects across the engagement, none of which the author's own process surfaced.

That is the most commercially useful thing this engagement produced, and it is not about this city. It is evidence for the survey's own core claim: an owner whose only reviewer is the entity doing the building has no reviewer at all.

Results

Cross-level contradictions are the highest-value output, and they cannot be produced without the interview. Sixteen surfaced here. The plan required one.

What the instrument got wrong

Published because an instrument that hides its own misses is not an inspection instrument.

The self-test failed, 1 of 2. Two defects were known before the engagement began. The survey independently found the first — a documentation drift. It walked straight past the second: an unattributed software license obligation on material the owner intends to sell.

That miss located a real hole in the instrument. No district asked "what in this city did you not write, and what does its license require of you?" For a survey sold to people who build with AI — who absorb licensed code and tooling constantly, often without noticing — that is a gap in exactly the place their risk lives. The question is being added to District 1.

The surveyor's own error rate was worse than the city's. Eleven predicted findings were investigated and all eleven died under verification — every one favoring the city. Including one that would have built the owner's new dashboard on a retired page he could not reach.

The conclusion drawn was not "be more careful." It became instrument law: a finding produced by pattern-matching a codebase is a hypothesis, and it does not enter a report until it is read from source.

What this engagement proves

1. A healthy AI-built city still fails the mayor. Nothing here was negligent. The controls were unusually strong. The gap was between the machinery and the person accountable for it — and no amount of additional automation closes that.
2. The dangerous defects were invisible, not broken. A recovery window nobody read. A library nobody knew about. Gates reporting to no one. None would have surfaced as a bug report.
3. The interview earns its place. L3 produced fewer findings than the code review — and produced the worst ones, plus every contradiction.
4. Outside review is not optional. Six real defects were found by a reviewer that was neither the builder nor the owner. The builder found none of the six.

Scope and honesty notes

• All fourteen districts were surveyed, at all three levels. The engagement ran in two phases — seven districts, then the rest — and this note said "seven of fourteen" for two days after the second phase closed, which is itself a specimen of the disease this record documents.
• The dashboard's panels were shipped verified by tests, build, and a live security-gate probe — but were not driven in a browser by the surveyor, because doing so would have required manufacturing a credential the city's own policy forbids. Recorded as unverified rather than claimed.
• Findings are described by class, never by exploitable specifics, and the open ones are observability and recovery gaps rather than anything a stranger could reach. Where a finding is not yet closed, this record says so rather than implying otherwise.
• The surveyor built the remedies as well as finding them. That is a conflict, and the appropriate correction is already scheduled: a surveyor who builds the fix has left the inspector's chair.

Prepared by Radical Edge Solutions. Findings are described by class rather than by exploitable specifics. Engagement records are confidential; this summary is published with the subject's consent.