Preview Badge Import-Graph Invariant Automation: A Rule That Follows the Code Instead of a Map of It

Deciding whether a screen shows real or simulated data by consulting a maintained list — one entry per screen, updated by hand whenever a screen's status changes — is a completely reasonable starting design: it's simple, explicit, and easy to read. Its entire reliability, though, depends on every single change to the underlying screens being accompanied by a corresponding, remembered update to the list, forever, with no structural connection forcing the two to move together. A check that instead follows the screen's own actual code — its real imports, exactly as the running program would follow them — has no separate list that can fall out of sync, because it isn't consulting one; it is asking the code itself, directly, every single time.

A direct measurement of Centriu Helix's ten feature areas, taken specifically to establish ground truth ahead of this fix, counted 206 total routes across those areas: 68 genuinely read a client's own real, AI-generated report, and the remainder still rendered invented, placeholder content. The distinction between the two groups — which screens show up in the product's navigation at all, and which of those carry a visible "preview" warning — had been controlled entirely by two separate, hand-maintained lists, each requiring someone to remember to update it at the exact moment a given screen's real-versus-simulated status changed. Anyone evaluating the product could move from a screen genuinely backed by real data directly into one still drawing invented content, with nothing in the interface signaling that a boundary had been crossed, because the maintained lists meant to signal exactly that had already drifted from what the underlying screens actually did.

The fix replaces both lists with a single automated verification that consults neither. Starting from each of the ten feature areas' own page entry files, it resolves every import statement to the actual file it points to — following relative paths and the module's own path-alias convention exactly as the real build would — and continues recursively as far as the chain of imports actually leads, determining directly whether that chain ever reaches the module's shared mock-data layer. No separate map is read at any point in this process; the answer comes entirely from following the code as it genuinely is at the moment the check runs.

The check enforces a deliberate two-way rule, not a one-way filter: a screen whose real import chain reaches the mock-data layer MUST be marked with the preview label, and a screen whose import chain does NOT reach that layer must NOT carry the label. Both directions are treated as equally real defects on purpose — a screen with mock data and no warning misleads a buyer about what they're evaluating, but a screen that is already genuinely real and still marked as a preview is, in the fix's own stated reasoning, the more expensive mistake, because it actively undersells work that has already been completed. Exactly two screens remain legitimately marked as previews after the fix, named explicitly in the check itself, both confirmed by the same import-following process to still genuinely reach the mock-data layer.

The check is deliberately scoped to only the ten client-facing feature areas this invariant governs — screens belonging to the module's own audit, closure, and platform-mapping areas are excluded on purpose, since those screens exist specifically to REPORT on what data is real or mock elsewhere in the system, and applying the same reachability rule to them would forbid them from doing the very job they exist to do.

Before the fix, whether a specific screen carried a preview warning depended on whether someone had remembered to add or remove it from a maintained list the last time that screen's underlying data source changed. After the fix, the same question is answered by tracing the screen's own real imports to see whether they genuinely reach the mock-data layer — a screen rebuilt to use real data, with no import path left leading to mock data anywhere in its chain, is automatically expected to have no preview label, and the automated check fails if one is still there.

Whether a Centriu Helix screen carries a preview warning is now determined by directly tracing its own real code imports to the module's shared mock-data layer, rather than by consulting a separately maintained list that could silently drift from what the screen's code actually does — closing a gap where 206 measured routes, 68 of them genuinely real, had relied entirely on manually-updated lists to signal the boundary between the two to anyone evaluating the product.

This automation governs only Centriu Helix's own internal preview-labeling verification for its ten client-facing feature areas — it does not apply to the module's own audit, closure, or platform-mapping screens, which exist specifically to report on real-versus-mock status elsewhere and are deliberately excluded from this specific check.

A hand-maintained list mapping each screen to its real-or-simulated status is simple to read and simple to reason about in isolation — but its correctness depends entirely on every future change to the underlying screens being accompanied by a remembered, corresponding update to the list, forever. An automated check that instead follows the screen's actual import chain has no separate state that can fall out of sync with the code, because it consults nothing but the code itself, every time it runs — the cost is a more involved initial implementation (resolving real import paths, following them recursively, deciding what counts as "reaching" the mock layer), paid once, in exchange for a guarantee that does not depend on anyone remembering anything, going forward.