Reading the operation timeline

The Operations page answers "what happened to this stack, and when". This page explains what each part of it means and, just as importantly, what it will not claim.

Reading operations requires operations:read, which every fixed role holds. Transcript bodies need the separate transcript-reader role.

Two questions every row answers

Outcome is what happened to the operation itself.

Impact is what the operation did to your resources, in the Changes column. It is independent of outcome: a failed operation can still have deleted things, and a successful one can have changed nothing. The detail panel breaks the total down per kind (Delete 3 · Create 1), and a Destructive badge appears when a retained count is positive for delete, delete-replaced, or replace.

Impact has three honest non-answers:

• No changes recorded — the operation reported counts, and they were all zero.
• Change detail expired — counts were retained once and retention has removed them. The summary survives; the breakdown does not.
• Changes not reported — this source never asserted counts. Runner rows read this way unless the wrapper was given an event log. The absence is disclosed, not rendered as zero.

Where a row came from

The Evidence column and the detail panel's Source field always name the provenance:

• Pulumi backend — Lumaft read this from the backend's own update history with its read-only credentials.
• Runner (deployment runner) or Runner (developer workflow) — an integration token submitted it. The label reflects the token's authority kind, not a claim about a person.

Lumaft records no human identity for a deployment. Pulumi state does not carry one, and Lumaft does not invent one. No row will tell you who ran an operation.

A wrapped deployment that produces both a runner assertion and a backend record appears as two rows, one per source, each labelled. Lumaft stores the trusted join between them but this build does not collapse them into one row.

Conflicts

conflict means Lumaft retained more than one assertion for one operation and they disagree on the result. Lumaft does not resolve it by taking the newest, the first, or the most trusted source. It shows conflict, keeps every assertion, and leaves the judgement to you. A disagreement between sources is information; silently discarding half of it would destroy the only evidence that something is wrong.

Previews and comparison

preview is an operation kind like update, destroy, refresh, import, rename, and resource-import. A preview appears with its own outcome and, where the source reported them, its own planned counts.

The planned versus actual panel lines a preview's planned counts up against an apply's actual counts. It appears only when Lumaft holds a trusted, explicit correlation between the two (see Runner integration). Otherwise the panel says:

Comparison unresolved. No authorized trusted preview-to-deployment correlation is available. Lumaft does not infer a match from timestamps, stack names, or similar resource counts.

With a correlation, the table marks each change kind Unchanged, Changed, Planned only, or Actual only. If either side has lost its change detail to retention, the panel reads Resource detail expired and renders no comparison rather than an empty one.

Active and incomplete work

A runner can announce a run before it finishes. While its lease is live the row shows in progress and the detail panel shows Not finalized in place of an end time. When the lease expires without a finalize, the outcome becomes incomplete — Lumaft never learned how the run ended and says so rather than assuming failure.

The buttons above the filters offer All, Needs attention, and Succeeded. Needs attention selects cancelled, conflict, failed, and incomplete. To see only running work, choose In progress in the Outcome filter.

Attention is a view over immutable outcomes, not a work queue. You can mark an operation reviewed from its detail panel; marks are per user, and Reset all reviewed marks clears yours.

Coverage and gaps

The Evidence coverage panel keeps the rest of the page honest. It reports the earliest retained and latest accepted evidence in your scope, the retention cutoff and how many assertions retention has already pruned, the current policy revision, and for each backend when collection started and when it last observed successfully.

It shows banners rather than leaving you to infer:

Two more appear per operation: Earlier evidence expired when some of its assertions have been pruned, and Source clock skew flagged when a runner's asserted times disagree with Lumaft's clock beyond the accepted bound.

Lumaft cannot show you what it never saw. History a backend pruned before Lumaft first read that stack is not retained, reconstructed, or estimated.

Filters and permalinks

Filters live in the URL, so any view is a link you can paste into a ticket.

The timezone control switches every timestamp between UTC and local time and is part of the URL too. Each timestamp offers Copy ISO; each operation offers Copy permalink.

Filters are authorization-aware: an operation outside your scope and one that does not exist return the same message, so the page cannot be used to probe for stacks you cannot read.

Resource detail

From a stack's inventory you can open a resource's history: its retained transitions, each typed baseline, appeared, changed, removed, or reappeared, with the changed fields drawn from a closed list.

Continuity is stated, not assumed. A Gap before this change or History has a gap since the newest transition banner names its reason from a closed vocabulary (stack-missing, last-good-only, duplicate-urn, bound-exceeded, projection-diverged, continuity-expired).

The Operations near this change panel lists operations whose observed window overlaps the transition. Lumaft labels that relationship temporal. It is an overlap in time, never a causal claim. The console does not assert that the listed operation caused the change.

Transcripts

When capture was requested, an operation's detail shows transcript metadata: runner-reported status, retained content, labelled gaps, redaction counts, and expiry. Ordinary readers see the metadata; viewing or downloading text requires the transcript-reader role and loads only after View transcript, as inert text. Redaction cannot identify every secret.

Export

The Export evidence panel downloads the versioned evidence record for exactly one stack and one explicit accepted-time window. It enables once your filters name one backend, one layout, one stack, and both window bounds. The document contains bounded operation metadata, normalized changes, digests, and retention state; never raw state, engine logs, or transcript text. Every page is recorded in the export audit. Export requires operations:export, which administrators hold and viewers do not.