The Logic Graph
How typed relationships between terms in this glossary get curated.
LLM-proposed, gate-filtered, human-reviewed. Every edge earns its place.
What's a typed edge?
Glossaries usually express relationships as flat lists — "related terms" with
no labels on the links. This one doesn't. Every relationship between two terms here
is tagged with a verb from a small vocabulary of twelve, so a
connection isn't just "these two go together" — it's X requires Y, or
X mitigates Y, or X is an alternative to Y.
That shifts what the glossary can do. The reader sees not only adjacent concepts but
why they're adjacent. The structure becomes machine-readable, so downstream
tools (Codex, future agents) can traverse it. And typed relationships fail loudly
when wrong, where untyped lists fail silently — discipline forces clarity.
1,463
terms in the glossary
149
live typed edges
188
edges rejected & remembered
How it works
Five stages, from a Claude proposal to a public typed relationship on the term page:
1
Suggester proposes
For a given term, the engine loads its existing related[] entries
plus its first 10 alphabetical same-category siblings as the candidate set,
then asks Claude to propose typed relationships from the 12-verb vocabulary
with a direction-aware prompt.
▼
2
Engine gates filter
Vocab check (verb must be one of twelve), slug check (both endpoints must exist
in the glossary — no hallucinated terms), self-loop rejection, dedup against
live and pending edges, and institutional-memory check against the rejected log.
▼
3
Scored and capped
Each survivor carries a confidence score from 0 to 1. The engine keeps the
top 8 proposals per term run. Hard caps prevent abuse: 50 LLM proposals per
day, 100 edges max in the pending queue.
✗
Auto-rejected
Failed a gate, or duplicated existing knowledge. Logged with reason. The
suggester won't re-propose anything in this log — this is institutional
memory, and it grows with every rejection.
4
Human review queue
A human reviews each surviving proposal: approve, flip direction, or reject
with reason. Optional second opinion from Claude
(✦ Ask LLM) returns a recommendation,
confidence, and short reasoning — never auto-applied; the human decides.
▼
5
Approved & live
The edge moves to the live graph and appears in the typed
Related Terms section on each endpoint's page. Outgoing edges read
with the verb's forward label, incoming edges with the inverse — so the
relationship reads naturally from either side.
The pipeline refuses to auto-approve anything. Every edge that reaches the public
side has been seen by a human. Every edge that doesn't reach the public
side is logged so it won't be re-proposed. The rejected log is, in effect, a record
of what's not a relationship — equally valuable, equally permanent.
The twelve verbs
The vocabulary is intentionally small. Seven verbs covered the original launch;
three more were added in May 2026 when rejection-pattern data showed clear gaps
— the LLM kept reaching for mitigates when the relationship was
really analytical (a metric flags a smell, not prevents it), or for
contains when one term was the implementation of another. Those three
were implements, configures, detects.
Two more followed later in May 2026, again driven by the rejected log rather than
convenience. Edges tagged [vocab-gap] clustered around two relationships
none of the existing verbs could state honestly: a metric quantifying a
property of its subject (an evaluation score, not a flag — distinct from
detects), and one term being an input feeding another's
computation (not a runtime dependency, not membership). Those gaps became
measures and feeds. Every other [verb-too-strong]
rejection turned out to be the LLM mis-picking an existing verb, not a missing one —
so the vocabulary grew by exactly two, and the prompt was tightened instead.
Adding a thirteenth requires the same standard: evidence of a recurring gap in the
rejected log, not just plausibility.
causes
X directly produces, triggers, or leads to Y.
A directly produces B. Asymmetric. Inverse reads as "caused by".
requires
X cannot function or be understood without Y in place.
A depends on B to function or to be understood. Hard dependency. Inverse: "required by".
contains
Y is a component, step, or sub-concept of X.
A includes B as a component or subsystem. Inverse: "part of".
alternative_to
X and Y address the same problem via different approaches.
A and B solve the same problem with different trade-offs. Symmetric.
precedes
X happens, runs, or is learned before Y in a typical flow.
A historically came before B, or must happen first in a sequence. Inverse: "follows".
mitigates
X reduces, prevents, or compensates for the impact of Y. Use for protective controls, not for analytical tools (use 'detects') or implementations (use 'implements').
A reduces the risk, impact, or likelihood of B. Protective control only — for analytical detection use detects. Inverse: "mitigated by".
often_seen_in
X commonly appears in the practical context of Y.
A and B commonly appear together in real systems. Loose contextual association.
implements
X is a concrete realization or implementation of Y (a concept, standard, interface, or abstraction).
A is a concrete realization of B (a concept, standard, or interface). Inverse: "implemented by". Added May 2026.
configures
X provides settings, directives, or parameters that control Y's behavior. Use for soft configuration relationships, not for hard architectural dependencies (use 'requires').
A provides settings or directives that control B's behavior. Soft relationship — defaults exist if absent. Inverse: "configured by". Added May 2026.
detects
X is an analytical tool, rule, or metric that identifies, measures, or flags occurrences of Y. Use for tools-of-analysis, not for protective controls (use 'mitigates').
A is an analytical tool, rule, or metric that identifies or flags B. Detection is not prevention. Inverse: "detected by". Added May 2026.
measures
X is a metric or evaluation that quantifies a property of Y. Use when X produces a value or score about Y, not merely flagging occurrences (use 'detects') or reducing risk (use 'mitigates').
A is a metric or evaluation that quantifies a property of B — it produces a value or score, where detects merely flags. Inverse: "measured by". Added May 2026.
feeds
X is an input or component consumed by Y's computation or process. Use for input→aggregate relationships, not runtime dependencies (use 'requires') or membership (use 'contains').
A is an input or component consumed by B's computation or process — not a runtime dependency (requires) nor membership (contains). Inverse: "fed by". Added May 2026.
Why bother
Most glossaries are read once and forgotten. This one is built to be read by humans
and by other tools — the codebase, search agents, future Claude tooling.
Typed edges are the substrate that lets a glossary become something more than a
lookup table: a navigable knowledge graph where relationships are explicit, falsifiable,
and inheritable.
The curation pipeline above is slow on purpose. Auto-approving LLM proposals would
let the graph grow fast and accumulate quiet errors. Putting a human in the loop on
every edge — and giving the human a second-opinion LLM to argue with — keeps the
graph small but trustworthy. At small N, that matters more than scale.
As the graph grows, patterns emerge. Overused verbs flag underspecified concepts.
Underconnected categories flag gaps in coverage. Contradiction sweeps catch
mutually-incompatible edges. None of that is possible with a flat related[]
list — but all of it becomes routine once the relationships are typed.