Applications, environments and ownership
A flat list of resources is hard to reason about. Applications, environments, and teams are how you impose the structure your organization already thinks in.
The three groupings
Section titled “The three groupings”Applications are deployable units. An application typically spans accounts and environments — one application might own resources in production and staging, in two regions, across two accounts.
Environments are deployment stages: production, staging, whatever you run. An AWS account can carry a default environment, which seeds the environment for resources discovered in it. That default is a starting point, not a constraint — individual resources can differ.
Teams are groups of people. They express accountability: which humans to ask about this application.
Memberships
Section titled “Memberships”The link between a resource and an application is a membership. It arrives one of two ways:
- Declared — someone said so explicitly.
- Inferred — an inference rule proposed it from the resource’s tags.
An inferred membership stays visibly marked as inferred until someone confirms it. This is deliberate: the difference between “we know this” and “we guessed this” is exactly the information that gets lost when a system quietly promotes its guesses to facts.
You can confirm an inferred membership, or reject it.
Inference rules
Section titled “Inference rules”An inference rule maps resource tags to an application. If your organization
already tags resources with something like app or service, a rule turns that
existing convention into structure without anyone re-entering it.
Rules can be previewed before saving. The preview shows what the rule would match against your current inventory, so you can see that a rule is too broad before it proposes a few hundred memberships.
Ownership issues
Section titled “Ownership issues”Where ownership is ambiguous — a resource matched by two rules, a resource nothing claims — Aletheia surfaces it rather than picking silently. Ownership events record how a resource’s ownership changed over time.
Why this matters beyond tidiness
Section titled “Why this matters beyond tidiness”Ownership is what makes the rest of the product actionable. A change in the timeline is interesting; a change to a resource owned by a named team, in production, is something someone can act on.
Where to go next
Section titled “Where to go next”- Explore your infrastructure for the other surfaces.
- Concepts and glossary for precise definitions.