Human Repair
Summary
This thread explains the human-repair posture: automation should turn ambiguity into visible state, not hidden failure.
Reader Question
Why should operational automation create reviewable repair state instead of only succeeding or failing?
Surface Or Workflow
The reader sees a generalized repair model: issue, evidence, human decision, audit trail, and resumed work.
Lifecycle
Automation encounters ambiguity. The system records the failure as data, exposes evidence through an operational surface, captures a human decision, and resumes work through service-owned behavior.
Child Threads
- Failures Are Data: failure posture.
- UI Window Into Operations: operator surfaces as operational windows.
- Composable Operations: execution and service context.
Implementation Boundaries
This thread focuses on the reusable repair pattern. Domain-specific repair surfaces are linked where they help explain the pattern.
Tradeoffs
The repair story is abstract by design. It describes a durable pattern without requiring access to specific internal cases.
Visual
The current visual is a public-reviewed graph neighborhood. The intended visual is a loop from automated ambiguity to issue, evidence, repair, and resume.
Source Evidence
docs/public/platform-journey-strategy.mddocs/engineering/concepts/failures-are-data.mddocs/engineering/concepts/ui-window-into-operations.mddocs/engineering/concepts/pipelines-jobs-services-review-surfaces.md