Client Preview and Export Blocked Automation: The Document Was Never Missing, Only Its Presentation

A screen that says a feature is "blocked" and shows a fabricated example in its place reads, to the person looking at it, as unambiguous: the real thing does not exist yet. That reading can be entirely wrong in a specific and easy-to-miss way — when the actual underlying content has existed the whole time, generated correctly, sitting in force one screen away, and the only thing genuinely absent is a presentation-layer step nobody had built: stripping away the internal chrome that makes a screen recognizably part of an internal tool, so what remains is exactly what an outside client should be shown.

A delivery-format screen — one meant to be shown to someone outside the building — is a genuinely different kind of screen from every other tab in a product built around one consistent internal shell: it needs to deliberately look like nothing else in the tool. Building that presentation layer (stripping chrome, adding a client-appropriate header, wiring a working print or export path) is real, separate work from the analysis-generation logic that produces the content in the first place — work that can reasonably lag behind a feature's core generation capability without the underlying capability itself being incomplete in any way. The risk is that a placeholder built to hold that screen's spot in the interface, labeled honestly as "blocked" at the time, can outlive the reason it was built once the real content it was always meant to eventually format has been sitting there, generated and correct, for a while.

Three screens — "Client Preview" and "Export" for one feature area, and "Follow-Up Preview" for a second, unrelated one — each promised the specific document an agency's own client is meant to see. All three displayed an explicit "(blocked)" label alongside a fabricated example document, with no functional connection to any real client's actual data.

The content each of these screens was meant to present was never actually missing. Every one of the two feature areas already generates a real, in-force analysis, correctly, and already displays that exact analysis in full on its own Overview screen. What none of the three screens had was the DELIVERY presentation of that same content: no internal navigation menu, no internal tab bar, no internal status badge, no internal-only labeling of any kind — replaced instead with the client's own name at the top of the document and a working way to turn it into something portable.

The fix builds one shared component used identically by all three screens. It reads the exact same real, in-force analysis the Overview screen already correctly displays, and renders it inside a clean, self-contained document view: the client's name at the top instead of any internal label, the full real content below, and a print button that invokes the browser's own native print-to-PDF capability directly — deliberately avoiding the cost and maintenance burden of building and hosting a separate PDF-generation service for output the browser can already produce natively.

Because the entire purpose of this specific screen is to prove what an external client would see, wrapping it in the product's own normal internal navigation shell — the very thing every other screen in Centriu Helix correctly renders inside of — would directly defeat that purpose. These three screens are therefore made the one explicit, deliberate exception to the module's own "every tab renders inside the shared internal shell" rule, rather than an accidental gap in an otherwise-uniform pattern. A pre-existing automated test that verifies every navigable screen renders inside that shared shell was updated specifically to require these three screens to render the new delivery-format component INSTEAD — so the exception is written down, actively checked on every future change, and cannot silently regress back to either an internal-looking screen or a fabricated placeholder without failing a test.

Before the fix, opening any of the three affected screens showed a "(blocked)" label and an invented example document with no relationship to any real client's actual analysis. After the fix, the identical entry point renders the client's own real, current, in-force analysis — the client's name at the top, no internal chrome anywhere, and a print button that turns it into a PDF using the browser's own built-in capability.

Three screens across two of Centriu Helix's AI feature areas — meant to show a client the exact document they are supposed to receive — now render that client's real, in-force analysis in a clean, presentation-appropriate format instead of a fabricated example behind a "(blocked)" label, with the exception to the module's usual internal-shell rule explicitly documented and test-enforced rather than left as an unexplained gap.

This automation governs only the DELIVERY presentation of an already-generated, already-correct analysis to an external client — it does not change how that analysis itself is generated, what it recommends, or its accuracy, which are the module's separate, unaffected generation logic. It is also distinct from this pillar's companion Helix page on the same-day history-archive fix — that page concerns the internal HISTORY of every past version of an analysis; this page concerns the external, client-facing PRESENTATION of the single current one.

Applying a single, consistent navigation shell to every screen in a product is a genuinely good default — it is what makes an internal tool feel coherent and reduces the number of ways any given screen can be built inconsistently. The risk of applying that default without exception is specifically that a small number of screens exist for a fundamentally different purpose (being shown to someone outside the product entirely), where the very consistency that helps everywhere else is the thing actively working against the screen's own job. Making that exception explicit, narrow, and covered by its own dedicated test — rather than leaving it as an unexplained, unenforced gap in an otherwise-uniform pattern — is what keeps the exception from silently drifting in either direction over time.