Explainable changes. Actionable decisions.
Provenance answers “how did this change get here?” Needs Attention answers “what, exactly, do you need me to decide?” They are two views over the same durable engineering history.
A canonical change is a chain, not a mystery commit
Work
└─ Attempt
├─ Agent / human executions
├─ checks + Review Findings
└─ Pull Request
├─ preview / semantic validation
└─ Integration Queue
└─ canonical ref update
Git remains authoritative for the actual commit/ref history in Cloudflare Artifacts. Trestle records the surrounding coordination facts: why the work existed, which Attempt produced it, what ran, which findings were raised, what policy applied and which integration action moved canonical.
What provenance records are useful for
| Question | Evidence Switchyard can connect |
|---|---|
| Why was this change made? | The originating Work item and its description/comments. |
| Which candidate produced it? | Attempt branch and execution records. |
| Was it reviewed? | Review execution plus structured Review Findings. |
| What validation ran? | Check results, preview result and repository contract findings. |
| Why did it integrate? | Queue state, risk/policy decision and final ref-update provenance. |
| What failed before the winning path? | Losing/failed Attempts remain durable history instead of being erased. |
Needs Attention is a decision inbox
Automation should not escalate merely because an internal operation returned an error. It escalates when the system has reached a point where a human choice is actually required. The consolidated list includes:
- Attempts parked in unresolved conflict;
- Integration Queue items blocked by conflict or policy;
- workflow runs waiting for explicit approval;
- open error-severity findings that require direction.
Decision packets
An escalation snapshots the information needed to decide rather than forcing the operator to reconstruct logs. For a content conflict the packet can include repository, branch/base, conflicting paths, base/source versions, findings and suggested resolution actions.
| Decision | Effect | When it makes sense |
|---|---|---|
take_ours | Apply canonical/base-side content to the Attempt, resolve, then allow re-preview/requeue. | The canonical version should win this contested content. |
take_theirs | Keep source-side content and record the choice. | The Attempt's version is known to be the desired one. |
three_way | Run a real three-way merge and write the result onto the Attempt branch. | The changes can be reconciled mechanically. |
approve | Release a workflow/policy gate waiting on human approval. | The evidence is sufficient but policy requires a person. |
requeue | Run the blocked integration item through preview/freshness again. | The underlying cause has been repaired. |
Example
Suppose PR A integrates first and PR B now conflicts. Switchyard does not ask “merge failed, what now?” It can show that B was valid against the old base, A moved canonical, B now conflicts in two named files, the conflict-resolver attempted a repair, and the remaining choices are ours/theirs/three-way. The human decision then becomes another attributable event in the same provenance chain.