every resource in your cloud — and how they connect.

A console shows you one account at a time. A bill tells you what it cost, in line items named after services rather than after anything you can point at. Between them you can eventually reconstruct what is running — that reconstruction is a week of somebody's time, it is out of date when it lands, and it has to be redone for the next account.

Listing the resources is the easy half. The work is the edges: which subnet that instance sits in, which role that function assumes, which account trusts which. disco resolves those after the walk and stores them as typed relationships, so the estate arrives as a graph you can follow rather than a pile of exports you have to join by hand.

graph blast walks outward from any resource and groups the result by distance ring. graph path gives the shortest path between any two. Edges are typed, not inferred — 11 kinds including attached-to, routes-to, assumes, and bounded-by.

Partial-id lookup means an id pasted straight out of a ticket resolves, and iam principals auto-expand in both directions, because a principal mostly receives edges rather than emitting them.

Every scan is recorded. diff reports what appeared and what went stale between any two of them, and history reads one resource's version chain forward.

"what appeared" is a time query, not a diff you eyeball: --discovered-since and --discovered-before bound first-seen time into a half-open interval, so last week's new resources are a filter on the inventory itself.

Resources the cloud creates and owns are marked as such, so the inventory separates what your team put there from what the provider did — and a count of your estate stays a count of your estate.

graph complete --orphans-only surfaces the resources with no edges pointing at them: unattached ebs volumes, key pairs no instance uses, iam principals with nothing attached.

tag-coverage reports the per-key coverage rate, and keys at zero percent still appear — an absent tag is the signal, so dropping it from the report would hide exactly the thing you need.

A scan stores the resource, not a headline about it — identity, location, lifecycle, tags, and the provider's own attributes. So the record answers questions asked after the fact: what this security group allowed in june, which accounts had public buckets then, when that role first appeared. history reads one resource's versions forward and diff compares any two scans, and both read the state that was actually stored rather than reconstruct it.

That makes the inventory itself the evidence. An export is a record with timestamps and a version chain behind every row, which is a different artifact from a screenshot of a console taken the week someone asked. Nothing has to be staged for the review, because nothing was waiting to be collected.

Service quotas can ride along too — always on azure, opt-in on aws, and planned for gcp — so a raised limit shows up in the same history as everything else. Separately, disco keeps an append-only, hash-chained log of what was done in disco — who connected an account, who exported, who changed a role.