Skip to content
AletheiaAletheiaAletheia docs

Plans and executions

Once your pipeline is sending plans and executions, they become two surfaces: what a change intended, and what actually ran.

Plans

Section titled “Plans”

A plan (/changes/plans) is terraform show -json output, parsed into per-resource changes.

Each plan carries:

  • Counts — how many resources to add, change, destroy, or replace.
  • A resource change list — every affected address, its action, and the before and after values.
  • Replace reasons — when Terraform plans to replace rather than update something, which attribute forced it. This is the field people most often want and most often cannot find in CI logs.
  • A summary — generated from the parsed plan by fixed rules, not by a model. The same plan always produces the same summary.

Sensitive values

Section titled “Sensitive values”

Values Terraform marks sensitive are redacted before they are stored. They are not in the change rows and not in the retained artifact.

Values that are not yet known at plan time show as (known after apply), which is what Terraform itself reports.

Matching to your inventory

Section titled “Matching to your inventory”

Aletheia tries to attach each planned change to the live resource it affects, using the code mapping first, then the native identifier, then the ARN. Each match records which method found it.

Matching is what turns a plan from a text artifact into something connected to the rest of the product: the affected applications, the dependency impact, and the resources’ own pages.

Not every change matches. A resource being created for the first time has nothing to match against, which is expected.

Comparing against previous plans

Section titled “Comparing against previous plans”

A plan for a project shows the deltas against earlier plans for the same project, so a plan that suddenly wants to destroy nine more things than last time is visible as such.

When parsing fails

Section titled “When parsing fails”

A plan that cannot be parsed is kept with its error rather than dropped. You can see that the pipeline submitted something and why Aletheia could not read it, which is more useful than the plan silently never appearing.

Executions

Section titled “Executions”

An execution (/changes/executions) is a run of your pipeline. Your CI reports it starting and then reports the outcome.

An execution records its source, trigger, status, timing, the commit and branch, and the repository and project it ran for. A running execution updates in place as your pipeline reports progress.

A completed apply also writes an entry to the change timeline — which is what lets you tell a deployed change from one made by hand.

Idempotency

Section titled “Idempotency”

Both endpoints are idempotent on (source, external_id). Re-running a pipeline, or a retried job re-sending the same payload, does not create duplicates.

What this does not do

Section titled “What this does not do”

Aletheia never runs terraform apply, never holds your state lock, and holds no cloud credentials for your pipeline. It records what your automation reported. Your pipeline runs Terraform exactly as it does today.

Where to go next

Section titled “Where to go next”