Growth-Experiment Backlog Source-of-Truth Automation: The Table With Zero Rows That Wasn't a Bug

A relational database table named `experiments` reads as an obvious, confident answer to "where do growth experiments live" — right up until someone queries it and finds nothing at all, on any client, ever. Whether that means the feature genuinely has no data yet or means the real data lives somewhere else, under a name that doesn't say so, is invisible from the empty result alone. Only reading the system's own internal documentation, or the code that actually writes experiment data, reveals which one it is.

Centriu Vesper's growth-strategy work is organized around a client's active strategy project, itself built from a fixed set of modules — an ICP, a value proposition, a growth plan, and, among them, an experiments module. Each module's own content is stored as a single JSON document tied to that project, a design that lets every module type share one storage mechanism regardless of its own internal shape. A dedicated `experiments` table also exists in the schema — but the actual write path used by the product's own interface targets the JSON module instead, leaving the dedicated table permanently empty. The table isn't wrong to exist; it simply isn't where this particular kind of data was ultimately routed to live.

The migration's own header comment states the fact plainly, as something the tool-building work needed to respect rather than rediscover by trial and error: the `experiments` table is a facade — zero rows in the entire database — and the real backlog lives in the JSON module. Every read and write tool built for this system targets that JSON array directly: listing experiments reads the array and can filter by status; creating one appends a new entry to the array in a single atomic database update, keyed by a freshly generated identifier, rather than risking a read-modify-write race with a concurrent call; updating one finds the matching entry by that identifier inside the array and merges in only the fields that changed, leaving everything else untouched.

Three guardrails travel with every write. First, a hypothesis has to actually be written out, and has to reach a minimum length (fifteen characters) — nowhere near a guarantee of quality on its own, but enough to reject an empty or single-word placeholder standing in for real strategic thinking. Second, an effort estimate is normalized: whether entered as "baixo," "médio," "alto," or their English equivalents, it is mapped down to exactly one of three canonical values, and anything that doesn't match is rejected outright rather than stored as free text that a later query would have to guess at. Third, an experiment's status is confined to four fixed values, and there is no operation anywhere in the tool suite that deletes an experiment — reaching the end of its useful life is represented by marking it `discarded`, with the reasoning behind that call captured in the same update, so a discarded idea remains part of the project's own history rather than disappearing as though it never existed.

Someone investigating why a client's growth experiments seem to be missing runs a direct query against the `experiments` table and gets back nothing — for that client, and for every other client in the database. Read in isolation, that looks like conclusive proof the feature has never been used. The actual backlog, dozens of hypotheses deep for an active project, sits one table over, inside a JSON array the query never touched.

An AI agent can now read and manage a client's real growth-experiment backlog through a dedicated tool suite that targets where the data genuinely lives, enforcing the same hypothesis, effort-scale, and no-deletion rules the product's own interface already depends on — closing the gap between what a schema-first search would assume and what the system actually does.

This tool suite manages the experiments module specifically — it does not fill in or rewrite the other strategic frameworks in a client's project (positioning, branding, personas, and the rest), which remain governed by their own separate, already-existing tools and interfaces, unchanged by this work.

A table named exactly after the feature it seems to represent is a reasonable place to look first — and an entirely unreliable place to stop, if the product's own write path was built to target something else. Centriu's agent tools were built by tracing that real write path directly, rather than assuming a conveniently-named table was the authoritative answer.