Somewhere in your wiki there is a page describing a service that was rewritten two quarters ago. Nobody knows which page it is, and nobody will until it burns someone: a new engineer following it step by step, an on-call responder at 3 a.m., or an AI agent reading it and reasoning from it as if it were true.

Galileo exists to find that page before it finds you. Beta access opens today.

Documentation doesn't break, it rots

When code stops working, you hear about it immediately: tests fail, alerts fire, users complain. Documentation has no feedback loop. The wiki grew for years without an owner, two runbooks describe the same incident procedure differently, and the README still explains an auth flow that was replaced last spring. Every page looks equally authoritative, and some of them are lying.

So engineers learn a defensive habit: don't trust the docs, reconstruct the context by hand. From the code, from tickets, from Slack threads, from the one person who was there when the decision was made. Every new engineer repeats this work, and every on-call shift gambles on which runbook is current.

AI agents inherit the same problem and add confidence to it. An agent retrieves whatever is easiest to find, can't tell a fresh claim from a stale one, and will happily reason from a page that stopped being true in March.

What is knowledge health?

Knowledge health is the degree to which what your organization has written down still agrees with what is actually true. Like code health, it's not a feeling. It can be measured: which pages have drifted from the code they describe, which sources contradict each other about the same concept, which knowledge exists only in one person's head.

Most teams have no instrument for this. Content gets indexed, searched, and summarized, but nothing checks whether it's still true. Galileo is that instrument.

How it works: Sources, a knowledge graph, and Findings

Galileo connects to the knowledge Sources your team already uses and processes them through one pipeline:

Sources ──▶ Ingestion ──▶ Knowledge graph ──▶ Findings
(GitHub,     (sync         (Nodes, Edges,      (derived
 Notion...)   lifecycle)    Evidence)           insights)

Three things make this more than an index:

• A connected graph, not a pile of chunks. Galileo extracts concrete Artifacts (a README, a commit, a service) and the Concepts they talk about, and joins them with directed, typed relations. It understands your knowledge as a system, not a search corpus.
• Provenance on every claim. Every node and edge carries Evidence pointing at the exact Source and location it came from. When Galileo says something, you can click through to where it learned it.
• Findings with a lifecycle. A Finding is a derived insight over the graph: this document is stale, these two sources disagree. Each one opens when detected, sustains while the problem persists across syncs, resolves when you fix it, and reopens if the drift comes back. Findings behave like issues, not like search results.

The graph is the platform; the Findings on top of it are the product.

Why we expose conflicts instead of resolving them

There is a growing category of tools that sit between your team's knowledge and your AI tools, and answer questions by retrieving the best available version of the truth. When two sources disagree, they pick a winner using signals like recency and authority, and serve a clean answer.

That's a defensible trade-off for answer quality, but notice what it doesn't do: the conflict is still there. The losing page keeps lying to the next person, or the next agent, that reads it directly.

Galileo makes the opposite trade-off. When two sources disagree, that disagreement is the product: a Finding with both Evidence trails side by side, so your team can decide which claim is right and fix the knowledge base itself. Conflict resolution done silently serves an answer; done in the open, it fixes the knowledge.

What works today (and what doesn't yet)

Galileo is in beta, so here is the honest inventory.

Working today:

• GitHub Connector: a repo becomes a service, its README a document, commits become code_change nodes linked to the person who made them, and root files become code_file nodes. Code-level symbol extraction is still in progress.
• Stale-documentation Findings with the full open / sustain / resolve / reopen lifecycle.
• A browsable, org-scoped knowledge graph where every node and edge shows its Evidence.
• The unglamorous parts: encrypted credentials at rest, multi-tenant isolation, async org data export.

Not yet working, and worth being explicit about: cross-source staleness. Today's detector works within a Source. The version that compares your Notion architecture pages against your GitHub code, and opens a Finding when the code has moved on, is the next item on the roadmap and the most important one. Code is the truth, the doc is the claim, drift is the Finding.

The roadmap: ordering is the commitment

We don't publish dates; we publish order. Everything sequences toward one goal: Findings over cross-source knowledge before any surface expansion.

Next, in order:

1. Notion Connector, because scale-up documentation rots in Notion more than anywhere else.
2. Cross-source staleness, the detector described above. This is the wedge.
3. Linear Connector, so tickets join the graph and Findings get more Evidence to draw on.

Later:

• Conflicting-claims detector: two Sources disagree about the same Concept and Galileo exposes it instead of picking a winner.
• Tribal-knowledge detector: claims that exist only in conversations and people, never in docs.
• An org-scoped MCP server, so agents like Claude Code and Cursor query the graph directly. This is deliberately sequenced after cross-source staleness: when it ships, an agent doesn't just retrieve a doc, it retrieves the doc with its Finding attached ("careful: this page has conflicted with the code since March"). Context that knows its own freshness is the thing a plain retrieval layer can't offer.
• Confluence, Slack, and Datadog Connectors, then enterprise readiness (SSO, compliance).

Beta access and design partners

The beta is free: two connected Sources per organization and unlimited seats. Unlimited seats is a deliberate choice, not a promotion. Knowledge health is worth more the more people can see the Findings, and charging per seat would punish exactly the behavior we want.

We're also opening a small design partner program: three to five teams of 20 to 200 engineers using GitHub plus Notion or Confluence. Design partners get the full product free during beta, a direct line to us, and real influence on connector priorities. In exchange we ask for permission to measure and publish, anonymized if you prefer, two numbers: how long from connecting your Sources to the first stale doc you confirm is real, and how fast Findings get resolved once you can see them. We don't quote borrowed benchmarks, so design partners are how the first real case studies get made.

That page describing the service that was rewritten two quarters ago? Connect the repo and find out which one it is: sign up for the beta. If the design partner program sounds like your team, mention it when you sign up.