Skip to content

Shadow-Platform Audit

Architecture audit — instantiates Layer-Appropriate Capability Placement

Inspects embedded systems for host-like facilities, duplicate authoritative state, and unbounded local extension growth, and registers each shadow platform it finds.

A Shadow-Platform Audit goes looking for the archetype's core failure after the fact: places where a narrow subsystem has quietly grown host-like facilities of its own — its own identity store, its own scheduler, its own policy engine, its own copy of authoritative state — becoming an inferior nested platform with a second source of truth. It inspects embedded systems for these tell-tale reconstructions, measures how far local extension has sprawled against the budget it is supposed to stay within, and records each finding in a register so the shadow platforms become visible, comparable, and assignable. Its defining move is detection, not repair: it names and sizes the duplication that has accreted, turning a diffuse "our tooling has gotten weird" into a specific inventory of what was rebuilt, where, and how big it has grown.

Example

A company runs its customer operations on a SaaS platform meant to be configured, not programmed. A Shadow-Platform Audit of one business unit's instance finds what a decade of "just one more customization" produced: a home-grown user table with its own roles and passwords running parallel to the corporate identity provider (two sources of truth for who is an admin), a nightly script-based job scheduler duplicating the platform's native automation, and an approval-routing engine hand-built in custom code because the native one "wasn't flexible enough." Each is logged in the register with its size, its authoritative-state overlap, and its blast radius.

The most alarming entry isn't the biggest but the riskiest: because of the parallel user table, an employee removed in the corporate directory still holds admin rights inside the platform. The audit fixes none of this — but it converts a vague unease about a "crufty" instance into a ranked list of shadow platforms, each with an owner and a measured cost, which is what any retirement or promotion decision needs even to begin. It is the inner-platform effect made visible.[1]

How it works

  • Inspect for host-like facilities. Look inside the subsystem for capabilities that duplicate the host's — identity, storage, scheduling, packaging, policy, observability — that the layer was never meant to own.
  • Find the second source of truth. Flag where the subsystem holds authoritative state the host also holds, since two masters is where the real damage lives.
  • Measure local extension against budget. Size how far custom local extension has grown and compare it to the local-extension budget the layer is meant to respect, surfacing unbounded sprawl.
  • Register each finding. Record every shadow facility — what it duplicates, its size, its risk, its owner — in a standing register so the findings persist and can be acted on.

Tuning parameters

  • Scope — one subsystem versus a fleet-wide sweep. Broad finds systemic patterns; narrow goes deep on one instance.
  • Detection sensitivity — how host-like something must be to count. Too sensitive flags every small local helper; too loose misses a shadow platform assembled from many innocuous pieces.
  • State-overlap focus — how hard the audit hunts for duplicate authoritative state specifically, which is costlier to detect than surface features but far more dangerous.
  • Cadence — a one-off review versus a recurring audit. Shadow platforms accrete continuously, so a single audit dates quickly.
  • Register durability — whether findings persist and are tracked to resolution, or evaporate after the readout. A register that isn't carried forward turns the audit into a one-time scare.

When it helps, and when it misleads

Its strength is that it makes an invisible, gradual failure legible: duplication accretes one reasonable customization at a time, and only a deliberate inspection reveals that a configurable subsystem has become a second platform maintaining its own truth. Naming it — the inner-platform effect — is what lets an organization decide to retire, consolidate, or promote.

Its limits: an audit is a snapshot, so it dates as fast as the customizations keep coming, and it is only as good as its detection criteria — a shadow platform built from many individually-defensible pieces can slip a check tuned to spot big obvious clones. The misuse to avoid is the audit that produces a register and no decisions — findings logged, nothing retired or promoted, the report filed as evidence of diligence while the duplication keeps growing. The discipline is to attach each finding to a disposition (retire, consolidate, promote, or consciously accept) and to re-run the audit on a cadence, because detection without a standing register and a follow-through is theatre.

How it implements the components

The audit fills the detection-and-tracking side of the archetype — the components that make accreted duplication visible and measurable:

  • shadow_platform_register — the audit's primary output: a durable, ranked inventory of the host-like facilities and duplicate state it finds.
  • local_extension_budget — it measures how far local extension has grown against the budget the layer is meant to keep, making "unbounded growth" a number rather than a feeling.

It detects and sizes the duplication but does not itself retire it — the path to unwind a duplicate facility belongs to Temporary Local Shim with Expiry and other retirement paths, and the decision to promote a justified capability into the host belongs to the sibling Capability-Promotion Review.

Notes

A shadow facility is not automatically wrong. The audit's job is to surface and size it, not to judge it — some duplications should be retired because the host already offers the capability, while others are evidence of a real gap that should be promoted into the host rather than deleted. Which response fits is the Capability-Promotion Review's call; the audit only guarantees the duplication is no longer invisible.

References

[1] The inner-platform effect — the anti-pattern in which a system is customized to the point that it reimplements, poorly, the very platform it runs on: a configurable system built inside a configurable system. It is the recognized name for the shadow platform this audit hunts for. ↩