OSuite / Solutions / 02
Resume the task. Not the mistake.
Keep approvals, committed effects and the next permitted step distinct when a change or batch operation fails halfway through.
Released SDK recovery path tested; resource capabilities remain decisive
Platform engineering / Financial operations / Commerce & retail
The task is useful. The failure is specific.
The business task
An agent applies an approved configuration change, creates a batch of business drafts or updates a service. One item commits, the response disappears, and the caller restarts. The operator needs to continue useful work without repeating an irreversible effect.
Where a normal flow becomes risky
Timeout is not evidence of non-execution. HTTP acceptance is not whole-task completion. Retrying under a new ID can bypass operation-level deduplication, and a previously valid permission may be gone by the time recovery begins.
Reference workflow, not a claim of installed coverage
Make each handoff explicit.
- 01
Identify
Assign stable operation and business-item identities; define each step, its authority and the resource evidence required for completion.
- 02
Authorize
Bind the actual plan and parameters to the applicable decision. Reusable semantic evidence does not keep a revoked authorization alive.
- 03
Dispatch
Persist the execution intent before sending. Preserve whether a request was definitely not sent, possibly sent or confirmed by the resource.
- 04
Observe
Query by the original identity when a response is lost. Keep committed, absent, declined and unobservable results distinct.
- 05
Recover
Continue only steps that are currently authorized and safe under the resource contract. Do not automatically resend an ambiguous operation.
| Situation | Observable change | Required handling |
|---|---|---|
| Commit followed by lost reply | The resource wrote the item, but the controller has no acknowledgement. | Look up the original operation. If no reliable lookup exists, retain unknown and escalate. |
| Process dies around send | The local durable journal survives, but the caller did not finish. | Reopen the same journal and preserve the uncertain dispatch fence. |
| Same item, new operation ID | A caller attempts the same business instruction using a different ID. | Use resource-side business uniqueness; journal identity alone is insufficient. |
| Two callers, one remaining allowance | Both callers pass an earlier check before either commits. | Enforce the shared allowance in the resource transaction rather than trusting two independent prechecks. |
Deployment and responsibility
Keep your systems. Define the missing contract.
What stays with you
Keep your CI, scheduler, application transaction, native idempotency and incident-response process. OSuite does not become a deployment engine, payment rail or distributed transaction coordinator.
What the integration adds
Stable-ID SDK handling, an explicit per-item outcome contract, and a recovery view that separates callback lifecycle from business completion. Native resource guarantees remain part of the solution.
| Boundary | Required information or capability |
|---|---|
| Durable execution identity | A supported persistent journal, agreed business uniqueness and safe restart/restore procedures. |
| Resource observations | Idempotency or conditional writes where available, plus a result lookup with defined trust and consistency. |
| Recovery ownership | An operator for ambiguous results, explicit compensation rules and a way to stop new work without hiding earlier effects. |
Most useful when operations span multiple calls, actors or systems and recovery is expensive. If the platform already supplies the full required transaction and recovery contract, integrate with it rather than duplicate it.
Observed, not assumed
What the evidence supports today.
In 18 journal-protected local crash cases, the original operation was re-offered after reopening the same journal: 12 SDK attempts and six conventional-journal attempts. Retained harness records show no additional parent-process callback or extra resource effect on those re-offers. Original child callback execution is counted separately.
Measure useful work and operating cost
Agree what success means before the pilot.
| Area | Evidence to collect |
|---|---|
| Useful recovery | Confirmed progress remains visible; eligible unfinished work resumes without repeating an ambiguous effect. |
| Correct accounting | Measure actual duplicate effects, shared-budget violations, partial outcomes and unresolved operations. |
| Operator cost | Measure time to understand and resolve a failure, added checks, retained state and ongoing support burden. |
Use the same task, permissions, resource guarantees and failure schedule for the existing platform and proposed integration. Denial alone is not success: normal work and safe recovery must also remain usable.
Start with one boundary
Bring a workflow. Leave with acceptance criteria.
Select one task, its actual tools and the decision owner. We can assess whether existing controls are sufficient, whether a narrow adapter is useful, or whether a broader integration deserves a pilot.
Pilot scope, prerequisites and commercial terms are agreed separately. No production access is needed for the initial discussion.