The loop
Documentation that keeps itself honest
Every other architecture map is a snapshot someone took once. This one is a loop: read the source of truth, propose the difference, wait for you, and admit when it has aged.
System Architecture
Your architecture diagram is wrong. This one says so.
A repository is not your whole system. SourceAnt records the services, components, queues and datastores that work together. You can see where changes are pushing the architecture and decide whether to keep that direction. Your agents can understand the connections before they edit code.
Self-host free · Bring your own tools
System architecture
- 01
It reads what your repositories already publish
package.json, composer.json, go.mod, requirements.txt, and pyproject.toml, fetched through the GitHub API. Nothing is cloned and nothing is executed.
- 02
It proposes, and only where it can point at a file
A dependency is proposed where one repository declares a name another publishes itself under. Every proposal names the manifest it came from, so you can check it by opening one file.
- 03
You approve it
Proposals arrive pending and stay pending. Nothing here approves itself. Send persist: false first if you want to see the proposal without touching the graph at all.
- 04
It tells you when it has stopped being true
A part believed out of date is marked stale rather than deleted. The record says it is unsure instead of going quietly wrong, which is the failure every architecture diagram has.
What it reads
Five files you already keep at the root
No agent walks your tree and no model guesses. The inference is deterministic, and a manifest that will not parse proposes nothing rather than failing the whole system.
-
package.jsonnpm · dependencies, devDependencies, peerDependencies, optionalDependencies -
composer.jsonComposer · require and require-dev, with PHP platform requirements skipped -
go.modGo · the module line and every require, block form or single -
requirements.txtPyPI · requirement lines, with options and includes skipped -
pyproject.tomlPyPI · project dependencies, plus entry points as extension groups
Names are compared by the rules of the ecosystem that issued them. On PyPI, friendly.bard and Friendly_Bard are one project, not two. A naive string match gets that wrong and quietly loses the edge.
POST /api/topology/infer
{
"assets": [
{ "entity_id": "billing-api",
"repository": "acme/billing-api" },
{ "entity_id": "shared-auth",
"repository": "acme/shared-auth" }
],
"persist": false
} persist: false returns the proposal and leaves the graph exactly as it was. Nothing to undo.
Evidence, not assertion
Every edge shows its work
A relationship you cannot check is a rumour. Each one carries where it came from, how sure it is, and whether anyone has signed it off.
billing-api depends_on shared-auth pending
- Status
- proposed, approved, or retired. Where the part stands, chosen by your team and not by the parser.
- Confidence
- 0 to 1. A part someone declared is 1. An inferred one is lower, and the reason is recorded.
- Stale
- Believed out of date. Kept and flagged rather than deleted, so you can see what aged and decide.
- Evidence
- The file, the manifest, the revision. Plus the exact name that was declared and which ecosystem issued it.
confidence 0.6
A bare name is not proof the dependency resolves to you. A public registry can carry the same name, which is how dependency confusion works, so an unowned name is proposed with lower confidence rather than asserted.
Bounded on purpose
An answer small enough to act on
A traversal returns a subgraph you can inspect or give to a model. It tells you when it had to stop rather than quietly returning half a graph.
| Field | Default | Range |
|---|---|---|
| depth | 2 | 1 to 3 |
| direction | both | outbound, inbound, both |
| minimum_confidence | 0.0 | 0 to 1 |
| include_stale | false | on or off |
| entity_limit | 50 | up to 50 |
| relationship_limit | 100 | up to 100 |
Read the graph directly with /api/topology/search and /api/topology/traverse, or let an agent pull the same subgraph through a context pack over MCP.
Why not a catalog
A catalog is a copy someone typed. This is read from the code.
Developer portals ask a person to register each service and then trust the entry forever. The entry does not rot loudly. It just stops matching the code, and nobody finds out until an incident.
A registered catalog
- Someone types the service in once
- Accuracy depends on who remembered
- Drift is silent
- No record of why an entry is believed
SourceAnt Systems
- Read from the manifests on every pass
- Accuracy carries a number you can filter on
- Drift is marked stale
- Every edge names the file behind it
Yours to take away
Graph snapshots are portable, streamed, and validated on the way in, and an interrupted write is recovered rather than left half applied.
Scoped, and only ever its own scope
Over MCP the scope is the authenticated principal. Over HTTP it is a workspace claim on the token, and a token without one is refused.
Your vocabulary, not ours
A part is whatever your architecture calls a part: a service, a queue, a datastore, a job. SourceAnt does not impose a kind list on you.
Stop redrawing the diagram
Point it at the repositories you already have and read the first proposal in a few minutes. The graph, the endpoints, and the inference are all in the open core.