Summary
An operational workflow regularly encounters missing mappings, ambiguous identities, incomplete evidence, and provider mismatches. Those are not all software defects, and they are not all reasons to stop an entire run. They are often work waiting for a decision. LKCI's platform posture is to represent such recoverable outcomes as durable issues, signals, review tasks, or failed-run state with evidence and a repair path.
The distinction is practical. A log line can say something went wrong. A work item can say what happened, what it affected, what evidence exists, who may decide, and how the workflow resumes. The platform is designed around the second form when human judgment is the correct next step.
Operational Tension
Automation is often evaluated as a binary: it succeeded or it failed. That model breaks down when a batch contains many independent items or when an external system returns evidence that is plausible but not decisive. Retrying an ambiguous identity does not create new identity evidence. Throwing an exception can preserve a stack trace but loses the operator's context. Ignoring the item may preserve throughput while hiding a business gap.
The opposite mistake is equally dangerous: catching every exception and creating a reassuring issue. Authorization failures, violated invariants, and programmer errors require visible failure with their cause preserved. If they are translated indiscriminately into “needs review,” the system can appear to advance while its safety boundary has failed.
The operating challenge is therefore classification: what outcome can be repaired through domain judgment, what outcome merits bounded retry, and what must halt loudly because the program or its authority is wrong?
Decision: Make Expected Ambiguity Durable
The architecture assigns different responsibilities to those outcomes. Recoverable business ambiguity and per-item validation failures become typed results, signals, or deduplicated issues at an orchestration boundary. Retryable provider or infrastructure failures retain attempt context and use bounded retry. Permanent operational failures become failed runs or issues with evidence and a repair path. Programmer errors, authorization failures, and violated invariants fail visibly.
This requires state beyond a process exception. A useful operational record preserves safe scope and correlation context: the tenant, actor or run, attempt, outcome, duration, and safe counts where relevant. It gives a human or an authorized agent a route to inspect the evidence without reconstructing the event from a transient worker log. Domain services and review surfaces own the repair interaction; pipelines do not pause invisibly for a person.
The decision also keeps the workflow composable. A job may orchestrate the batch, but reusable business behavior belongs in services and libraries. The job should not become a private catalog of special cases. By placing issue creation and repair semantics at a service boundary, different entrypoints can reach the same visible state.
Failure And Repair Posture
Imagine an automated step that needs a decision it cannot make safely. The right response is not a silent default. It creates an issue or review task with the candidate evidence, records the current state, and gives the appropriate operator an explicit action. The repair changes durable domain state. Resumption is then a defined transition, a retry with context, or a newly queued step—not an instruction to rerun an entire opaque script and hope the circumstances have changed.
This posture also protects partial progress. Independent items can reach accepted outcomes while uncertain ones remain visible. The system can tell the operator what is blocked, rather than flattening all results into a single pass/fail status. Where external effects are involved, idempotency, leases, heartbeats, and intent or outbox records make retry and recovery less likely to duplicate work.
Repair is not an excuse to ignore observability. The expected failure record must contain enough context to act, but should avoid copying sensitive content into generic logs. Business audit history remains separate from diagnostic logging. The goal is a useful decision trail, not a new unbounded data store.
Tradeoff
This design costs more than a broad exception handler. It needs typed outcome models, durable persistence, deduplication rules, review UI, authorization, and tests for retry and resume. It also asks teams to name the difference between ambiguity and defect rather than treating all unexpected behavior as one category.
The benefit is operational continuity with accountability. A person can repair the right thing without reading code or guessing which worker produced a log. Future agents can participate only through the same state, evidence, actions, approval, and audit boundaries. The platform gets more automatable over time because it preserves where judgment was needed.
Limits
Not every failure should become an issue. A corrupted invariant or unauthorized operation should remain an error, with its root cause visible to engineers. Nor does a visible issue prove that the repair policy is good; it can still be poorly scoped or lack evidence. This case study describes an architectural posture, not a claim about any particular incident, queue volume, or response time.
Transferable Lesson
When the correct next step is judgment, model the interruption as work. Give it state, evidence, ownership, and a defined resumption path. When the correct next step is to fix the system, fail loudly instead. The value is not avoiding failure; it is making the nature of failure legible enough to repair safely.