The lexicon
argued, never built Roughly 7,000 words across two versions describe a package that is “required by every Issues-FS repository” and one half of a stated two-dependency invariant. It has no repository, no PyPI entry, and it appears in no pyproject.toml anywhere. It is the most theorised and least built idea in the corpus, and it is published here for exactly that reason.
Read every claim on this page in the conditional. The design is presented as written — in the present tense, as designs are — and none of it is implemented. This site publishes it because the idea is a good one and because six months of silence around a load-bearing architectural claim is itself information. Nothing here is a dependency you can install; the READMEs that describe it as one are wrong.
The idea
The interesting move is what the lexicon is defined against. It is explicitly not a schema registry, and explicitly not an authority on definitions. It is:
The most well-connected graph in the ecosystem — a set of anchor nodes that any scope may link to, in order to raise the confidence and interoperability of its own nodes.
That follows directly from C1. If a node has no inherent meaning and confidence in its meaning is proportional to how richly it connects to context, then a shared, densely connected set of anchor nodes is not a naming authority — it is a supply of context. Two teams whose nodes both link to the same anchor have a measurable relationship between their graphs, without either having adopted the other's schema.
The distinction matters practically. A schema registry says “your severity field must be one of these five values.” A lexicon says “here is a well-connected node called severity: high; link to it if you mean the same thing, and your graph becomes comparable with everybody else who did.” The first constrains; the second offers.
The two-dependency invariant
The architecture states the claim in its strongest form. Every repository in the ecosystem depends on exactly two things:
| Dependency | What it supplies | State |
|---|---|---|
osbot-utils | How we build — the type-safety layer and the shared primitives | real 3.75.0, a declared dependency across the ecosystem |
issues-fs-lexicon | What we can link to — the anchor graph | does not exist |
It is a genuinely elegant framing: one dependency for construction, one for meaning, and nothing else shared. Half of it shipped.
What is actually there instead
The gap the lexicon was meant to fill is real, and something does partly fill it today — just not the thing that was designed.
| The lexicon would supply | What exists today |
|---|---|
| Shared anchor nodes that any graph may link to | Nothing. Every graph's nodes are local to it, and no cross-graph edge exists anywhere in the ecosystem |
| A shared vocabulary of types | Partly: issues-fs types init writes the same 12 node types and 10 link types into every graph. That is a shared vocabulary by convention and duplication, not by reference — and it already diverges, since one live graph has added release, user-story and cli |
| Measurable interoperability between graphs | Nothing measures it. There are four live graphs and no tooling that reads more than one |
The duplication story is the honest current answer, and it works at four graphs the way copied config always works at small numbers: fine, until the copies drift. One has already drifted.
Two versions, one of them unmarked
| Version | Words | Status |
|---|---|---|
| Lexicon architecture v2 | 4,485 | v2.0, 5 February 2026. The version this page describes. Names C1 as a prerequisite |
| Lexicon architecture v1 | 2,509 | Superseded. It sits in a directory named already-legacy/ and carries no supersession marker in the file itself — so a reader who arrives at the file directly, as an agent fetching a path would, has nothing telling them it is superseded. Not published here. Marking it at source is open request N6 |
Is it still the plan?
This is open question Q1 and the site publishes it unresolved, because the evidence points both ways and it is not the site's call.
For: the argument is coherent, it follows from the foundational document rather than being bolted on, and nothing has replaced it. The problem it addresses — graphs that cannot be compared — is still unsolved and gets worse with every new graph.
Against: six months have passed with four live graphs and no cross-graph edges, so nothing has yet needed it. Copied type configuration has proved good enough at this scale. And a hard dependency in every repository is a large commitment to make for a benefit that appears only when several independent graphs are being read together — which nobody is doing yet.
What would settle it either way is small: one cross-graph edge. A single node in one live graph linking to a node in another would make the requirement concrete, and would immediately expose whether an anchor graph is needed or whether a URL is enough.
For an agent
There is no lexicon package. Any document describing issues-fs-lexicon as a required dependency, or referring to a two-dependency invariant as though both halves exist, is describing design rather than reality — do not attempt to install it and do not add it to a dependency list. The shared vocabulary that does exist is the default type registry written by issues-fs types init, duplicated into each graph rather than referenced, and already divergent across live graphs: read .issues/config/node-types.json in the graph you are working with rather than assuming the defaults. Whether the lexicon remains the plan is an open question, published unresolved.