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 18, 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,489 terms in the glossary

481 live typed edges

929 edges rejected & remembered

How it works

Five stages, from a Claude proposal to a public typed relationship on the term page:

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 18-verb vocabulary with a direction-aware prompt.

▼

Engine gates filter

Vocab check (verb must be one of the 18), 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.

▼

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.

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.

▼

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 18 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.

Through mid-2026 the same evidence-driven process added six more, each from a recurring [vocab-gap] or [verb-too-strong] cluster the existing verbs couldn't state honestly: specializes (a subtype / is-a-kind-of, neither containment nor contract), enforces (an active runtime or analyzer that checks or guarantees a rule), enables (a permissive condition that makes an outcome possible without directly causing it), realizes (a concrete mechanism providing a working version of an abstract protocol or pattern), applies (a technique putting a non-code principle or guideline into practice), and leverages (a feature built on another construct as a working ingredient). Every other [verb-too-strong] rejection turned out to be the LLM mis-picking an existing verb, not a missing one — so each addition had to be earned, and the prompt was tightened the rest of the time. The vocabulary now stands at 18; adding another holds to 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".

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".

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".

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".

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".

enforces

X is an active tool, analyzer, runtime, or config that guarantees or checks Y.

Use this when something programmatically mandates or verifies a rule or constraint.

specializes

A is a more specific kind, subtype, variant, or specialized case of the broader concept B, sharing B's identity while narrowing it.

Many edges express an 'is-a-kind-of' / subtype relationship that reviewers repeatedly reject because it is neither component membership (contains) nor contract realization (implements) nor hard dependency (requires) — there was simply no home for taxonomy/specialization.

enables

A is an enabling condition, permissive setting, or weakening factor that makes B possible or more likely without directly producing it.

Many real edges describe a setting, feature, or condition that opens the door to an outcome — an attack vector, a capability, a risk — without directly causing it or being a hard dependency. This permissive 'makes-possible' relation currently has no home and gets mis-filed as causes (too strong), requires (wrong direction/too strong), or configures.

realizes

A is a concrete tool, engine, mechanism, or technique that provides a working implementation of an abstract protocol, specification, standard, or pattern B, without B being a code-level contract or a taxonomic parent.

Many rejected edges describe a concrete tool or mechanism that provides a working version of an abstract protocol/standard/pattern — e.g. 'swoole realizes ws protocol', 'websockets realize the protocol', 'dataclass uses decorator syntax' — a relationship that is neither a code-contract implements, a subtype specializes, nor an active enforces.

applies

A is a concrete technique, feature, or construct that puts a non-code abstract principle, guideline, methodology, or notation to use without being a subtype of it or a code-contract implementation of it.

Many edges describe a concrete technique or feature putting an abstract principle, guideline, methodology, or notation into practice — e.g. a pattern upholding OCP, skip links satisfying WCAG, dotenv supporting a 12-factor principle. These are neither code-contract implementations nor full realizations of a spec, so they currently get mis-filed under implements/realizes and rejected.

leverages

A is a concrete feature/technique/tool that builds upon or uses another distinct concept, mechanism, or construct B as a working ingredient, without B being a hard dependency, a part of A, a subtype, or an abstraction A fulfils.

Many real edges describe a concrete feature or mechanism that is built on top of another concrete construct — 'X uses Y as an ingredient' — which is stronger than mere co-occurrence but is not a hard dependency, containment, subtype, or abstraction fulfilment. This relationship currently has no home and gets mis-filed under often_seen_in, requires, implements, realizes, or specializes.

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.

Where to go from here

← Back to the glossary About this reference Contribute via AI agent