Execution History for Multi-Actor Software Systems
Salmon is Execution Verification Infrastructure: a cryptographic protocol that establishes a Verifiable Execution Record across humans, agents, and automation. Built for engineering, security, and AI verification systems.
Software Has Acquired Operational Agency
AI agents increasingly act across tools, workflows, infrastructure, and downstream services.
The central technological shift is recursive delegation of operational authority across humans, agents, tools, orchestration systems, and infrastructure. An assigned objective does not establish compliant execution.
Software is produced by multiple actors across distributed systems, making the execution history associated with resulting software state difficult to establish from the outcome alone. The outcome does not reveal the multi-actor execution history that produced it.
Governance increasingly depends on understanding which operational actions were delegated, executed, and propagated to produce a given outcome.
One Verifiable Execution Record. Multiple Downstream Systems
Existing systems observe, govern, and secure execution. Salmon establishes execution evidence those systems can consume.
AI and Agent Platforms
- Execution verification
- Evaluation evidence
- Agent supervision
Cybersecurity Platforms
- Investigation context
- Attribution
- Response evidence
Cloud and Infrastructure
- Infrastructure change evidence
- Automation execution evidence
- State-change reconstruction
Developer Platforms
- Execution history
- Debugging and reconstruction
A Production Event Occurs. No System Records How It Was Produced
A configuration file changes and reaches production. The commit, the author, the deployment, and the policy record are each accurate. Without a canonical execution history, attribution and reconstruction depend on fragmented evidence, making accountability and responsibility harder to evaluate.
Who initiated it?
The originating actor is no longer identifiable from the artifact.
Which system executed it?
Multiple systems may have contributed to a single outcome.
How was it produced?
The execution path is not encoded in the resulting artifact.
What evidence supports evaluating responsibility?
No single record holds the evidence needed to evaluate it.
Existing Records Capture Pieces of Execution, Not Necessarily a Verifiable Execution History
As delegated software execution becomes increasingly multi-actor, these questions become mission critical.
What existing records can establish
- Who authenticated?
- What artifact changed?
- What API was called?
- What policy was applied?
- What event was recorded?
What fragmented records do not necessarily establish
- Which recorded execution is associated with this state transition?
- Which execution chain produced this state?
- What recorded sequence of actions led here?
- How was execution authority delegated?
- What execution evidence is available for evaluating responsibility?
Execution History Is the Missing Property
Execution history functions as a foundational system record alongside identity, policy, and telemetry. It is the one that is not yet in place.
Identity
who authenticated
Telemetry
what was recorded
Observability
what was observed
Policy
what was permitted
Execution History
how it was produced
Why execution history is not reliably reconstructed after execution occurs
Salmon Establishes Verifiable Execution History
Salmon is a cryptographic protocol. It records execution transitions as they occur, binds each one to a signer, and links them into a chain that can be checked state by state, for agent execution, human execution, and automation alike.
- Recorded, not reconstructed afterwards. Execution history is recorded as it occurs, independently of the agent's own account of what it did.
- Signed at execution. Identity is attached when the transition happens, not inferred afterwards.
- Unaccounted-for state transitions are marked. The record says that something changed outside the capture boundary rather than presenting an unbroken chain.
Execution Verification Infrastructure Capture · Execution Record · State Lineage · VerificationWhat the Execution Record Looks Like
Each row is one execution event, signed as it happened. Where recorded state jumps without a matching event, the record says so rather than presenting an unbroken chain.
chain: 2 sessions · 7 events · 1 unaccounted-for transition · all captured signatures validsession A[3dcca739]First Claude Code session2026-08-10T08:51:24Z✓3dcca739f026957aclaude:session-start,prompt2026-08-10T08:52:07Z✓3dcca739e96a3979claude:bash,read,edit2026-08-10T08:52:18Z✓3dcca739ca556ea7claude:session-end⚠UNACCOUNTED-FOR STATE TRANSITIONrecorded state at session B does not follow from session Asession B[d47cf728]New Claude Code session2026-08-10T08:52:41Z✓d47cf728e0cec939claude:session-start,prompt2026-08-10T08:53:39Z✓d47cf728a19ce1f2claude:bash,skill,read,edit2026-08-10T08:54:39Z✓d47cf7284a905c5fclaude:prompt2026-08-10T08:55:14Z✓d47cf728cb738110claude:read,bash,editchain end · 2026-08-10T08:55:14Z · signatures verified
Observability Records Signals About Execution. Execution History Establishes How State Was Produced
Where the actor being evaluated can influence the record that describes its own execution, that record is not authoritative because it exists.
Not observability. Not logging. Not security tooling. Logs, telemetry, and observations can support reconstruction after execution. Salmon establishes a verifiable execution history during supported execution.
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.