23 The Catalog Is the Front Door

The most underappreciated product decision in the open-source clinical world was not a package. It was a catalog: a public, browsable collection of every standard table, listing, and graph, each shown as a rendered example with the code that produced it, runnable on synthetic data. The team behind it invested in the catalog as seriously as in the packages themselves — and the ecosystem’s adoption curve bent upward accordingly.

The lesson generalizes. For a trust product, the catalog is not documentation garnish. It is the front door, the sales engine, and the quality instrument, all at once.

23.1 Three jobs the catalog does

It is the demo that never sleeps. A prospect in another timezone can, at 2 a.m. their time, browse the exact outputs your system produces — not screenshots, not promises, but rendered artifacts with their manifests visible: which spec, which data, which comparison verdict. For a product whose pitch is “every number carries evidence,” there is no more persuasive artifact than a library of numbers carrying evidence. A demo requires a salesperson; a catalog requires only a URL.

It is the boundary of honesty. The catalog draws a physical line between what exists and what does not. A capability absent from the catalog is officially not claimed; a capability present was rendered by the real system on data the visitor can inspect. Marketing cannot outrun such a catalog, which — per Principle Six — is the point. Teams discover that the catalog quietly becomes the internal source of truth too: engineers check it before claiming a feature works, because everyone else will.

It is the regression instrument. The same machinery that renders the catalog on synthetic data can re-render it on every release and compare against the locked reference. The catalog becomes a living OQ: any change in engine behavior appears as a visual + cell-level diff across the whole product surface, before customers ever see it. Few teams use their public gallery as a quality gate; those that do ship with unusual calm.

23.2 What a good catalog entry carries

Consistency matters more than volume. Every entry should show the same anatomy, because the catalog teaches the product’s mental model, not just its inventory:

The rendered output itself — table, listing, or figure, exactly as delivered.
The specification it was built from, in readable form.
The synthetic dataset it ran on, with its provenance visible.
The comparison verdict — what was independently verified, and how.
The one-command reproduction — the exact invocation that regenerates the entry locally.

The last item converts readers into users: the distance from “looking at an example” to “running the example on my machine” should be one copy-paste. Ecosystems grow at the speed of that distance.

23.3 The synthetic-data foundation

None of this works with real study data — governance forbids it, and rightly so. The catalog stands on synthetic data that is honest about being synthetic: structurally faithful to the standards (domains, variables, controlled terminology), rich enough to exercise every code path, clearly labeled in every artifact. Building and maintaining that dataset is not overhead. It is the fuel of the front door, the demo, the public CI, and the training ground — one investment, four returns.

The test. Send a stranger your product’s URL and leave the room. What can they verify without you? If the answer is “marketing claims,” the front door is a brochure. If they can browse rendered outputs, inspect specs and verdicts, and re-run one locally in five minutes, the front door is the product.