Why Execution History

The Missing Property of Multi-Actor Software Systems

Execution history is the record of execution transitions that produced a resulting software state. Once an agent has executed, that history cannot be reliably reconstructed from observed events alone.

Reconstruction

Execution History Cannot Reliably Be Established After the Fact from Fragmented Observations Alone

If execution relationships are not preserved during execution, events observed afterwards may support multiple plausible histories. Observed events provide signals about execution, but fragmented observations do not necessarily preserve the relationships required to independently verify one execution history.

Incomplete evidence
  • Partial logs and records
  • Missing cross-system linkage
  • Unrecorded execution
Ordering ambiguity
  • Concurrent and parallel execution
  • Clock synchronization uncertainty
  • No canonical event sequence
Continuity gaps
  • Missing actor continuity
  • Missing state-transition linkage
  • Execution outside of recorded boundaries
Multiple plausible histories. No independently established execution history.
Identity

Identity Is Necessary but Insufficient

Identity establishes who authenticated. It does not establish what executed afterwards, or under what authority.

Access control describes the authority an actor was granted. It does not by itself establish which actions were executed under that authority or what state resulted.

Git vs Salmon

Git Shows Artifact History.
Salmon Records Execution History

Git is content-addressed version control. It stores blobs, trees, commits and tags, its primary question is what changed, and what it proves is that one content state evolved into another.

Salmon records execution events, state transitions, actor evidence, authority context, and their relationships within the supported execution boundary. Its primary question is how recorded execution relates to resulting state, establishing a verifiable execution record and state lineage rather than relying on the resulting artifact alone.

For traditional human-authored workflows, the human and the commit often functioned as the practical attribution boundary. Much of the agent and tool execution that now happens before the commit is not represented in Git's artifact history.

Git against Salmon. What Git proves: this content evolved into that content, commit A to commit B, its primary question being what changed. What Salmon establishes: this recorded execution is associated with this resulting state, running actor evidence, action, execution record, state transition, resulting state, its primary question being how recorded execution relates to this state
Consequences

Consequences of Missing Execution History

Operational events become more difficult to attribute and reconstruct, while responsibility must be evaluated from incomplete execution evidence.

Operational Events
Production incident
Unauthorized infrastructure change
Agent-triggered action
Cost spike
Security event
No canonical
execution history
What Becomes Unclear
Root cause disputed
Actor unclear
Responsibility unclear
Source unclear
Execution path unclear

Without a canonical execution history, attribution and reconstruction depend on fragmented evidence, making responsibility and accountability harder to evaluate.

Why Now

Agent Execution Has Reached Production

Attribution is strongest when captured during execution rather than reconstructed solely afterward.

Agents in Production

Agents no longer only suggest changes. They invoke tools, modify artifacts, and trigger downstream systems inside production environments.

Enterprise Adoption

Agent-assisted development is moving from individual experimentation to organization-wide deployment, under the security and audit obligations that already apply there.

Governance Pressure

Accountability and disclosure requirements increasingly reach software production, where consequential state changes increasingly require evidence of the actors and execution associated with them.

Common Questions

How Execution History Complements and Strengthens Existing Controls

How is this different from observability or tracing?

Observability and tracing capture telemetry about system behavior and request paths. They do not necessarily establish one signed execution record linking actor, transition, and resulting state. Execution history captures supported state transitions as a linked record, with each recorded transition bound to actor evidence as it occurs.

Does Salmon trust what the agent reports about itself?

No. An agent's account of its own session is another model output. Salmon records the state transition independently, so the record can be compared against what the tool said it did.

Where is the record produced?

Capture happens at the point of execution, on the machine where the change is made, so the record exists before anything is shared. Whether records then leave that environment — and where they are retained or queried — is a deployment decision rather than a property of the protocol.

Execution History for Multi-Actor Software Systems

Execution now comes from AI agents, humans, and automation. Salmon establishes a verifiable execution record for supported execution, captured as it occurs rather than reconstructed solely afterwards.

See Salmon in Action