> ## Documentation Index
> Fetch the complete documentation index at: https://docs.riftmap.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# What Riftmap detects

> The dependency coupling Riftmap detects today — package manifests, container images, Terraform modules and CI workflows across eight ecosystems — what it deliberately does not detect yet, and why a correctly scanned org can still produce a near-empty dependency graph.

Riftmap answers one question: *if I change repo X, what else breaks?* It answers it by reading what your repositories **declare** — manifests, lockfiles, Dockerfiles, Terraform sources, CI workflow references — and resolving those declarations to other repositories in the same org.

That approach is deterministic and has no per-repo configuration, which is the point. It also has a definite edge, and this page is where that edge is written down.

## What we detect

| Coupling                | Read from                                          | Examples                                        |
| ----------------------- | -------------------------------------------------- | ----------------------------------------------- |
| **npm packages**        | `package.json`, workspaces                         | internal scoped packages, `workspace:` siblings |
| **Python requirements** | `requirements*.txt`, `pyproject.toml`, Poetry, PDM | private-index packages, `git+` requirements     |
| **Go modules**          | `go.mod`                                           | `require` directives, including sub-packages    |
| **Container images**    | `Dockerfile`, `docker-compose.yml`                 | `FROM` base images, `COPY --from` stages        |
| **Terraform modules**   | `*.tf`, module blocks                              | `git::https://…` and registry sources           |
| **Helm charts**         | `Chart.yaml`                                       | chart dependencies                              |
| **CI workflows**        | GitHub Actions, GitLab CI                          | reusable workflows, `uses:` actions, `include:` |
| **Raw git URLs**        | anywhere in a scanned file                         | clone URLs that name an in-org repo             |

Riftmap also detects what each repo **produces** — Docker images, npm packages, Python distributions, Helm charts, Terraform modules — and matches producers to consumers, so an edge can exist even when the two repos never name each other directly.

## What we do not detect yet

**Runtime coupling.** A service that calls another service over HTTP declares nothing about it in any manifest. If your repos are named `billing-api`, `zoho-client`, `orders-client`, most of your real architecture is service-to-service HTTP — and Riftmap cannot currently see any of it. This is the single largest gap, and the one most likely to explain a near-empty graph.

**Contract-level coupling.** Shared OpenAPI specs, protobuf definitions and GraphQL schemas describe exactly the dependencies that runtime coupling creates. Parsing them is the planned answer to the gap above.

**Shared infrastructure.** Two services on the same database, queue or bucket are coupled in practice and identical in every manifest.

**Monorepo-internal imports.** Within a single repository, Riftmap maps what that repo depends on — not how its internal packages depend on each other.

**Vendored and copy-pasted code.** Code duplicated rather than depended on leaves no declaration behind.

## Why your graph might look empty

A scan can be completely correct and still produce very few edges. The usual cause is not a bug and not a misconfiguration:

* **You don't publish internal packages.** If nothing in your org depends on anything else in your org *by name*, there is no manifest-level edge to find. Orgs that build many standalone services and share nothing through a package registry legitimately have almost no packaging coupling.
* **Your coupling is runtime, not packaging.** See above. This is very common for services organisations, and it is our gap, not yours.
* **The scan didn't see everything.** Check the scan on the Scans page: `failed_repos > 0` means some repos could not be processed, and a repository-limit banner means some were skipped by your plan.

When a graph is mostly unconnected repositories, Riftmap now says so directly rather than rendering a field of dots without explanation, and hides the unconnected repos by default so the real edges are visible. Nothing is deleted — the count is stated and one click brings them back.

A low resolution rate is **not** in itself a problem. Most declarations in any real repository point at third-party packages (`react`, `fastapi`, `alpine`), and those are supposed to stay unresolved. The only meaningful question is whether an unresolved reference names a repo in your own org.

## Tell us what we're missing

If your repositories depend on each other in a way this page doesn't cover, that is the most useful thing you can send us — it is how coverage gets prioritised. Email [hello@riftmap.dev](mailto:hello@riftmap.dev) and describe the coupling.