Concordance

Documentation you already wrote

What your files already know about each other.

Your team writes markdown for the AI. Concordance turns it into a wiki for the humans. Point it at your git repositories and get a site where every word of your business has a page: the note someone wrote, if any, and every passage, in every file, that mentions it.

See the demo Getting started

What it produces

Drag the handle. Left, one file of your repository, exactly as it is. Right, the page Concordance publishes for it — nothing was added to the markdown.

docs/concepts/keyword-page.md  →  example.wiki/concepts/keyword-page
before after
1234567891011121314 
---
type: concept
status: stable
---
# Keyword page

Every word that crosses the publication threshold gets a page,
whether or not anyone wrote a note for it.

## Contents

The note itself, if one exists, then every passage that mentions
the word, grouped by file.

> A keyword page is never empty: the corpus fills it.
Concepts Build pipeline12 Confidence9 Keyword page31 Occurrence27 Publication threshold18 Reference Configuration44 Checks41 Decisions Publication threshold4
⌕ Search the corpus / concepts / keyword-page
Conceptstable

Keyword page

Every word that crosses the publication threshold gets a page, whether or not anyone wrote a note for it.

Contents

The note itself, if one exists, then every occurrence that mentions the word, grouped by file.

  • Written links come from the markdown
  • Mentions come from the index
A keyword page is never empty: the corpus fills it.
—— written link · · · recognised while indexing docs/concepts/keyword-page.md
Properties
TypeConcept
StatusStable
SpaceReference
On this page Contents
Related pages 35
Publication thresholddecision4 Below three occurrences we do not publish a page. Publication thresholdconcept6 Cited · How many pages a build produces. Build pipelineconcept3 Keyword pages are written in the render step. Occurrenceconcept2 Cited · One line, one phrase, one file. Ordered by number of passages. “Cited” marks a link written in the page.
‹ ›

The rail is calculated, not written: the properties come from the file's own header, the related pages and their passage counts come from reading the corpus. Written links and recognised words stay visually distinct, so you always know which of the two you are looking at.

Lint first, then build

Start with the linter: it checks one repository on its own, before any site exists. The build comes next, and reads your repositories exactly as they are — no rewriting, no wikilinks, no frontmatter required, no server to run. 

# 1 — check one repository, before you push. No site needed.
npx @concordance-wiki/concordance lint

# 2 — build the wiki from every source in concordance.yaml
npx @concordance-wiki/concordance build

# or turnkey, with the container image
docker run --rm -v "$PWD:/wiki" concordancewiki/concordance build

How it works

Three steps, and nothing kept between two builds.

  1. Declare your repositories. One concordance.yaml lists the git sources. Nothing else is required — and concordance lint already works on a single repository without it.
  2. Build. Every word people actually use gets a page, every file that mentions it gets a link, office documents and transcripts get a preview.
  3. Publish the folder. dist/ is static: GitHub Pages, GitLab Pages, a bucket, or a file on disk. Search works without a server.

Repositories

The engine lives in one repository. The project's own wiki is built with Concordance from two content repositories and one configuration repository: copy the configuration to start yours. The split is a convenience, not a rule — one repository can hold several kinds of content, and a single kind can be spread across several repositories.

It fits repositories you already have

Nothing to migrate, nothing to rename. Three levels, and you stop wherever it is enough.

Recognised on its own
Markdown, office documents, transcripts and interface contracts are picked up by extension — notes, specifications, glossaries, meeting transcripts, decision records. A first build works on an untouched corpus, and one repository may mix all of them.
Declared once, in the configuration
A type per folder, or a glob when folders are not enough — specs/screens/** becomes screens. Sources, domains, thresholds and formatting live in concordance.yaml, never in your files.
Refined in frontmatter, when you want more
A few keys per note override the rules and declare relations by hand. It is the advanced level, not the entry ticket — a corpus without any frontmatter still builds.
Published under your own name
Concordance is white label: name, logo, accent colour, radius and typefaces come from a theme file, and a stylesheet of your own goes further. The site wears your identity — the visible branding is yours, the licence notices stay where the licence requires them (GPL v3).

Read on

What it does not do

Worth knowing before you install, rather than after.