For three weeks, one of our products was sitting on brand knowledge it hadn't told anyone about.
The store itself was innocent. A small record inside Vermeer, our ad studio, holding proof a customer personally attested: testimonials, press mentions, founder quotes, each one typed in and signed by the person vouching for it. Exactly the kind of thing the rest of the suite would love to know exists. A founder quote a customer has put their name behind is gold to the product that writes their content and the product that builds their strategy reports.
Nobody hid it. Nobody decided to keep it local. It shipped on June 29 inside a feature that had other things on its mind, did its job quietly, and no other product ever heard about it.
Then, on July 19, a plan for extending that surface ran the standard pre-build checks. Our plans carry a section called "Verified absences" — the gaps you prove exist before you build on them. One line in that section ended the quiet: the proof-items store, it noted, appears nowhere in the promotion-debt ledger. An undeclared debt.
Translation: this store holds durable knowledge about a brand, and it never signed a lease. Under our rules, the plan couldn't proceed as if that were fine. So the same plan did two things: opened the missing ledger row, and built the bridge that pays the debt, a one-way channel that forwards every attested fact to the canonical brand store. Four days after the flag, the bridge existed. And the ledger row it left behind carries a small, honest piece of bookkeeping in its "opened" column:
"2026-07-19 (flagged undeclared since 2026-06-29)"
The ledger recorded the debt, and it recorded how long the tenant lived there before anyone collected.
If you run a brand, you've heard the pitch this story sits underneath. Every multi-product platform you evaluate promises that its products make each other smarter. Use two of our tools and each learns from the other. This essay is about what it actually takes to make that sentence true, because we believe the honest answer matters to anyone deciding where their brand's knowledge is going to live.
The flywheel is a lease
What I've come to believe building a multi-product company: compounding is not an emergent property. Left alone, each product optimizes its own store and the center starves, politely, invisibly, one shipped feature at a time. Knowledge flows back to the center only if something makes it flow. Not culture. Not architecture diagrams. A contract.
Ours is one page. The rule at its core:
"Two compliant outcomes, chosen per feature at plan time"
Either the feature writes what it learns to the canonical brand store, or it opens a promotion-debt row: a named, dated entry in a ledger saying exactly what knowledge is being held locally, who owns it, and the path by which it eventually gets promoted. In the same plan that ships the store. Not later. Not "tracked in the backlog."
Rent is owed on anything that meets a two-part definition: a fact, decision, or preference about a brand that outlives the request that produced it, and that another product could act on.
The collection moment is plan review, the checkpoint every piece of planned work passes before anything gets built.
The check lives in the standing instructions every plan is read against, so every plan gets the same walkthrough regardless of who or what wrote it.
Does this feature store brand knowledge locally? Then show me the canonical write, or show me the row.
The landlord is a checklist that never gets tired, not a person having a good day.
That's how a three-week-old undeclared store gets caught by a plan that was only trying to add form fields.
The case law
A contract you enforce grows something a slogan never does: case law. The ledger's most useful content is the rulings about who doesn't owe, each one a line of reasoning attached to a real store. Four exemptions do most of the work, and each teaches something about what "brand knowledge" actually is.
One product lets customers upload brand assets: logo files, type specimens. Durable? Yes. About the brand? Obviously. Exempt anyway, because “a file is not a human-confirmed fact.” The upload is an operational artifact; the durable knowledge it carries (a confirmed hex value, a confirmed typeface name) promotes separately, through a confirm flow where a human signs off on the extracted value. And the vision model that auto-labels uploads gets a wall of its own: its “guesses stay tags, never facts.”
Another store tracks marketplace signals (ratings, review counts, prices) for a brand and its competitors, as a running log that only ever grows, never gets edited. Nothing in it will ever promote, because “a rating is a measured value, not a human-confirmed fact.” A number a machine read off a website is evidence, not truth. But here's the move I'd steal: the store still has a ledger row. Someone flagged that another product might someday act on a snapshot of it, so the row exists purely so the store is “tracked here explicitly rather than by silence.” The ledger tracks the decisions not to owe alongside the debts, so nobody re-litigates them by accident.
Campaign configuration (destination URLs, traffic splits) lives next to genuine brand knowledge and looks superficially similar. The ruling, verbatim: “Tracks remain campaign plumbing — promoted only if a cross-product consumer emerges.” Rent is owed on knowledge another product could act on. No consumer, no rent — and the ledger says so out loud, with the condition that would reverse it.
Some knowledge skips the whole apparatus: “Org ownership is canonical, no debt owed.” Which organization owns a brand is durable knowledge every product acts on — and it lands directly in the canonical store at write time, so there's no local copy to declare. The cheapest rent is the kind collected at the door.
Rent review
One more clause does quiet work. From the contract:
"A plan that extends or reshapes a debtor store must restate (or execute) that store's promotion path"
Touch a store that owes, and the lease gets re-read. When a July plan added a new field to one of the debtor stores (a brand-level creative default the user sets by hand), it couldn't just add the field. It had to restate, in the row, how the new field would eventually promote: a user-set default is human-confirmed, so it qualifies; machine drafts never will. The debt didn't grow silently. Nothing here is allowed to grow silently; that's the entire design.
And the ledger has a model tenant, worth contrasting with my squatter. The brand-family store in our research-reports product — founder identity, parent company, sibling brands — declared itself the day it was born: row opened July 5, in the same plan that created the store. The bridge that pays it was built three days later. The part I respect most: the row is still open. The status column reads "BRIDGE BUILT 2026-07-08", with "(dark)" right there in the ledger, because the bridge isn't switched on in front of customers yet. And the row refuses to close until the first real confirmed fact flows through in production. The proof-items bridge from my cold open sits in the same state: built, behind a flag, not yet live.
| The store that shipped undeclared | The store that declared itself | |
|---|---|---|
| When it declared | Three weeks after it shipped. The ledger reads “2026-07-19 (flagged undeclared since 2026-06-29)”. | The day it was born. Row opened July 5, in the same plan that created the store. |
| When the bridge was built | Four days after the flag. | Three days after the row. The status column reads “BRIDGE BUILT 2026-07-08”. |
| Where it stands today | Built, behind a flag, not yet live. | The row is still open, marked “(dark)”, and it refuses to close until the first real confirmed fact flows through in production. |
Code that exists is not rent paid. Value moving is rent paid.
A ledger that closed rows the moment the bridge was built would be exactly the kind of optimistic fiction it exists to prevent.
Why this matters to a brand picking its tools
The squatter is my answer to the obvious objection — that if the architecture is right, knowledge flows to the center naturally. That store was built by the same small team, in the same system, in the same month we were writing internal docs about the one canonical brain. It still shipped undeclared and sat for three weeks. Not malice, not ignorance — a feature with other things on its mind. Discipline decays per feature; that's deadline physics, not a moral failing. The contract's genius is that it doesn't preach against local stores: it concedes they'll happen and prices them instead.
Now turn the lens around, because your brand already lives inside an unenforced version of this problem. Your agency knows things about your brand your ads platform doesn't. Your email tool has learned things your social scheduler will never hear. Every tool you use is a product-local store, and almost none of them owe rent to anything. The compounding you were promised (by your stack, by your agency, by every "all-in-one" platform) depends entirely on whether knowledge flows back to a center, and in most stacks nothing makes it flow.
So when a platform tells you its products make each other smarter, ask the operator's question: what, specifically, makes knowledge move to the center, and how do you know when it hasn't?
If the answer is an architecture diagram and good intentions, you're buying the hope, not the flywheel.
Our answer is a ledger that remembers, to the day, how long one of our own stores went unnoticed and exactly how fast it got caught.
Up close, the network effect isn't a flywheel. It's a lease.
How Jinn works
How it worksWhat counts as brand knowledge that owes rent?
Rent is owed on anything that meets a two-part definition: a fact, decision, or preference about a brand that outlives the request that produced it, and that another product could act on.
What is a promotion-debt row?
A named, dated entry in a ledger saying exactly what knowledge is being held locally, who owns it, and the path by which it eventually gets promoted. In the same plan that ships the store. Not later. Not “tracked in the backlog.”
Does an uploaded brand asset owe rent?
No, because “a file is not a human-confirmed fact.” The upload is an operational artifact; the durable knowledge it carries, a confirmed hex value or a confirmed typeface name, promotes separately through a confirm flow where a human signs off on the extracted value.
Why doesn't a built bridge close the row?
Because the bridge isn't switched on in front of customers yet, and the row refuses to close until the first real confirmed fact flows through in production.