ultrarouter docs
Concepts

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

The data flywheel and the learning loop run on the local stack only. They are off on the invite-only hosted gateway (the 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.

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.

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.