api

the map, as data

JSON over CORS. No credential, no rate limit, no key.OpenAPI 3.1 describes every path below;JSON Schema describes what they return.Why it says what it says is a separate page.

every surface

The whole map first, then the descriptor to start a client from, then everything else.

/.well-known/site-map.jsoncanonical

The whole artifact: entities with their authored and derived halves, asserted couplings, weak ones, coverage gaps, and the vocabulary needed to read them.

curl -s https://xn--w6j.day/.well-known/site-map.json

/.well-known/0day.json

The service descriptor: what this is, when it was collected, which halves are authored versus derived, and where every other surface lives. Small on purpose — an arriving agent needs where to go, not the whole map.

curl -s https://xn--w6j.day/.well-known/0day.json

/schema/v1/site-map.json

The contract as JSON Schema, generated from the same definition the generator validates against.

curl -s https://xn--w6j.day/schema/v1/site-map.json

/graph.json

Byte-identical alias of the artifact. It predates the well-known path and is kept so nothing already fetching it breaks.

curl -s https://xn--w6j.day/graph.json

/projects.json

The public manifest view: authored project records with their derived dependencies folded in.

curl -s https://xn--w6j.day/projects.json

/openapi.json

The HTTP surface as OpenAPI 3.1, generated from this same list and the same Zod contract. What paths exist and what they return, for a consumer that has not read the site.

curl -s https://xn--w6j.day/openapi.json

/schema/v1/mache-topology.json

A mache topology schema for this artifact, generated from the same Zod definition — mount the map as a navigable tree instead of parsing it. Published beside the data so a consumer gets both the facts and a way to walk them.

curl -s https://xn--w6j.day/schema/v1/mache-topology.json

/projects/<slug>.json

One entity on its own, carrying the resolution rules its edges cite and the coordinates it publishes — enough to read and reproduce every claim in it without fetching the whole artifact. Granularity stops here; there is no per-edge endpoint.

curl -s https://xn--w6j.day/projects/assay.json

what is in it

entities: One per repository, splitting authored — a maintainer's statements, which should not be second-guessed from activity signals — from derived, which was read from a manifest.
edges: Established couplings, each carrying its kind, the file it was read from, resolved_by (the rule that identified its target) and matched (the coordinate it was found under, so the resolution can be reproduced).
weak_edges: Couplings a source declares whose target could only be matched by name. Kept, because deleting a real coupling would be its own distortion, but never folded into edges. If you want only what is established, read edges and ignore this.
unresolved: Declared couplings that resolve to no repository at all, with the reason. A resolution gap is recorded rather than dropped, so the document never looks more resolved than it is. Note the scope: this covers declarations the collector PARSED and could not resolve. A coupling declared in a format it has no parser for is never attempted, so it is absent rather than recorded — see sources_read for which formats were actually read, and entities[].unexamined for root configs seen but not parsed.
ownership: Every coordinate the ecosystem declares publishing — module path, crate, package, image, MCP server — and which repository declares it. This is the index every exact edge was resolved against, so a reader can reproduce a resolution rather than take it on trust. A coordinate two repositories claim carries contested rather than being reduced to one.

a worked example

Who depends on a given repository, and in what way:

curl -s https://xn--w6j.day/.well-known/site-map.json \
  | jq '.entities[] | select(.id == "ley-line-open") | .derived.depended_on_by'

This returns only the dependencies that were established outright. A name that merely looked like a match never reaches an answer someone might use to decide what a release breaks. What was left out is kept beside it, with the reason, in weak_edges and unresolved.

versioning

schema_version: Currently 1. Increments only when a field is removed or its meaning changes — adding one never breaks a pinned consumer.
$schema: Every document names its own schema, so nothing has to be looked up out of band.
collected_at: When the sources were read. The map is a point-in-time reading, not a live query.

run it against your own repositories

Everything above describes one deployment. The code that produces it is published, so the answer to "could I have this for my repositories" is yes, without asking anyone.

@agentic-research/depgraph-core: The contract, the derivation and the gate. One dependency, no filesystem and no network — it runs in workerd or a browser as readily as in Node.
@agentic-research/depgraph-collect: Reading repositories into a sources lock: manifests, lockfiles and workflows. Node-only, and uses no credential.
agentic-research/0day-api: The source both are published from, Apache-2.0, including the check that proves a change still reproduces this site's data byte for byte.

npm i @agentic-research/depgraph-core @agentic-research/depgraph-collect

Two packages rather than one, for a reason. The build re-runs the whole map from the same sources and fails on any difference — which only proves something if working it out cannot reach the network. So the half that does the working out has one dependency and touches nothing else, and the half that reads repositories is kept apart from it. That half uses no login either: if what the map says depended on who ran it, nobody else could reproduce it.

No version is quoted here. A number written into a page is a claim that rots the next time one is published, and the registry already answers the question authoritatively.