Your knowledge DB

The Flywheel distills your resolved outcomes into a knowledge DB — redacted domain facts about what tends to work for each of your workflows. Your knowledge DB (/knowledge in the dashboard) is where you see all of it. It is the ownership surface: everything on it belongs to you, and every number on it is re-derived at read time from your outcome ledger and the knowledge DB — never a value someone typed into a UI.

What the screen shows

Overview tab

• Counts and coverage — how many situations the DB covers, how many patterns are known, and how many coverage gaps are open. Gaps are first-class: "what we do not know, and what would fill it" is a rendered state, not an empty list.
• What it taught — the flat list of every known fact, each shown with the evidence count n and the 95% interval it was taught with, plus its window and lineage. A fact renders with its uncertainty, or it does not render. Every pattern is labelled an observed association, never a cause — a candidate that only reaches your calls through the Flywheel ratchet, never applied on its own.
• Injection policy per workflow — for each workflow, whether knowledge injection is on or off, the per-module token cap, and the enabled kinds. This is shown read-only here; see where it is set.

Tried and did not help tab

• The candidates you refused, kept with their evidence instead of vanishing: the offline screening result, the live status, the mandatory reason the candidate was refused with, and when it was refused. A refused candidate is stored, not deleted — you can always see what was tried and why it did not help.

A seeded demo workspace carries a persistent "Example data" badge, so demo content is never mistaken for your own.

Why there are no per-fact approvals

Approving facts one by one is theatre. A knowledge DB with hundreds of facts is not made safer by a hundred checkboxes — it is made unusable. So approval is a policy, not a per-fact gate: you decide, per workflow, whether knowledge injection is on, what token budget it may occupy, and which kinds are enabled. That policy governs every fact for that workflow at once, and it is the same setting the gateway reads when it decides what (if anything) to inject.

Because the policy is the control, nothing on this screen needs a write. The numbers reconcile against the ledger and the knowledge DB directly, so the screen can never drift from what was actually distilled.

Where the injection policy is set

The injection policy is read-only on this screen and set on the workflow itself — the call type's Self-improve card (or PATCH /v1/call-types/:id), the same place the self-improve mode lives. Turning a workflow off captures outcomes without proposing or adopting anything; assist builds the knowledge DB and proposes tested candidates to your Improvements inbox; the candidates that did not pass are kept here under "tried and did not help."

Next steps

• Read The Flywheel for the loop that produces these facts and the laws that keep every one honest.
• Read Holdout and lift for how a candidate is screened, confirmed live and adopted — and why a refused one is kept, not erased.

Browse company knowledge

GET /v1/knowledge searches the current workspace's stored lessons and supported derived facts. Use a config:read or config:write key, or a member session with X-UR-Workspace. Both knowledge and corrections consent must remain enabled. Reads make no embedding or model calls.

The response contains data, has_more, next_cursor and snapshot_at. Current candidate lessons can have current=true and active=false; they have not become the incumbent. active identifies the incumbent's nonretired lesson, not a guarantee that each request receives it. Workflow disable/pause and serving eligibility remain governed by learning controls. Neither publication nor admission establishes efficacy.

GET /v1/knowledge/{id} reads one stable item: fact:<fact_id> or lesson:<playbook_version_id>:<lesson_id>. URL-encode the full ID. Foreign, erased and unknown items return 404. Lessons include their text, atomic conditions/exceptions/tool scope, recipe and metadata-only citations. evidence_count and evidence_truncated disclose the 100-reference bound. Citation availability says whether that same-workspace/workflow metadata record exists; it does not promise a retained raw transcript or prove a lesson's correctness. Fact lineage availability is explicitly not_checked. Facts expose only supported kind descriptions, structured scope, sample counts, rates, intervals and source references. Raw fact bodies, correction example text and raw episode content are excluded.

Pages use stable ID ordering. Source changes invalidate a continuation with 409 knowledge_cursor_stale, as does a cursor older than 15 minutes; restart the search. A malformed cursor or changed filters return 400 knowledge_cursor_invalid. snapshot_at records when the traversal began, not a durable database snapshot. Each page rechecks current consent and deletion rules. Existing correction-body retention does not expire derived lessons by age; revocation and deletion still remove their content through existing controls.

Export company knowledge content

GET /v1/knowledge/export accepts the same filters and returns ur.company_knowledge/v1. This separate, audited operation requires an owner/admin session, 2FA, X-UR-Workspace and explicit training_export consent in addition to knowledge/corrections consent. API keys cannot perform this export. The existing GET /v1/flywheel/knowledge/export metadata/statistics bundle remains available and unchanged.

The content export includes selection (normalized filters), data, an explicit exclusions list, content_hash, complete, truncated, next_cursor, generated_at and snapshot_at. A complete filtered selection is not the whole workspace. Any page that omits preceding or following matching items is marked complete=false and truncated=true; a final continuation still represents a fragment even with no next cursor. Continue using the same export route and unchanged selection to obtain further pages. The hash covers the schema, workspace, selection, exact projected data, omissions and completeness flags; generated clocks and cursor are excluded. This is portable retained knowledge, not frontier model weights, an import format or an automatic activation request. Model training remains separate future work.

Search and export use the management path, outside the request-time lesson-serving budget. Returned content and version-state lookups are page-bounded. The existing visibility/drop metadata and revision aggregates can still grow with workspace history; this release does not promise constant-time searches or a new search index. Ordinary uncited episode traffic does not invalidate cursors; changed or deleted cited evidence metadata does.