PATH A
Original transfer worker
The software call site that submits the original attempt.
Retain cash-request-4822 and the original operation ID before sending.
ILLUSTRATIVE · SYNTHETIC · NONPRODUCTION
One workflow.
An actionable readout.
A historical pilot example showing the release paths, recovery observations and next work. New pilot sales have ended. This fictional example is not a customer result or approval to use production payment control.
01 / DECISION TO INFORM
Can our original and replacement software paths share one recovery contract?
Fictional format example with synthetic USD 10 inputs. These are illustrative observations, not a completed customer evaluation or new verification results.
Current local reference
Local synthetic own-account USD reference. This example uses USD 10 within the preserved R2 USD 20 principal ceiling. Real amounts, provider contracts and customer paths require separate qualification.
02 / PATH MAP
One transfer. Two software paths.
Common reference: cash-request-4822. The source owner establishes the same payer, beneficiary, currency and full principal across both paths.
PATH B
Replacement transfer worker
The software call site that proposes a replacement for the same transfer.
Use the same source-owned transfer identity. A different route or operation ID does not create capacity.
03 / EXISTING CONTROLS
Record the baseline before comparing.
This sample does not establish that a customer's existing idempotency, ledger or reservation is insufficient.
Record whether existing controls preserve the shared reservation and original identity through unresolved outcomes, restarts and every included replacement path.
04 / RECOVERY CASES
Observations with their limits.
Original outcome unresolved
HOLD
- Expected behavior
- Reserve the full principal. Block the replacement.
- Illustrative observation
- The replacement stayed on hold while the original outcome remained unresolved.
- Customer evidence still needed
- Identify both controlled release points and the remaining ways the original can pay.
Original create reply lost
HOLD until original resolved
- Expected behavior
- Look up the retained original operation. Do not resend create.
- Illustrative observation
- Original lookup retained the attempt identity without another financial create.
- Customer evidence still needed
- Verify that the application persists its operation ID before sending and retains it after restart.
Original closed; approval stale
HOLD
- Expected behavior
- Closure alone does not approve a replacement.
- Illustrative observation
- An approval issued before retained closure did not permit replacement release.
- Customer evidence still needed
- Identify authoritative closure evidence and the issuer of a newer signed approval.
Original closed; fresh replacement validated
ACCEPT
- Expected behavior
- Reobserve the original and validate the exact replacement.
- Illustrative observation
- One simulated replacement was reserved under a newer postclosure approval. Settlement remained unconfirmed.
- Customer evidence still needed
- Separately qualify provider closure semantics and the customer's complete release path.
Accepted replacement still unresolved
HOLD
- Expected behavior
- Keep the replacement's principal reserved.
- Illustrative observation
- Another path or request could not create a second allocation while the accepted replacement could still pay.
- Customer evidence still needed
- Include every retry and rescue path in the shared control boundary.
Obligation paid
REFUSE
- Expected behavior
- Paid history consumes the obligation.
- Illustrative observation
- A new route, request or approval did not permit another full-principal payment.
- Customer evidence still needed
- Confirm authoritative paid evidence and retained history for the actual provider path.
05 / OPEN CONDITIONS
What this record does not qualify.
- Customer-path integration and provider qualification remain open.
- Common transfer mapping, existing controls and actual software call sites have not been evaluated in this sample.
- Manual or unconnected release paths remain outside coverage.
- Native bank connections, production operations, availability and customer economic value are not established.
06 / WRITTEN NEXT DECISION
Confirm the common transfer mapping and retained original identity, then agree any further provider qualification before considering enforcement.
Customer engineer
Map the two software release points.
Completion condition: One source-owned transfer identity and retained operation IDs are documented for both paths.
Customer payment owner
Assign the recovery evidence owner.
Completion condition: The required original-outcome evidence, escalation procedure and excluded paths have accountable owners.
Customer team and HALTSEAL
Decide whether to continue the integration.
Completion condition: Review the actual findings against the existing controls; accept a next scope or keep the current controls. Native qualification requires a separate agreement.
In a delivered pilot, observations, owners and actions reflect the accepted scope and actual findings. Keeping existing controls or stopping an integration can be the appropriate decision.