Intelligence Service

The company knowledge layer — claims backed by quotes from conversations, notes, and meetings, a map of people and things, and the patterns that only show up across projects.

Intelligence reads what happened in workspace and turns it into claims the company can be asked about: who knows about a thing, what contradicts what, where the same work is being done twice, what was decided and then quietly reversed.

Nothing here is a source of truth. Every Insight: One claim the knowledge layer holds: a fact, decision, open question, or journal entry, derived from conversations and answerable across projects. It is never a source of truth — every insight points back at the evidence it came from. is worked out from something else, and every one carries Citation: A span of source text an insight rests on, verified twice: the quote must still exist where it claims to, and it must actually support the claim. A quote that exists but does not support becomes context; a claim with no supporting citation is withdrawn. pointing back at the turn, note, or spoken line it came from. If this database were deleted we would lose the conclusions, not the records.

Domain: Services
Kind: Go HTTP service
Lifecycle: Active
flowctl project: None
Stacks: Runs on its own
Source: services/intelligence

Run it locally

Fake models, no credentials, and how to point it at a real provider.

Architecture

The pipeline, the queue, the domains, and how a claim earns trust.

Projects

Which parts of a task count as knowledge, when, and whose words they are.

Job kinds

Every queue kind, which worker runs it, and how work moves from one to the next.

API

Search, claims and their lifecycle, signals, the graph, and the company model.

Company model

Identity, strategy, and dated operating facts the insight harness compiles into.

Operations

Four releases, scheduled work, spend caps, and what a reindex costs.

Knowledge belongs to the company

A project says where a claim came from. It does not say who may read it (ADR 0025). What divides the knowledge base up is Practice: The area of expertise a claim belongs to: marketing, engineering, design, construction. Knowledge is company-scoped, so practice rather than project is what partitions the corpus. — marketing, software engineering, design, construction — because that is how expertise actually divides.

A project can stop contributing. What was already worked out from it is not deleted, because evidence from other projects may support the same claim.

Everything written in workspace is evaluated: the project write-up, decisions, saved outputs, conversations, evidence, and the facts a platform admin recorded. The only skips are a scratchpad, a project or record that opted out, and a project under legal hold — none of which a Company fact: A statement about the business that a platform admin has decided is settled — a legal entity name, what a product is, which market the company sells into. It is a record in workspace's fact domain, written as markdown or uploaded as a file, readable by anyone and writable only by a platform admin. Intelligence derives claims from it the ordinary way and then confirms them instead of queueing them for review, and those claims go into every project's context pack. Distinct from an insight whose kind happens to be `fact`, which is any claim the pipeline extracted from a conversation and which still goes to a reviewer. can be.

A project's tasks are the exception. Only the part of a task that states something settled counts, and only while it is settled; an open task's own text never does. Projects has the rules.

Evidence works differently. A citation is a pointer into workspace, and showing the quoted text requires the reader to have access to the thing it was quoted from. The review app opens that record next to the claim when the caller is allowed to see it. So search returns claims to everyone and quotes only to the people allowed to see them.

A note attached to no project is the one case where anyone can see the quote. That is the point of ADR 0028: if everyone can read the claim, everyone has to be able to open the source it came from.

From what was said to a claim

The cheapest check runs first. At thousands of conversations a day, that ordering is what makes this affordable at all. The same path runs for an agent conversation, a written note, a Zoom meeting, a Slack thread, and an uploaded document. Only the first filter differs.

Diagram. Text representation: flowchart LR T[turn, note, or utterance] --> D[debounce] D --> O[observe] O --> G{cheap gates} G -->|too short, seen before,<br/>project opted out| X[stop] G -->|worth it| E[extract] E --> V[verify spans] V --> N[score entailment] N --> R{route} R -->|corroborated| P[publish] R -->|needs a person| C[candidate] R -->|ungrounded| J[reject]

Diagram source

flowchart LR
  T[turn, note, or utterance] --> D[debounce]
  D --> O[observe]
  O --> G{cheap gates}
  G -->|too short, seen before,<br/>project opted out| X[stop]
  G -->|worth it| E[extract]
  E --> V[verify spans]
  V --> N[score entailment]
  N --> R{route}
  R -->|corroborated| P[publish]
  R -->|needs a person| C[candidate]
  R -->|ungrounded| J[reject]

Most conversations stop at the first filters. That is the design working, not coverage being lost. A model is only asked about text that is likely to contain something worth keeping.

What it does not do

Not event sourcing. Claims are rows, updated in place. The outbox tells other services what changed.
Not a second copy of workspace. The text of a turn is fetched through the Derivation surface: The internal routes intelligence reads conversation text through, authenticated by a service token and a named principal. Evidence stays in workspace and is fetched per request rather than copied, so a redaction takes effect everywhere at once. each time it is needed, so a deletion takes effect everywhere at once.
Not something anything depends on. Workspace degrades when this service is down, on purpose.

Canonical service README: services/intelligence/README.md.