Correcting a mapping

Mapping is inference. Inference is sometimes wrong, so every mapping can be overridden by hand.

Making a correction

Open the resource, go to its mapping, and correct it. You can:

• Point it at the right code. The resource is declared by a different state entry than the one Aletheia picked.
• State that it is not managed. Nothing in code declares this resource, whatever the match suggested.

A correction asks for a short reason. It is worth writing: the next person to look at this resource sees the reason rather than re-deriving your conclusion.

Corrections win, permanently

A correction pins the mapping. Later scans and state syncs re-run the matcher, see the pin, and leave it alone.

This is the property that makes correcting worthwhile. If a correction could be silently undone by the next scan, nobody would make one, and the inventory would stay wrong in the same way forever.

The pin holds even when the evidence underneath changes. If the resource’s tags change or its state entry moves, your correction still stands until you change it.

The correction history

Corrections are append-only. Making one does not overwrite the last; it adds an entry. Each entry records who made it, when, what it changed, and the reason.

You can read the full history for any resource. Nothing in the history can be edited or deleted, including by an administrator — the record of what was decided is not something the product lets you rewrite.

Who can correct

Correcting a mapping is a change to what the inventory asserts, so it needs an operator-level permission rather than plain read access. See Roles and permissions.

When you should not correct

If a resource is unknown because no state source covers it, a correction is the wrong tool — it records an opinion where the real fix is designating the state source. Correct a mapping when Aletheia had the evidence and drew the wrong conclusion from it, not when it had no evidence at all.

Likewise, a conflicting resource usually reflects something genuinely wrong in your infrastructure — two roots that can both change it. Correcting the mapping hides the symptom without fixing the cause.

Where to go next

• Resource-to-code mapping for the states and confidence tiers.
• Audit log for where corrections appear alongside other changes.