MeridiansMeridians

Knowledge-quality benchmark

Source path: knowledge-base/knowledge/operations/knowledge-management/01-knowledge-quality-benchmark.md

# Knowledge-quality benchmark

Meridians treats its internal knowledge base as an operational system: it needs a map, boundaries, and
evidence about what will be hard to maintain. The benchmark measures the shape of that system without
pretending to grade whether the prose is true.

## Run it

```bash
npm run knowledge-insights
npm run gen:knowledge-quality
npm run gen:quality-worklog
```

The first command writes a local, gitignored review bundle at `knowledge-base/insights/knowledge/`, using the same
midnight/light theme and one-question-per-chart discipline as `repo-insights`. The second produces
the committed [quality report](../../../generated/KNOWLEDGE_QUALITY.md), its machine-readable JSON
sibling, and a separate generated [Mermaid topology](../../../generated/diagrams/knowledge-topology.md).
It also runs in `npm run gen:all`.

`gen:quality-worklog` turns the separate static-analysis, change-history, documentation-drift, and
knowledge-shape reports into a generated [maintenance queue](../../../generated/QUALITY_WORKLOG.md). It
does not assign a score: an item is promoted only when independent signals overlap, then still requires
inspection against the underlying contract.

## What it measures

- **Tree shape:** topical leaves, branch count, depth, local hubs, and documents left at `knowledge-base/` root.
- **Reader cost:** leaf-size distribution, leaves over the 240-line review threshold, and inbound
  maintained navigation links.
- **Technical maintenance:** source-path anchors on the architecture, governance, operations, and
  conventions branches; use the staleness report to decide whether an anchored claim needs re-reading.
- **Diagram boundaries:** maintained Mermaid sources belong in `knowledge-base/diagrams/`; generated aggregates
  belong in `knowledge-base/generated/diagrams/`. Mermaid inside a knowledge leaf is surfaced as leakage.
- **Trend:** a committed baseline and 90/365-day knowledge-change counts from git history.

## How to use the findings

Treat a finding as a prompt to read the branch, never as an automatic migration instruction. Split a leaf
only when it contains multiple reader questions. Add a small `README.md` or `index.md` when a directory
becomes a branch. Move a diagram into a single-purpose diagram leaf, then regenerate the aggregate. Keep
the docs root as a router rather than a catch-all.

The report intentionally has no composite score. A single number would reward fragmentation and false
links; the individual signals preserve the judgment needed to make the tree more legible.
Open on GitHub

Raw Markdown source