Team Knowledge Hub

The Knowledge Hub reads directly from your team org's running Brain instances via the cachly API. It does not store a separate copy — every page reflects the live state of the Brain.

An org selector (shown when you belong to more than one org) lets you switch context. Your selection is saved to localStorage and survives tab switches.

A searchable, browsable list of every lesson the Brain has crystallized across all org instances. Lessons are de-duplicated by topic (the most-recalled version wins) and ranked by recall count, so the most battle-tested knowledge rises to the top.

Search: free-text across topic, body, author, and tags. Case-insensitive, client-side — instant results.

Severity filter: show only critical major or minor lessons.

Export CSV: appears when results are present. Exports the currently-filtered set — filter by severity or search first to get a focused slice. Columns: Topic, Outcome, Severity, What Worked, What Failed, Author, Recalls, Confidence %, Tags.

The API caps results at the 1,000 most-recalled lessons per org. Lessons with no recalls yet don't appear here — they need at least one hit to surface in the Knowledge Base.

The retention view answers one question: what happens to knowledge when someone leaves? The short answer: nothing — it stays in the Brain and keeps being recalled.

How it works: every lesson the Brain stores can carry an optional author field (set via learn_from_attempts). The retention endpoint cross-references those author strings against your current org roster. Members whose rows still exist are active; authors not matched to any current member are former.

Metrics:

• Knowledge retained — lessons authored by former members that are still in the Brain.
• Still recalled — how many times those lessons have been used since the author left. This is the number that proves ROI.
• Former / Active contributors — unique author counts by status.

Export CSV: full contributor breakdown including top topics and last-active timestamp. Useful for offboarding reports and leadership presentations.

Auto-generated Day 1 reading for new hires. Pulls the most-proven lessons from the org Brain, filters them by minimum quality thresholds, groups by topic category, and presents them as a numbered list.

Quality thresholds (built in, not configurable):

• ≥ 2 recalls (proven, not theoretical)
• ≥ 50% confidence score
• Top 12 lessons shown (the highest-recalled that pass)

Grouping: topic categories are inferred from the topic string — everything before the first : becomes the category (e.g. deploy:order → deploy). Topics without a colon fall into "general".

Print / Save as PDF: use browser Print (⌘P / Ctrl+P) → Save as PDF. The page includes print-optimised styles that hide navigation and format the brief cleanly for A4/Letter.

The retention endpoint matches lesson author strings against your org member list using four strategies, in order (all case-insensitive):

1. Full email match — [email protected] matches a member with invite email [email protected].
2. Email local-part — jane matches the same member.
3. Cross-domain local-part — an author string of [email protected] also matches via its local part jane.
4. Display name — Jane Smith matches if the member's display name is set to "Jane Smith".

Authors that don't match any strategy appear as former in the retention table. This correctly handles external contributors and automation bots — their lessons still count toward retained knowledge.

When developers use their full name in git commits or MCP sessions (e.g. author: "Jane Smith"), email-based matching fails. Set a display name once to fix this:

1. Go to Team → find the member row.
2. Click set display name… under their email.
3. Enter the exact string used in lessons (e.g. "Jane Smith") and click Save.

Display names are org-scoped and admin-only. You can also set them at invite time via the API:

POST /api/v1/orgs/:id/invite
{
  "email": "[email protected]",
  "role": "member",
  "display_name": "Jane Smith"
}

Or update an existing member:

PATCH /api/v1/orgs/:id/members/:memberId/display-name
{
  "display_name": "Jane Smith"
}

Both endpoints require a valid JWT (Bearer token) and org membership. Responses are JSON.

{
  "org_id": "uuid",
  "count": 42,
  "lessons": [
    {
      "topic": "deploy:order",
      "outcome": "failure",
      "what_failed": "migrated before column existed",
      "severity": "major",
      "author": "jane",
      "tags": ["deploy", "migration"],
      "confidence": 0.82,
      "recall_count": 17,
      "ts": "2025-11-04T09:12:00Z",
      "instances": ["uuid-a", "uuid-b"]
    }
  ]
}

{
  "org_id": "uuid",
  "total_lessons": 200,
  "attributed_lessons": 120,
  "retained_lessons": 35,
  "retained_recalls": 408,
  "active_authors": 5,
  "former_authors": 2,
  "authors": [
    {
      "author": "alice",
      "status": "former",
      "lesson_count": 20,
      "total_recalls": 231,
      "last_active_ts": "2025-09-01T00:00:00Z",
      "top_topics": ["deploy", "auth", "db"]
    }
  ]
}