MedallionAI Wiki

README

aiwiki

A searchable knowledge base of everything Medallion has learned about its customers and the payers they work with. Claude reads Gong calls and Salesforce updates, turns them into wiki pages, and answers your questions with citations.

Browsable at aiwiki.mdln.co, but most useful when you query it from an LLM.

Clone the repo, ask Claude questions, sync occasionally to get fresh data.

How to use

git clone git@github.com:trymedallion/aiwiki.git
cd aiwiki

Point Claude at the aiwiki folder:

  • Claude Code (CLI): npm install -g @anthropic-ai/claude-code, then cd aiwiki && claude.
  • Claude Cowork (desktop): add the aiwiki folder as a workspace.

Ask natural-language questions — “What are Cortica’s top issues?”, “Which payers have the worst turnaround times?”, “Summarize every commitment we’ve made to Cortica.”

Say “sync” at the start and end of a session to pull the latest wiki and push your query log.

Pages refresh roughly daily as the maintainer ingests new Gong calls and Salesforce updates. Don’t edit the repo directly — just ask questions and sync.

How it works (technical)

The repo is a flat markdown knowledge base in the style of Karpathy’s LLM wiki. Claude is the only writer: the maintainer pulls raw sources, Claude distills them into wiki pages, everyone else reads. No database, no vector store, no embeddings — the whole system is grep and markdown.

Files

  • Sources (immutable) — raw/gong/<date>-<call-id>.md holds a full Gong transcript with participant metadata. raw/salesforce/<date>-<customer>.md holds a delta of account / opportunity / contract / note / case / touchpoint / attachment changes since the last fetch — or a one-time ## Bootstrap — initial state section on the first pull of an account. The only thing ever edited on a raw file is its frontmatter ingested: true/false flag.
  • Distilled pages — wiki/customers/<slug>.md and wiki/payers/<slug>.md, one page per entity. Only two entity types exist; processes, people, and topics are captured inline on the customer or payer they belong to, not as their own pages.
    • Customer pages use a Snapshot-first layout: **Commercial** / **Profile** / **Operations** subgroups, then Key Contacts, Active Work, Open Issues & Requests, Decisions & Commitments, Source History.
    • Payer pages use the older shape: Overview / Key Contacts / Active Work / Pain Points / Decisions / Key Facts.
  • Logs — logs/<slug>.md, one append-only file per user (slug = email local-part for @medallion.co, full email otherwise). Every query, ingest, lint, and sync is recorded. One file per person means no merge conflicts on sync.
  • The contract — CLAUDE.md at the repo root is the spec: page templates, section names, slug conventions, extraction heuristics, merge rules, lint checks. Claude reads it on load. If a page looks a certain way, the rule lives there.

Ingest

Triggered by the maintainer:

  1. Run integrations/gong/fetch.py or integrations/salesforce/fetch.py to land new raw files.
  2. Ask Claude to “ingest new gong” or “ingest new salesforce”.
  3. Claude fans out one sub-agent per source file. Each identifies the customers and payers mentioned, routes extracted facts into the right page sections, appends the source path to the page frontmatter, bumps last_updated, and flips ingested: true last as its checkpoint.

Key properties:

  • Merges de-dupe, not overwrite. If a new fact contradicts existing content, both values are kept and the older one is marked possibly stale per <source> with a cite.
  • Idempotent re-runs. The ingested: flag plus the de-dupe merge mean a crashed batch picks up where it left off — no handoff file needed.
  • Salesforce diffs only touch customer pages. Payer signal comes from Gong calls, not CRM. Field changes render as strikethrough-plus-new-value with an inline cite back to the diff file, so history is never lost.

Query

  • Every answer ends with a **Sources:** line listing every wiki page it read, as markdown links.
  • Contested facts, direct quotes, and specific numbers also cite the raw transcript or Salesforce diff they came from.
  • No retrieval step in the traditional sense — Claude uses grep and Read the same way a human navigating the repo would. The wiki’s job is to make the right page easy to find; CLAUDE.md tells Claude where to look.

Lint

Running “lint the wiki” triggers a pass over every customer and payer page, checking for:

  • Contradictions across pages
  • Stale pages (last_updated > 90 days with no recent source)
  • Orphans and broken relative links
  • Missing back-references to entities mentioned in prose
  • Schema drift in the Commercial subgrouping
  • Nested-subsection sprawl
  • Ephemeral Key Contacts entries
  • Citation noise

Mechanical findings auto-fix on confirmation; judgment findings are reported for the maintainer to handle manually.

Rendering

aiwiki.mdln.co is statically generated by Quartz from the same markdown Claude reads, then served from Cloudflare Pages on every push to main.

  • Raw transcripts and Salesforce diffs are emitted as browsable pages (so backlinks work) but their body text is excluded from the search index — keeps static/contentIndex.json under Cloudflare’s 25 MiB per-file cap.
  • Custom OG images are intentionally off — nobody’s sharing URLs to LinkedIn.

Sync

scripts/sync.sh is a thin wrapper:

  1. git pull --rebase to get the latest wiki.
  2. git add logs/<slug>.md && git commit && git push to push the caller’s query log.

It never stages files outside that one log path, so a contributor can’t accidentally push a wiki/ edit even if they made one.

Questions?

Ping Armaan in Slack or open an issue.

Backlinks