how this map decides what it says

what is written by hand, and what is read from the code

Everything here is one or the other, and the published data says which —authored for a person's statement, derived for something read out of the code. Which side a field falls on is decided by one question anyone can check: does a file somewhere already say it?

A project's status, the question it is investigating, what it contributes and how itrelates to the others are written by hand. Nothing infers maturity from stars, commit frequency, or whether a release happened recently. Status is a statement someone makes, not a measurement.

The dependency graph is the opposite. None of it is written here. It is read from each repository's own manifests and regenerated rather than maintained, because a hand-written graph is wrong the first time a dependency changes and nothing catches it.

what gets read

110 manifests across 8 public repositories:

Cargo.toml

dependencies, including git pins and platform-gated tables

go.mod

direct requirements

package.json

dependencies across every workspace package

server.json

MCP identity, published artifacts, declared runtime dependencies, and the executable a server launches itself with

cluster.toml

bundles, the wires between them, and pinned inputs

cluster.lock.toml

resolved image identifiers, versions and digests

Taskfile.yml

the repositories a release task publishes assets to

.<tool>-version

a bare version string pinning an external tool

.github/workflows/*.yml

cross-repository dispatch: the events a workflow sends, and the ones it declares accepting

That list is exhaustive, and it is the honest boundary of everything else on this page. A coupling declared in any other format is not merely unresolved — it is never read, so it is absent rather than recorded. A tool that declares its wiring in its own config file is invisible here. Where the collector saw such a file, it now records it: the dependency ledger'sunexamined note names the repository and the file, so the gap is stated where it applies rather than assumed everywhere. That record covers formats someone declared to be coupling-bearing — a format nobody has named is still invisible, and outside this list absence remains unexamined rather than empty.

Names are resolved to repositories using an index built from what those repositories declare they publish — crate names, Go module paths, npm package names, image identifiers, MCP server names, executable names. There is no hand-written table mapping one to the other, so there is nothing to fall out of date.

when a dependency counts as real

A coupling is only stated as fact when the source named the repository outright — a git URL, a Go module path, a github:// reference — or named an identifier that repository declares publishing. 28 couplings clear that bar.

6 do not. Something is declared, but its target could be identified only by matching a name against a convention, which is true today and can go quietly wrong on a rename. Those are kept — deleting a real coupling would be its own distortion — but they are held separately in weak_edges, listed on the project pages that involve them, and never folded into a dependency statement. A further 4 resolve to no repository at all and are recorded with the reason, so a resolution gap reads as a finding rather than vanishing into a graph that merely looks resolved.

Two couplings are named and deliberately not derived: a shared data-at-rest schema, and derivation lineage carried by content hashes. Both are real, and both are the kind a handshake cannot fix — a stored database outlives the connection that produced it. No machine-readable source declares them today, and emitting them anyway would mean hand-writing a fact. They become derivable when a producer declares them.

what stops it rotting

Two gates, split by what they need. One re-derives the graph from the committed sources on every change and fails on any difference, so a hand-edited graph cannot survive review. The other re-reads the repositories on a schedule and fails when the committed copy has fallen behind them.

The first gate is itself tested: a suite breaks the real graph 19 different ways — an edge dropped, invented, reversed, a version left stale, a commit altered, distinct couplings flattened into one, a coverage gap quietly deleted — and requires every one to be rejected. A check that only ever passes proves nothing.

Neither gate uses a credential. Repository visibility is established by asking GitHub, and it fails closed: 0 of the 8 repositories named here are not public, are never read, and appear only as an endpoint carrying a name and a coupling kind — no version, no commit, no file path.

the same thing, as data

Everything above is published as data, including the boundary itself, so a consumer can tell an authored status from a derived dependency without reading this page. That is documented separately, because buried here it reads as a footnote to the methodology rather than as an interface someone can use: the API.

For a machine, the entry point is /.well-known/0day.json — a small document naming every surface, when the map was collected, and the same authored/derived boundary this page argues for. It is deliberately not the map: an agent orienting needs to know where to go, not to be handed everything at once.