The network effect a model vendor structurally cannot copy.
When Quinn does a piece of shareable work for one customer, verifies it against a quality bar, and records it, another customer who asks for the same shape of work on the same public inputs inherits the verified result instead of paying to recompute it. If that cross-tenant saving rises with scale, it is a network effect a single model vendor cannot copy, because a vendor's cache cannot span work it does not host. The infrastructure is shipped. What remains is watching the curve print.
- Status
- The cross-tenant cache and provenance ledger shipped in PR #200. The mechanism is proven correct and safe.
- The one number
- Whether cross-tenant saving rises with scale on live traffic. The single number the business turns on.
- The proof
- Instrumented and watched in real time in the observatory, not argued about in prose.
Do shared work once, replay it near-free.
Compute is trending toward free. The durable value in Quinn does not come from marking up tokens that get cheaper every month; it comes from doing shared work once and replaying it near-free for everyone who needs it. The arrow that matters is cost per run falls as adoption grows, which is a promise ordinary software pricing structurally cannot make.
A deterministic resolver, on every run.
The cache is a runtime path every run passes through: canonicalize the inputs into a content key, look up a prior verified shareable result from any tenant, serve it on a hit or compute and verify on a miss, and enforce the boundary that only shareable work ever enters the pool. The resolver is covered in full on the technology page; here is what it means for the moat.
| Step | What happens |
|---|---|
| Canonicalize | Hash the recipe identity, its version, and the sorted inputs into a stable content key |
| Look up | Search for a prior verified, shareable result for that content key, from any tenant |
| Hit | Serve the inherited result, log a cross-tenant hit with a provenance link, at a cost near zero |
| Miss | Compute the work, run it through the verification gate, log a cold miss; the verified result becomes inheritable |
| Boundary | Only a shareable result enters the cross-tenant pool; a private-input run is always a cold miss |
Input canonicalization
Semantic near-match
Every reuse carries a proof chain.
Every run writes to a tamper-evident ledger. The ledger is the substrate that makes the cache auditable, carries the trust signals, and later pays the participation economy. The measurement system, the trust system, and the payment system are one thing.
| Recorded fact | What it proves |
|---|---|
| Cache outcome | Whether the run was a cold miss, a same-tenant recompute, or a cross-tenant hit. Written at run time, so a cross-tenant hit is a logged fact, not a guess |
| Provenance link | On a cross-tenant hit: exactly which prior run, for which tenant, this result was inherited from. The digital proof chain |
| Verification result | Whether the gate passed on the served result. Proves the cache serves correct, not merely matching, results |
| Shareable flag | Whether this run's inputs qualified for the cross-tenant pool. The privacy boundary, logged |
| Synthetic flag | Whether this row came from a test rig or real traffic. The wall that keeps the headline number honest |
A cross-tenant hit that carries a provenance link and a passing gate result is a tamper-evident record that a specific piece of verified work was inherited by a different customer at near-zero cost. A diligence reader can click any hit and walk the chain: which prior run produced it, for which tenant, that the output hash matches, and that the gate passed. The proof is digital and inspectable, never asserted.
The gate is what makes the cache safe.
A cache that replayed unverified results would serve matching but possibly wrong work, and one bad result would propagate to every customer who inherited it. Quinn verifies before it serves, so a reused result is proven-correct. The cache and the verification are not separable features: the cache is only defensible because the work it serves was verified before it was ever inherited.
| Without the gate | With the gate |
|---|---|
| The cache serves whatever matched the key | The cache serves only results that passed the quality bar |
| A wrong result propagates across tenants | A wrong result never enters the inheritable pool |
| Reuse is a risk | Reuse is a guarantee |
| The customer must re-check inherited work | The gate result travels with the inherited work |
This is also the foundation of the most durable revenue line. People pay for a guarantee whose value is independent of compute cost: a proven-correct, gate-verified result. As compute trends toward free, the value of certainty does not deflate, and it is exactly the verification gate that produces it.
The privacy wall is the network-effect wall.
The most important architectural fact about the cache is that its network effect and its privacy wall are the same wall, built from the first line of code. The saving comes from shared computation on shared work, never from exposing one person's private brain to another.
| Input type | Cache behavior | Cross-tenant sharing |
|---|---|---|
| Shareable (a recipe on non-private, public inputs) | Enters the shared pool once verified | Yes; inheritable by any tenant |
| Private (a run on private inputs) | Always a cold miss | Never; computed fresh, never inheritable across tenants |
A cache that ever leaked private work across tenants would be uninvestable and unshippable; a cache that provably never does is the moat. The elegance of the design is that the same boundary that protects privacy is what makes the network effect legitimate. Overlap is real precisely because it is drawn only from shareable work, so the cross-tenant hit rate is an honest measure of genuinely shared computation and never a measure of leaked private data.
Why a model vendor cannot copy this.
The cross-tenant cache is the one part of Quinn that a single model vendor cannot copy without becoming Quinn. The reason is structural, not a matter of effort or capital. A cache cannot span what a vendor does not host.
| Requirement for a cross-tenant cache | The model vendor's position |
|---|---|
| The cache must span work across many customers | A vendor's cache can only span work the vendor hosts; it cannot span work done on a surface it does not own |
| The shared surface must be neutral across models | A vendor optimizing its own model cannot be neutral across models |
| The result must be verified and provenance-tracked at the work layer | A vendor caches at the token or prompt layer, not the verified-work layer |
| The reuse must pay an open builder base | A vendor optimizing its own margin cannot credibly pay an open builder base against itself |
Quinn's shared surface sits above every model, so its cache spans every customer's runs regardless of which model executed them. A model vendor's cache is confined to its own model's traffic and its own hosting, and it has no incentive or ability to make that cache span a neutral, multi-model, multi-customer surface. That is the flywheel a single model vendor structurally cannot copy.
Two tracks, never mixed.
The differentiator of this case is that the number the thesis turns on is instrumented and watched in real time, not argued about in prose. The measurement is built so it would survive an adversary trying to prove it fake. Mechanism proof and thesis measurement are separated at the data layer and never mixed.
| Track A, mechanism proof | Track B, thesis measurement | |
|---|---|---|
| Question | Does the cross-tenant cache work correctly and safely? | Does real cross-tenant overlap happen, and rise with scale? |
| Tenants | Synthetic, flagged as such | Real only |
| Proves | Tenancy, provenance, correctness, isolation (the plumbing) | The one number the business turns on |
| Visibility | Its own panel, labeled synthetic | The headline chart, organic only |
| The rule | May never contribute a single row to the headline rate | Never contaminated by a synthetic run |
The synthetic-versus-organic partition is load-bearing and enforced at query time, not by convention. If a stakeholder can ever ask is that number real or is it your test rig, the harness has failed.
The observatory renders the ledger as it fills.
An investor-scoped observation surface renders the headline chart of cross-tenant hit rate against cumulative scale, the cold and warm-self and warm-cross splits, dollars of compute saved, a provenance explorer for inspecting any hit's chain, and an isolation-assurance panel that confirms zero private-run leakage. It reads organic traffic only. It is the difference between telling an investor the moat is forming and showing them the ledger as it fills.
Proven today, versus being measured.
This case holds one distinction with total discipline, because a room that blurs it hands a diligence analyst a contradiction in the first hour. The plumbing is built and proven safe; the one empirical question that remains is whether real cross-tenant overlap rises with scale on live traffic.
- The cache saves within a single customer's own repeated work
- The mechanism serves correct results; verification passes
- The mechanism is isolated; no private-work leakage
- Every reuse carries a provenance chain
- The infrastructure is shipped (PR #200)
- That the saving crosses between customers
- That the cross-tenant rate rises with scale
- The dollar magnitude of cross-tenant saving at scale
- Where the organic curve lands: bear, base, or bull
- The audited false-pass rate at scale
If reuse rises, the thesis holds and Quinn is a network. If the saving is mostly a single customer replaying their own work, that is good engineering but not a moat, and Quinn is valued as a good AI application. The business turns on this one number, and the case is built to show it printing rather than to assert it.
A moat that widens with use.
The cache is the network effect at the center of Quinn's defensibility, and its durability comes from these properties together.
| Moat property | Why it holds |
|---|---|
| Compounds with adoption | Every additional customer who runs shareable work warms the cache for everyone; the moat widens with use |
| Cannot be copied by a model vendor | A vendor's cache cannot span work it does not host |
| Is safe by construction | The verification gate and the privacy wall make reuse correct and isolated |
| Is inspectable, not asserted | Every hit carries a provenance chain a diligence reader can audit |
| Feeds the economy | The same ledger that measures the cache pays the builders, referrers, and seeders |
| Improves margin as compute falls | The buyer's price is pegged to recompute cost and falls with it, while the durable-layer margin holds |
Stated without hedging.
The single dependency the whole case rests on is stated plainly: the cache must save across customers, not just within one, and that is the number being measured now.
| Risk | Assessment | Mitigation / status |
|---|---|---|
| The cross-tenant curve is flat (saving is intra-tenant only) | The single largest risk in the business | Being measured on live traffic; the seed recipes are designed to generate honest organic overlap |
| Overlap depends on a few popular recipes | Would make the moat narrow | The honesty pass reports the rate with and without the top recipes, so breadth is visible |
| A privacy leak across tenants | Would be fatal | The privacy wall is the network-effect wall, enforced at the ledger; a private run is always a cold miss |
| The number is doubted as a test artifact | Would undermine the proof | The synthetic-versus-organic wall is enforced at query time; the headline chart is organic only, and every hit is inspectable |
| Compute falls so fast the saving is trivial | Would compress the near-term spread | Durable revenue shifts to certainty, the standard, and the registry; the cache remains the network effect regardless |