Analysis Tabs Per-Topic AI Generation Automation: One Question Per Call, Not Twenty in One

Not every screen showing placeholder content needs the same kind of fix. Some need a working FEATURE built — a real settings toggle, a real export pipeline, a real kill switch — where no amount of AI-generated text would be the correct answer. Others need a real ANALYSIS generated — genuine insight about a specific client, produced by a model given the right context and a narrow enough question to actually answer well. Conflating the two categories, and defaulting every screen toward whichever fix is more familiar, risks either building unnecessary features where text was the right answer, or generating shallow AI text where a real feature was actually missing. Separating 128 screens into 99 genuinely analysis-shaped and 29 genuinely feature-shaped, before writing a single fix, is what let each group get the fix it actually needed.

Asking one AI call to cover many related subjects at once is a reasonable, often correct instinct when the subjects are genuinely few and closely related — it minimizes the number of round trips and keeps a topic's context consistent with its neighbors. The instinct breaks down specifically at the scale this fix operates at: a single feature area can have twelve to twenty-seven distinct analysis tabs, and asking one model call to meaningfully cover that many subjects at once runs directly into the model's own limited attention across a long, multi-subject instruction — each additional subject competes with every other one for the same fixed budget of depth, and the measured result is real: each topic degrades toward one shallow bullet rather than a developed answer, while the total time to produce all of it grows regardless.

Across Centriu Helix's AI feature areas, 128 screens were still displaying mock content. A deliberate first step separated them into two categories before any fix was written: 99 are genuine single-topic analysis — margin exposure, delivery capacity, how a specifically skeptical client would object, a synthetic-consumer reaction, the cost of taking no action, and dozens more, spanning nine separate feature areas — each a topic an AI model, given the right context, can actually produce a real, useful answer to. The remaining 29 are functional screens needing an actual feature built (settings, list views, export, a kill switch, search), correctly left marked as preview rather than papered over with generated text that wouldn't have been the right fix.

For the 99 real analysis topics, the core architectural decision was to make each one a fully separate, on-demand AI generation call — one focused subject, the client's entire available context, and an explicit instruction telling the model to state plainly what the data available does NOT support concluding, rather than filling gaps with confident-sounding guesses. The rejected alternative, tried and abandoned during this same work, was requesting all of a feature area's topics inside one shared prompt: the team found this measurably dilutes the model's output, degrading each subject toward a single shallow bullet point, while taking LONGER overall than the mock content it would have replaced — the exact failure mode of a screen that looks more finished (a "real data" badge, generated text) while delivering objectively less than what it's replacing.

Each deep-dive generation is recorded using the same underlying archive mechanism this pillar's companion Helix page on the report-history fix already covers — filed under a compound key combining the feature and the specific topic, which slots directly into the existing archive-by-organization-type-organism pattern with no database schema change required. Cost stays fully explicit throughout: a deep-dive generation call happens only at the exact moment someone clicks to request that specific topic, and any topic not yet generated for a given client shows a plain, honest invitation to generate it — never invented content standing in for something that hasn't actually been produced yet.

Two new automated gates were added, both deliberately verified through mutation testing — introducing a fake defect into the exact code path each gate checks, to confirm the gate genuinely fails when it should rather than passing by accident. The first compares the interface's own map of which topics exist against the AI engine's own registry of which topics it knows how to generate, in BOTH directions: a topic offered by the interface but absent from the engine's registry would be a button that always fails to generate; a topic present in the engine but never offered by the interface would be a fully-written analysis capability nobody could ever reach. The second confirms no single topic is simultaneously treated as a section carved from the feature's shared base report AND as its own separate deep-dive generation — a topic caught in both categories would read from one storage key while a click to generate it wrote to a different one, so generating would silently change nothing visible on screen, exactly the kind of failure that looks like success and produces nothing.

A closely related, same-day finding closes out this story: the very first real deep-dive generation, run end to end against actual production data, worked correctly — a specific topic returned a genuinely client-specific analysis in 25 seconds, with an honest note about what the underlying data did not support concluding. That same live verification caught two smaller display defects: the description shown under one tab was the description of the ENTIRE feature area rather than that specific tab's own (each tab's correct, narrower description had existed in the navigation structure the whole time, simply never read by the display code), and a screen's empty state told the person to go back to a different, unrelated screen to generate content, rather than correctly naming the actual tab they were already on. Both were fixed the same day, caught by direct verification against a real, generated result rather than by inspecting code alone.

Before this architecture, requesting insight on a specific topic like "margin exposure" would, in the rejected shared-prompt approach, compete for the model's attention against roughly twenty other unrelated subjects in the same request — producing one thin, generic bullet point rather than a developed answer, and taking longer overall despite covering less depth per topic. In the shipped architecture, clicking that same specific tab sends one AI call carrying only that topic and the client's full context, returning a focused, genuinely useful analysis — with an honest statement of what the available data does not support concluding, rather than a confident-sounding guess filling the gap.

99 of 128 previously mock-content screens across nine of Centriu Helix's AI feature areas now generate genuine, single-topic, client-specific AI analysis on demand — architected as one focused call per topic rather than one diluted call covering many, cost-transparent (a generation call happens only on an explicit click), and protected by two mutation-tested gates that keep the interface's own topic map and the AI engine's own topic registry in exact agreement.

This automation covers the 99 screens whose correct fix was genuine, on-demand AI analysis — it explicitly does not cover the remaining 29 screens in the same original batch that needed a real, working FEATURE built instead (settings, list views, export, a kill switch, search), which correctly remain marked as preview rather than receiving generated text as a substitute for actual functionality. It is also distinct from this pillar's separate companion page on the report-history archive fix, which covers how PAST versions of a report are listed and reopened, not how any individual analysis topic is generated in the first place.

Requesting many subjects inside a single AI call is the simpler architecture to build and reason about, and it is a reasonable choice when the number of subjects is genuinely small. At the scale of a feature area with over twenty distinct analysis topics, the measured cost of that simplicity is real: each individual subject's depth degrades as the model's attention is divided across everything else in the same request, and the total time to produce all of it grows regardless of the shallower result. Committing to one focused AI call per topic costs more total calls, but each one arrives with the model's full attention on a single, well-defined question — the difference between a genuinely useful answer and a bullet point that merely occupies the space where one used to be a mock example.