Skip to content
AletheiaAletheiaAletheia docs

Resource-to-code mapping

Mapping joins a live AWS resource to the infrastructure-as-code that declares it. It is the step that turns an inventory into a control plane.

Management states

Section titled “Management states”

After mapping runs, every resource carries one of five states:

State Meaning
managed_synchronized Exactly one deployment unit’s state manages this resource
unmanaged State coverage exists for this resource’s scope, but no state entry claims it
conflicting More than one deployment unit’s state claims this resource
managed_missing A state entry claims a resource that discovery did not find
unknown No state covers this resource’s scope, so management cannot be determined

unknown is the default, and it is the honest answer before you have designated any state sources.

unmanaged versus unknown

Section titled “unmanaged versus unknown”

This distinction is the one people trip over, and it is deliberate.

  • unmanaged is a finding. Aletheia can read the state for that scope, it looked, and this resource is not in it. Something created this resource outside your infrastructure code.
  • unknown is an absence of evidence. No state source covers that scope, so nothing can be concluded. This is not a finding about your infrastructure; it is a gap in what Aletheia has been given.

Reporting unknown as unmanaged would manufacture alarming findings out of missing configuration. Adding the state source turns unknown into a real answer.

conflicting

Section titled “conflicting”

Two deployment units claiming the same resource is usually a real problem: two Terraform roots that can both modify the same infrastructure, where whichever runs last wins. Occasionally it is a mapping mistake, in which case correct it.

managed_missing

Section titled “managed_missing”

State claims a resource that discovery did not find. Common causes:

  • The resource is of a type Aletheia does not support — expected, not a fault.
  • The resource lives in a region or account not covered by a connection.
  • The resource was deleted outside Terraform, and state has not caught up.

Confidence

Section titled “Confidence”

Every match carries one of four tiers, strongest first:

Tier What it rests on
confirmed An identifier both sides agree on exactly
high Strong corroborating signals
medium Plausible signals with some ambiguity
low Weak signals — treat as a proposal

Confidence is shown, not hidden. A low-confidence match is presented as something Aletheia thinks is probably true, not as a fact.

Evidence

Section titled “Evidence”

Every mapping records why it was made: which state source, which resource address within it, and which identifier matched. You can open the evidence for any mapping and judge it yourself rather than taking the conclusion on trust.

This matters because mapping is inference. Inference that cannot be inspected is indistinguishable from a guess.

Correcting a mapping

Section titled “Correcting a mapping”

When Aletheia gets one wrong, you can override it by hand. Corrections:

  • Persist across rescans. The next scan will not silently revert your correction.
  • Are their own audit trail. A correction records who made it and when, so the history of “we decided this actually belongs to that module” survives.

Where to go next

Section titled “Where to go next”