One rail every AI routes through to act on production.
The whole architecture turns on one separation: what work is to be done, expressed as a recipe in an open format, is kept apart from which model does it, decided at runtime. That single seam is what makes the model a swappable supplier, the workspace portable, and a verified result safe to reuse across customers. Everything technical below follows from it.
- Execution
- A stateless, provider-agnostic harness. The model is selected at run time, never hard-coded.
- The rail
- A deterministic resolver every run passes through: canonicalize, look up, serve or compute, verify, log.
- The substrate
- An append-only provenance ledger on Supabase, built additively so a schema change never disturbs live serving.
The recipe and action model.
A recipe is a named, versioned description of a piece of work, written in an open workspace format. An action is a recipe packaged for one-tap install. Because the recipe describes the work and not the model, the same recipe runs on whatever model is best at the moment of execution, and it can travel to any runtime that implements the format.
| Property | What it means technically | Why it matters |
|---|---|---|
| Named and versioned | A recipe has a stable identity and a version; a new version is a distinct identity | Reuse never crosses versions by accident; upgrades are explicit |
| Open format | The recipe is expressed in a portable, published workspace format, not a proprietary blob | Any runtime can implement it; the customer can take it with them |
| Model-independent | The recipe names the work, not the provider; the model is bound at run time | The frontier is captured for free; vendor churn is absorbed underneath the customer |
| Content-addressable | A run canonicalizes recipe identity plus version plus sorted inputs into one content key | Two identical pieces of work resolve to the same key, which is the unit of reuse |
| Portable across accounts | An action installs and runs on the installer's own connected services | Build once, deploy many, with no per-account rewrite |
The content key is a hash over the canonical form of a request: the recipe identity, its version, and the sorted inputs. It is deterministic, input-sensitive, and version-bound. Two customers running the same shape of work on the same public inputs produce the same content key, which is exactly where reuse happens. Overlap is a logged fact at the content-key level, not an inference.
The resolver: the path every run passes through.
Every run passes through one deterministic, auditable resolver. It is the signed rail: the place trust, the ledger, and reuse all live, and it is neutral across models by construction. The resolver does one of two things on every run, and either way it writes a tamper-evident record.
| Step | What happens |
|---|---|
| Canonicalize | Normalize the run inputs into a stable content key over the recipe identity, its version, and the sorted inputs |
| 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, and the verified result becomes inheritable for the next tenant |
| Boundary | Only a shareable result enters the cross-tenant pool. A private-input run is always a cold miss and never inheritable across tenants |
Provider-agnostic execution, the harness.
Model-independence is real rather than aspirational because a stateless execution harness separates the recipe from the model. The harness is what routes a run to the best available model that meets the quality bar, at the moment of the run, and it is where cost is optimized without the customer feeling a migration.
Stateless workers
Runtime model selection
Cost-optimized routing
Vendor churn absorbed
If the workspace format is portable and the execution is provider-agnostic, the model vendors are suppliers, not competitors. A standard captures value precisely because it is not tied to the fortunes of any single supplier beneath it. The harness is the mechanism that makes that inversion true in code rather than in a slide.
The provenance ledger, additively built.
Every run writes to an append-only, tamper-evident ledger. It is the one substrate that measures the cache, carries the trust signals, and later pays the participation economy. The measurement system, the trust system, and the payment system are the same table. It was built additively on the existing execution log, with behavior-neutral defaults, so the change could not disturb live serving.
| Column | Type | Purpose |
|---|---|---|
| cache_outcome | text | cold_miss, warm_hit_self, or warm_hit_cross, written at run time so a cross-tenant hit is a logged fact, not a retrospective inference |
| served_from_run_id | bigint | Provenance. On a cross-tenant hit, the exact prior run this result was inherited from |
| source_brain_id | text | Provenance. Which tenant's brain produced the inherited result |
| verified | boolean | Did the verification gate pass on the served result |
| gate_result | text | The verification outcome detail, so a served result carries its quality proof |
| shareable | boolean | Did this run's inputs qualify for the cross-tenant pool. The privacy boundary, logged |
| is_synthetic | boolean | The wall between the mechanism-proof track and the real-traffic measurement track |
Result: a tamper-evident ledger where every cross-tenant hit carries a provenance link and a verification result. That is what turns digitally prove this is happening from an aspiration into an inspectable record.
The verification gate does double duty.
The gate is the same plan-act-verify quality bar the product runs on, serving two roles at once. For the individual user it is the check that separates an intelligence from a brittle automation. For the cache it is the correctness guarantee that makes cross-tenant reuse safe: a result is verified before it is ever inherited, so a reused result is proven-correct, not merely matching.
| 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 |
The false-pass rate, the share of gate-passed results later found incorrect on audit, is a first-class measured quantity, not an assumption. It is audited by recomputation and reported alongside the reuse rate, because a high false-pass rate would make reuse a liability even at a high hit rate. The two numbers are read together.
Messenger-native, source-truth-independent.
The surface is delivered by a universal messenger harness: first-class native adapters for the major platforms plus a universal connector for the long tail. The messenger is the surface, but it is not the source of truth. Every inbound data point is source-tagged at the messenger-contract layer, so the same brain is reachable from any surface and the customer's context is never trapped in one channel.
| Layer | Role | How it stays neutral |
|---|---|---|
| Native adapters | First-class Discord today; Slack, Teams, WhatsApp on the roadmap | Each adapter is a config-and-override layer over the brain, never the brain itself |
| Universal connector | The long tail of messengers via a single connector contract | One contract, so a new surface does not fork the brain |
| Source-tagging | Every inbound data point is stamped with its origin at the contract layer | The brain is reachable from any surface; context is never locked to a channel |
| The brain | Memory, context, connected-service config, authored actions | Lives independently of any messenger, in the exportable workspace repo |
Additive, shadow-first, verified against a real build.
The infrastructure was built methodically so no phase could disturb live serving and each phase could be verified with a real production build before the next began. This is how a claim like the ledger is shipped, PR #200 can be made without hedging.
| Phase | Deliverable | Status |
|---|---|---|
| Ledger | The additive proof columns on the execution log, behavior-neutral defaults | Shipped (PR #200) |
| Observatory | The read-only super-admin dashboard and the real-traffic queries over existing data | Shipped; verified with a real production build |
| Resolver logging | Writing cache outcome and provenance at run time, shadow-first (log-only before any serving change) | Shipped |
| Mechanism harness | The synthetic scenario runner, on a nightly schedule, with signed proof artifacts | Shipped, running nightly |
| Seed recipes | Publishing canonical shareable recipes to generate honest organic overlap | In progress; overlap accumulating on live traffic |
| Optimization loop | Input canonicalization and semantic near-match to raise the organic rate honestly | Staged |
Each phase followed the same loop: specify, build, verify with a real production build plus the harness's own assertions, then merge. The instrument is shipped and live; the remaining work is watching the organic curve accumulate and running the optimization loop to raise it honestly.
The rail is neutral; the ledger makes it inspectable.
The resolver spans every customer's runs regardless of which model executed them, because the shared surface sits above every model. That is the one property a single model vendor structurally cannot copy, and the ledger is what lets a diligence reader watch it happen rather than take it on faith.
A cache cannot span what a vendor does not host. Quinn's shared surface sits above every model, so its cache spans every customer's runs. The next page is the moat itself: the cross-tenant verified-result cache, the provenance ledger, and why the privacy wall is the same wall as the network effect.