Why execution history
Software Outcomes and the Resulting State Do Not Preserve the Execution History that Produced It
As software execution becomes autonomous and multi-actor — the resulting state alone cannot show which execution occurred, in what order, or how each state transition derived from the ones before it.
A resulting software outcome can have multiple plausible histories. Multiple actors and multiple execution chains produce an outcome. Execution history provides the evidence of how the resulting state was produced.
S4 
Outcome
State alone does not
reveal its history
The old assumption no longer applies
In the Past Software Was Built around Human-Directed Execution
Software systems were designed around relatively bounded workflows, human initiation, and predictable execution paths.
Human 
Application 
Tool 
State change- Human intent
- Known tools
- Predictable flows
- Auditable outcomes
The execution model changed
Software Has Acquired Operational Agency
Autonomous software actors can delegate, invoke tools, modify artifacts, interact with infrastructure, and produce consequential state at machine speed.
Human 
Agent A 
Agent B API Agent C Tool 
Service 
Runtime 
State changeIt's not just more activity
More Autonomous Execution Creates More Relationships
The challenge is not simply the volume of activity. It's the increasing number of relationships that must be established to verify what happened.
- Who?
- What executed?
- Under what context?
- In what order?
- What state changed?
- In what order?
- What came before?
- What followed?
Resulting outcome does not provide execution history
Observing an Outcome and Preserving Its Execution History Are Different Systems Properties
Observations infer an outcome
Recorded execution relationships
S1
S2 S3
S4 The same state can result from different execution histories. State alone does not reveal how it was produced.
Why reconstruction has limits
Post-Hoc Reconstruction Depends on the Evidence that Survived Execution
Logs, telemetry, identity records, alerts, and other observations can be essential for investigation. However, they do not constitute a persistent execution record linking supported execution events to recorded state transitions.
Observation helps explain outcomes.
A recorded execution verifies history.
Identity is necessary — but different
Authority and Execution Are Different Properties
Identity / Authority
Who is the actor?
What may it do?
Execution Verification
What actually executed?
What recorded state transition followed?
What execution history can be
verified?
- Objectiverequested
- Authoritypermitted
- Executionrecorded
- Resulting statechanged
Software already depends on durable history
Version Control Shows the Value of Persistent, Linked History
Git demonstrates the value of persistent, linked history and file state showing the diff between Commit A vs. Commit B. However, Execution Verification addresses a different problem: establishing a verifiable record of execution events and the resulting state that led to the commit.
Git (commit history)
commit A e0cec939
commit B a19ce1f2 commit C 4a905c5f vs
Salmon (verifiable execution history)
Actors
S0 91d7a4e22 S1 a4e8c1f9 
Resulting state
Multi-actor execution makes lineage more important
Execution History Becomes More Important as Actor Multiplicity Increases
A single state can sit downstream of multiple actors, delegated operations, tools, runtimes and interventions. Execution history preserves these relationships.
Human S1 Agent A S2
Security
agent Tool S3 S4More actors create more consequences
Greater Control Increases the Need for Evidence
Systems that interrupt, modify, terminate, or remediate execution themselves perform consequential actions. Their execution becomes part of the history that downstream systems need to evaluate.
Agent 
Execution Resulting state Security agent executes block / modify / remediate
The missing systems property
The Missing Property Is Not More Observation.
It Is a Verifiable Record of Execution and State Lineage.
Execution Verification Infrastructure
Establish the Record during Execution
Execution Verification Infrastructure establishes persistent execution evidence during supported execution so downstream systems do not have to rely solely on retrospective reconstruction.
Salmon implements this architectural property.
S1 S2 S3
S4 Why now
Execution Complexity Is Increasing
The value of execution history increases as AI agents are deployed at scale. Consequential state changes occur faster than humans can reconstruct manually because execution becomes more distributed across actors and tools at machine speed.
- Autonomy
- Multi-actor
- Machine-speed
- State mutation
Execution Verification Infrastructure
Provides Missing Evidence to Understand Software
Outcomes
S1See where Execution Verification Infrastructure sits in the software stack.