Skip to content
The Keyworks Paper — Assessment & Decision
Admin & Reference
On this page

The Keyworks paper — assessment and decision

What we’re taking from the “Keyworks” data-platform research paper, what we’re pushing back on, and what we’re actually building. Written July 2026.

TL;DR

The Keyworks paper designs an AI-native, self-building, self-healing data platform — the layer that produces and keeps data trustworthy. Today’s KeyOne is mostly the decision app that sits on top of such a layer. They’re adjacent, not the same thing, and the paper says so of itself (“dream-mode… practicality engineered in later”).

Verdict: aligned in values and a few real primitives; not aligned in architecture. The paper is a good north star. Its values are already ours. Its FMCG-specific ideas are worth real, incremental investment. Its generic-platform moonshot (an intent-language compiler + autonomous agents that touch production) is where we push back hardest — highest cost, highest risk, least domain edge, and least supported by its own cited research.

We are building the FMCG-useful parts incrementally on the current lake, and not committing to the compiler / standing-autonomous-agent parts.

What the paper gets right (keep)

  • “Bad data executes.” The correct organizing frame for a decision engine: a dashboard tolerates bad data, a replenishment engine acts on it. This is already our operating principle — it’s the same “fabricated-default” bug class we fight continuously (an invented value rendered as measured fact).
  • Agents write intent, never touch production. The best governance idea in the paper, and research-backed: agents complete <4% of end-to-end pipeline builds, so they must not hand-carry artifacts to prod. Every change is a reviewable, tested, versioned diff. (This is, incidentally, exactly how our own multi-agent build sessions already work.)
  • The semantic layer is the highest-leverage reliability investment (research: +17–23 percentage points of SQL accuracy from a small semantic layer). This is also the place our code most contradicts the vision — our metric/semantic layer is currently a façade (the metrics/*.json are read only by a unit test; metrics live as SQL in flow specs).
  • Confidence-tiered identity with a first-class “genuinely new” (NIL) outcome. Dead-on for FMCG; maps onto MDM, which half-exists.
  • Two-speed cognition — cheap deterministic checks everywhere, LLM only for the novel. Economically correct; a mature system should cost less per unit of data over time, not more.
  • Quarantine-not-drop, coverage-degraded labels, stale-pinned snapshots. Excellent, cheap honesty primitives. The paper at its most buildable.

What we push back on

  • The autonomous-onboarding “magic moments” are the least evidence-backed part, and the paper half-admits it. The “39-minute autonomous SAP onboarding” scenarios ride on exactly the capability the cited research puts at <4% success. The supervised version (draft → human approves a legible diff) is real; the autonomous version is aspirational. Don’t let the scenarios set the expectation.
  • KeyLang + the Loom (intent-as-source-code compiler) is the biggest bet and the one most likely to partially fail. Every declarative language grows escape hatches (the paper concedes this in open question 4). Real distributor feeds are idiosyncratic enough that a meaningful fraction need embedded procedural code anyway, and each escape hatch leaks the compiler’s guarantees. Multi-year effort; pays off only if intent-coverage stays high.
  • A standing autonomous Doctor that acts on production is where danger concentrates. Their own open question 10 (“when the Doctor is wrong”) is the crux: a confident-but-wrong diagnosis with auto-apply authority does damage at machine speed. Keep the Doctor propose-only far longer than the paper implies; treat auto-apply as a rare, hard-earned exception, not a goal.
  • Cross-tenant “immunity carries shape, never data” is a compliance landmine stated as a slogan. For multi-tenant FMCG SaaS, “provable” is the whole game, and the paper files enforcement under open questions. Nothing cross-tenant ships until that’s a proof, not a promise.
  • The biological framing (the “Organism”) smuggles in false confidence. “The body doesn’t ask permission to sweat” is a vibe, not a spec; the paper’s own comparison table flags metaphor drift as its chief risk.
  • Scope-vs-product. The Keyworks is a data-platform company. KeyOne sells FMCG decisions. The platform is a means to trustworthy decisions — the paper occasionally treats it as the end. Building the full platform risks becoming a different product than the one customers buy.

What’s genuinely useful to FMCG (ranked) — and what we’re building

The paper’s domain edge is not the compiler or the agents (those are generic). The FMCG value is concentrated in four ideas, all buildable incrementally on the current lake / data-health / flows / MDM / dim tables — no compiler required.

1. Unit-of-measure & currency typing (highest value)

Cases ↔ eaches ↔ pallets with a pack-size witness, and currency scale (units vs thousands). Catches the single most catastrophic invisible FMCG bug — the silent unit flip that inflates or guts a number 12–24× and executes into a bad order. This is a sentinel/validator, not a compiler: a check that a quantity, given its SKU’s pack size, implies a plausible per-unit value; and that a currency column’s magnitude matches its baseline.

2. Coverage-collapse / distribution sentinels

Scenario 4: half a region’s outlets silently drop out of a feed, national volume still looks fine, volume checks cannot see it. A real, common, decision-corrupting FMCG failure. Detected as distinct-outlet-count per region vs a learned baseline, checked against the store master — a direct extension of the data-health page.

3. Reconciliation as a conservation law

sell-in − sell-out − stock Δ − returns ≈ 0 per SKU × period, within tolerance. Genuinely FMCG, genuinely catchable, and exactly the Scenario 5 “reconciliation mystery.” A flow-authored SQL check with an honest caveat when a term (e.g. returns) is structurally absent from a feed.

4. Demand-driven Coverage Map

“What regions / SKUs does nobody supply, ranked by decision impact.” The same idea as the field-coverage-gaps work already in the app, one layer up: a slot ledger over the canonical schema, each slot filled / partial / open.

Least FMCG-differentiated (be slow / skeptical)

KeyLang, the Loom, the running Guild of agents, antibodies — impressive general data-platform engineering, but not where the domain moat is. Deprioritized.

Decision

  1. Adopt the values (already in place): bad data must be known loudly and never silently execute; no fabricated default rendered as fact; honest “not measured” ≠ “healthy”.
  2. Build the four FMCG-useful items incrementally as sentinels + identity discipline on the existing lake — starting with unit-of-measure typing and coverage-collapse detection, because they catch the highest-impact invisible failures and extend surfaces we already have (data-health, flows, MDM, dim_store/dim_product).
  3. Make the semantic layer real (turn the façade into a small curated contract/ontology that generation and checks resolve against) — the one place the code most contradicts the vision and the highest-leverage reliability step.
  4. Do NOT build the intent-language compiler or grant standing agents authority to mutate production. Keep any diagnostic AI propose-only, behind a reviewable diff.
  5. Nothing cross-tenant (shared “antibodies”/recipes) until leakage prevention is provable, not promised.

This document is the record of that decision and its reasoning.