Export your knowledge DB
Take your whole knowledge DB out as a portable, content-addressed bundle — every distilled fact, exemplar, prior and process pattern with its evidence and lineage, plus the learned modules and their lift history. It is yours; training a model from your content happens only for your own workspace, never a shared or cross-workspace model.
Preview — not on the hosted service
learning.enabled master switch), there is no hosted MCP endpoint, and whether learning improves a given agent is not yet demonstrated. See the evidence status.The Flywheel distills your resolved outcomes into a knowledge DB: redacted domain facts about your workflows, each carried with its uncertainty — an evidence count, an interval, a window, and lineage back to your own outcome events. Export takes that whole DB out as a single portable file you own.
The bundle is yours to take. It is a projection of your own append-only outcome ledger and knowledge store — never a second source of truth. It is a different object from the training-ready dataset export (which builds SFT/preference examples for you to train on): the knowledge bundle is the DB itself, for portability and audit. Training a model from your content is a separate, governed path that runs only for your own workspace.
What the bundle contains
GET /v1/flywheel/knowledge/export returns one JSON object
(schema: ur.knowledge_bundle/v1) with these sections:
facts— the model-class failure-mode facts.exemplars— the clustered, redacted correction patterns (how your reviewers fix outputs).priors— the resolution base-rate and calibration priors, each with its rate and interval.process_patterns— the observed process-pattern associations per workflow × situation.modules— the learned modules and their lift history: the epoch, the live-confirmation verdict, and the recorded treated − holdout interval.lineage— one row per exported item, linking it back to the outcome-event ids and content hash it derives from.
Every item carries ids, content hashes and derived statistics only — never a
raw prompt or output body. You join an item back to the fuller, retained view you
already own (the /knowledge screen) by its fact_id or content_hash.
Current facts vs history
Your knowledge store is append-only: when a fact changes, a new row is written and
the old one is kept. The bundle keeps all of it — the history is yours — but it
is never ambiguous. Every fact carries current: true|false, and a superseded
predecessor carries superseded_by (the id of the fact that replaced it), decided
by the same read-time rule the runtime uses to serve the live fact. Each
section's counts are split into current and history, so you always know which
facts are live and which are kept for the record.
It is deterministic and content-addressed
The bundle is addressed by a bundle_hash computed over its canonical content.
The generation timestamp (generated_at) is excluded from that hash, so
exporting the same data twice produces a byte-identical bundle and a stable
bundle_hash — you can diff two exports, or verify an archived one, without the
clock getting in the way.
Consent, revocation and retention
Export is consent- and retention-bound, exactly like every other derived surface:
- A workspace that has not enabled the training-export consent gets
a named refusal,
EXPORT_CONSENT_REVOKED— the whole bundle is refused, never partially emitted. - A revoked fact (a consent-withdrawal tombstone) and a suppressed fact (an active retrieval-suppression window) are dropped from every section and from lineage, through the same drop rules the knowledge-pack export uses.
- Items past retention are simply absent.
Who can export it
Exporting the whole knowledge DB is an owner or admin action (a viewer is
refused). The request is authenticated with your dashboard session, every export
is audited (the bundle_hash and per-section counts are recorded — never any
content), and the structured log carries ids, hashes and counts only.
From the dashboard
Your Knowledge page (/knowledge) has one Export knowledge action in the
header. It downloads the bundle as a JSON file named after its bundle_hash. If
your workspace has not enabled the training-export consent, the action tells you
so instead of producing an empty file.
Export vs. training
We build this bundle for you; the export path itself invokes no fine-tuning or
trainer API — a grep-level guarantee (TST-FLW-TRAINING-GOVERNED) that the same
scan applies to the training-ready dataset export. Training a model from your
content is a separate, governed decision: it happens only for your own
workspace, only behind the six-conjunct train_allowed authorization, and never
produces a shared or cross-workspace model — and enabling this export never
authorizes it (its switches and the train_allowed enforcement are built; a governed
trainer is not). The bundle is for you: to
keep, to inspect, to carry to another tool, or to feed to your own training run if
you choose to.
Stored lesson content and search
The separate company knowledge API provides lexical search,
version-specific lesson detail and metadata-only evidence references. Its explicit session-only content export,
GET /v1/knowledge/export, uses ur.company_knowledge/v1; it includes stored lesson text and a safe derived
fact projection. The metadata bundle described above is unchanged. Every content export states its filters,
omissions and pagination completeness. Neither format exports frontier model weights.
Your knowledge DB
The read-only dashboard screen where you own what the Flywheel distilled from your own traffic — counts and coverage, what it taught with the evidence behind each fact, the injection policy per workflow, and the "tried and did not help" tab.
Holdout and lift
The standing holdout, the exposure arms, and how the Flywheel proves a real improvement — superiority behind a randomized live contrast, arms never pooled, and the laws that keep a merged PR from becoming a result.