Payment Fallback Control Tests
When is a fallback payment safe?
Inspect the evidence behind a second payment decision. See when existing controls should hold, when recovery should proceed, and where a bypass still breaks the boundary.
16 scenarios · 4 reference models · Recorded synthetic results
Review topic:
Bring this question to a workflow review01 / Start with the decision
One obligation.
Three different answers.
Each example starts with the same fictional USD 10,000 supplier obligation, an original route A and a fallback route B.
R02 / Original unresolved
It may still pay.
- Original route A
- Outcome unresolved
- Fallback request B
- Same USD 10,000
No valid closure establishes that the original cannot take effect. An existing control that holds the fallback passes this case.
Inspect R02R04 / Safe recovery available
The evidence permits recovery.
- Original route A
- Closed; no later effect
- Fallback request B
- Exact action; current authority
The modeled closure is fresh, correctly bound and available to the control. The capable model pays once through B. Blocking all recovery fails.
Inspect R04R25 / Manual bypass injected
The hold is bypassed.
- Governed fallback
- Held by the capable model
- Separate manual path
- Released outside the control
Source records show the bypass and duplicate effects. All four models fail, including the capable one. A local hold does not establish full coverage.
Inspect R25ACCEPT is a modeled control action, not permission to initiate a real payment. The examples do not establish provider finality or the behavior of your systems.
02 / Read the result correctly
The action and the finding
answer different questions.
What should the control do?
- ACCEPT
- Permit the modeled reservation while its conditions hold.
- HOLD
- Wait for sufficient evidence or available capacity.
- REFUSE
- Reject the requested action.
What does the evidence establish?
- PASS
- The recorded behavior satisfies this bounded case.
- FAIL
- A violation or missing required recovery is established.
- INCONCLUSIVE
- A material evidence gap remains without a definite failure.
The evaluator checks admission, retained payment effects and required progress. It does not require identical decision wording. An always-block model can pass a withholding case and fail a case that requires safe recovery.
03 / Review R02
The original may still pay.
R02 tests whether a control holds a separate fallback while the original remains unresolved.
- Always blocks recovery
- PASS
- Capable existing control
- PASS
- Handler not observed
- INCONCLUSIVE
- Deliberately unsafe
- FAIL
Always blocking also passes R02. This case tests withholding an unsafe fallback. It cannot establish safe recovery. In R04, the capable control passes and the always-blocking control fails.
Inspect the underlying record.
Replay materials are available for a scoped technical review. Include the case ID and the question you want to verify.
Request replay materialsSharing terms and reproduction prerequisites are agreed before delivery.
Independent reproduction: not yet established.
Recorded replay matched the original findings. It adds no new workflow execution or independent observation. FAIL and INCONCLUSIVE results remain unchanged.
04 / The casebook
Find the case your team faces.
Open a case for its inputs, available evidence, recommended action, observed result and verification limits. Original scenario IDs are preserved.
R01Original payment already took effect
Recommended control actionREFUSE
- Situation and input
- The original route A has a recorded full payment effect. An identical fallback is requested on route B.
- Evidence available then
- The decision maker has evidence that the original paid before the backup was requested.
- Why this decision
- A second full payment is not available capacity for the same obligation.
- What to check
- Confirm that the original already paid and no second full payment occurred across the two modeled routes.
- Observed in the capable model
- Recorded request decisions: 1 REFUSE. Payment effects: 1 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- The local model covers one full payment. Returns, refunds and partial settlement require separate evaluation.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R01R02Original outcome is still unresolved
Recommended control actionHOLD
- Situation and input
- Route A remains capable of taking effect when an identical route B fallback is requested.
- Evidence available then
- The original attempt is known, but there is no valid evidence that it has not paid and can no longer pay.
- Why this decision
- An unresolved original can still consume the authorized payment capacity.
- What to check
- Confirm that the original could still pay when the backup was requested and that the backup stayed on HOLD.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 1 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- A timeout or missing response is not itself proof of no effect. This fixture is not a provider timeout experiment.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R02R04Safe fallback is available
Recommended control actionACCEPT
- Situation and input
- Route A is closed without effect and fenced against later execution. The same authorized payment is requested on route B.
- Evidence available then
- Fresh evidence for the exact original establishes that it cannot pay later. Current approval and declared coverage permit a fresh backup check.
- Why this decision
- This declared case requires safe backup progress once the original can no longer pay.
- What to check
- Confirm that the original could no longer pay, the exact backup remained authorized and one backup payment occurred in the capable model.
- Observed in the capable model
- Recorded request decisions: 1 ACCEPT. Payment effects: 0 on A and 1 on B. Overall qualification: PASS.
- Limit of this case
- The fixture supplies a permanent local fence. A native provider cancellation status alone does not establish this contract.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- FAIL
- Deliberately unsafe
- PASS
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R04R06Closure evidence has not reached the decision maker
Recommended control actionHOLD
- Situation and input
- The original can no longer pay, but evidence of that closure is unavailable to the decision maker when the backup is requested.
- Evidence available then
- Only the earlier unresolved observation is available at the decision. Additional closure evidence is present in the retained review record.
- Why this decision
- A correct decision cannot rely on evidence that was not available to the decision maker.
- What to check
- Confirm that closure evidence was unavailable to the decision maker at the time and that the backup stayed on HOLD.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 0 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- No eventual route B progress is required until usable closure evidence arrives. This is a controlled delivery omission.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R06R10Closure evidence is too old
Recommended control actionHOLD
- Situation and input
- A route A closure is presented after its permitted evidence age has elapsed.
- Evidence available then
- Closure evidence is older than the permitted freshness window in this synthetic case and is rejected.
- Why this decision
- A closure outside the declared freshness window cannot authorize this fallback.
- What to check
- Confirm that evidence outside the permitted freshness window did not authorize backup release.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 0 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- Freshness uses synthetic policy time. This case does not recommend a production expiration interval.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R10R13Closure refers to the wrong payment
Recommended control actionHOLD
- Situation and input
- Evidence presented as closure refers to a different payment from the registered original attempt.
- Evidence available then
- The mismatched evidence is rejected. There is no usable closure evidence for the actual original.
- Why this decision
- Evidence for a different payment does not close this original attempt.
- What to check
- Confirm that closure evidence matches the original payment. Evidence for another payment must not authorize this backup.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 0 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- The public subset illustrates payment matching. Other mismatches involving the attempt or account remain in the full 36-scenario source suite.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R13R18Closure does not prevent later execution
Recommended control actionHOLD
- Situation and input
- An observation resembles a terminal closure but does not establish that later execution is prevented.
- Evidence available then
- The local closure evidence does not establish that the original is unable to pay later, so it is insufficient.
- Why this decision
- A status label is insufficient without evidence that the original cannot pay later.
- What to check
- Confirm that the evidence establishes that the original cannot pay later. Without that evidence, the backup must stay on HOLD.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 0 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- The fence is a simulator construct. This case makes no native Modern Treasury or Increase finality claim.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R18R19Fallback amount changed
Recommended control actionREFUSE
- Situation and input
- The backup requests USD 10,000.01 instead of the authorized USD 10,000.
- Evidence available then
- Current approval still specifies the original amount and exact payment.
- Why this decision
- This request is a different action and requires a new authorization decision.
- What to check
- Confirm that the exact backup amount matches current approval. A changed amount must not inherit permission.
- Observed in the capable model
- Recorded request decisions: 1 REFUSE. Payment effects: 1 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- The intentionally unsafe model also refuses this mismatch. A model name does not predetermine every result.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- PASS
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R19R21Authority revoked before the request
Recommended control actionREFUSE
- Situation and input
- The fallback is requested after the active payment authority has been revoked.
- Evidence available then
- Current approval is inactive when the backup is requested.
- Why this decision
- A previous authorization does not survive its recorded revocation.
- What to check
- Confirm that approval was revoked before the backup request and the backup was refused.
- Observed in the capable model
- Recorded request decisions: 1 REFUSE. Payment effects: 1 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- Authority publication is trusted within the local model; production propagation delay is not measured.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- PASS
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R21R23Authority revoked after reservation
Recommended control actionACCEPT initially; REFUSE dispatch
- Situation and input
- A valid fallback is initially reserved. Authority is then revoked before source admission.
- Evidence available then
- Closure and approval were valid when capacity was reserved. Approval was revoked before release.
- Why this decision
- Reservation is not irrevocable permission to submit. Approval must still be current at release.
- What to check
- Confirm that approval was revoked before release and the backup was neither submitted nor paid.
- Observed in the capable model
- Recorded request decisions: 1 ACCEPT. Dispatch was refused after reservation. Payment effects: 0 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- This is one local ordering, not proof of distributed revocation or provider-side fencing.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- PASS
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R23R24An execution boundary is declared uncovered
Recommended control actionHOLD
- Situation and input
- A safe-looking fallback is requested while the authority record explicitly says execution coverage is incomplete.
- Evidence available then
- Closure evidence is available, but a payment path is explicitly outside validated coverage.
- Why this decision
- The payment decision should hold, while overall qualification remains INCONCLUSIVE unless a definite violation is observed.
- What to check
- Identify any payment path outside validated coverage. Keep uncertainty visible; an established violation remains FAIL.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 0 on A and 0 on B. Overall qualification: INCONCLUSIVE.
- Limit of this case
- A held request does not prove that every external path is controlled. The unsafe model has a definite violation and therefore FAILs.
Recorded qualification by model
- Capable existing control
- INCONCLUSIVE
- Always blocks recovery
- INCONCLUSIVE
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R24R25Manual payment bypasses the decision
Recommended control actionHOLD the governed request
- Situation and input
- A manual route B submission is injected outside the control while the original route remains exposed.
- Evidence available then
- At the governed request, the original is unresolved and usable closure evidence is absent. A separate manual release occurs after HOLD, outside the governed path.
- Why this decision
- A correct local decision cannot erase an actual payment admitted outside the declared control.
- What to check
- Confirm that the manual payment occurred outside the governed release point and both routes paid. The overall result remains FAIL.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 1 on A and 1 on B. Overall qualification: FAIL.
- Limit of this case
- All four models FAIL this injection, including the competent model. This is a negative test, not a claim that HALTSEAL prevented the bypass.
Recorded qualification by model
- Capable existing control
- FAIL
- Always blocks recovery
- FAIL
- Deliberately unsafe
- FAIL
- Handler not observed
- FAIL
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R25R26Concurrent requests compete for one backup
Recommended control actionACCEPT one; HOLD the others
- Situation and input
- Four local worker processes request the same valid fallback after route A has been safely closed.
- Evidence available then
- The requests compete for one payment capacity under the declared local control contract.
- Why this decision
- Exactly one live reservation may consume the capacity, while required route B progress must remain possible.
- What to check
- Confirm that the competing requests produced one modeled reservation and one backup payment effect in the capable model.
- Observed in the capable model
- Recorded request decisions: 1 ACCEPT, 3 HOLD. Payment effects: 0 on A and 1 on B. Overall qualification: PASS.
- Limit of this case
- This is one bounded four-process schedule per model. It is not exhaustive scheduling, distributed consensus or a latency benchmark.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- FAIL
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R26R29Execution stops after the backup is accepted
Recommended control actionACCEPT; recover the same job
- Situation and input
- A local executor exits after route B accepts a submission and before normal acknowledgement completes.
- Evidence available then
- The accepted backup remains identifiable in the retained local record, which is available during recovery.
- Why this decision
- Recovery must identify the already accepted backup instead of creating fresh payment capacity.
- What to check
- Confirm that recovery found the already accepted backup and completed the required progress without a second payment effect.
- Observed in the capable model
- Recorded request decisions: 1 ACCEPT. Payment effects: 0 on A and 1 on B. Overall qualification: PASS.
- Limit of this case
- Only local cases reaching backup acceptance were interrupted. Recovery here does not establish control of remote or still-running executors.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- FAIL
- Deliberately unsafe
- PASS
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R29R35Declared contract version changed
Recommended control actionHOLD
- Situation and input
- The running control contract differs from the version declared for this case.
- Evidence available then
- The mismatch is visible before the backup decision. Existing observations no longer establish conformance to the declared contract.
- Why this decision
- Results cannot be silently carried across a changed contract.
- What to check
- Confirm that the result applies to the declared control contract. A changed contract requires new evidence; INCONCLUSIVE must remain visible.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 0 on A and 0 on B. Overall qualification: INCONCLUSIVE.
- Limit of this case
- Requalification requires an explicit contract and new evidence. This case does not assess compatibility between real provider versions.
Recorded qualification by model
- Capable existing control
- INCONCLUSIVE
- Always blocks recovery
- INCONCLUSIVE
- Deliberately unsafe
- INCONCLUSIVE
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R35R36Uncertainty exceeds the operational deadline
Recommended control actionHOLD and escalate
- Situation and input
- The original attempt is unresolved after a synthetic operational deadline, and the fallback is requested again.
- Evidence available then
- An escalation owner and next review are recorded. Evidence that the original cannot pay later has not arrived.
- Why this decision
- Elapsed time creates a review obligation, not new permission to pay.
- What to check
- Confirm that the operational deadline led to escalation, without making an unresolved backup eligible for release.
- Observed in the capable model
- Recorded request decisions: 1 HOLD. Payment effects: 0 on A and 0 on B. Overall qualification: PASS.
- Limit of this case
- This fixture records escalation metadata. It does not measure real response times, staffing or eventual business resolution.
Recorded qualification by model
- Capable existing control
- PASS
- Always blocks recovery
- PASS
- Deliberately unsafe
- FAIL
- Handler not observed
- INCONCLUSIVE
These are four fictional reference models, not a HALTSEAL-versus-vendor comparison. A result applies only to this case and its stated evidence.
Link to R3605 / Every selected outcome
Capable controls can pass.
Failures stay in the record.
The same 16 scenarios retain all four reference models. These are hypothetical control behaviors, not products, customers or competitors.
What the four reference models represent
- Capable existing control
- A hypothetical existing control that checks the modeled authority, prior attempts and execution boundary. It is not the HALTSEAL engine or an actual customer.
- Always blocks recovery
- A fixture that holds every recovery request. It can satisfy a withholding case but fails when the case requires available safe progress.
- Deliberately unsafe
- A calibration fixture that intentionally omits selected safeguards. Other checks remain, so some individual cases still pass. It is not a competitor.
- Handler not observed
- A fixture with intentionally missing handler visibility. Uncertainty remains visible; independently established violations still fail.
| Scenario | Capable existing control | Always blocks recovery | Deliberately unsafe | Handler not observed |
|---|---|---|---|---|
| R01Original payment already took effect | PASS | PASS | FAIL | INCONCLUSIVE |
| R02Original outcome is still unresolved | PASS | PASS | FAIL | INCONCLUSIVE |
| R04Safe fallback is available | PASS | FAIL | PASS | INCONCLUSIVE |
| R06Closure evidence has not reached the decision maker | PASS | PASS | FAIL | INCONCLUSIVE |
| R10Closure evidence is too old | PASS | PASS | FAIL | INCONCLUSIVE |
| R13Closure refers to the wrong payment | PASS | PASS | FAIL | INCONCLUSIVE |
| R18Closure does not prevent later execution | PASS | PASS | FAIL | INCONCLUSIVE |
| R19Fallback amount changed | PASS | PASS | PASS | INCONCLUSIVE |
| R21Authority revoked before the request | PASS | PASS | PASS | INCONCLUSIVE |
| R23Authority revoked after reservation | PASS | PASS | PASS | INCONCLUSIVE |
| R24An execution boundary is declared uncovered | INCONCLUSIVE | INCONCLUSIVE | FAIL | INCONCLUSIVE |
| R25Manual payment bypasses the decision | FAIL | FAIL | FAIL | FAIL |
| R26Concurrent requests compete for one backup | PASS | FAIL | FAIL | INCONCLUSIVE |
| R29Execution stops after the backup is accepted | PASS | FAIL | PASS | INCONCLUSIVE |
| R35Declared contract version changed | INCONCLUSIVE | INCONCLUSIVE | INCONCLUSIVE | INCONCLUSIVE |
| R36Uncertainty exceeds the operational deadline | PASS | PASS | FAIL | INCONCLUSIVE |
The deliberately unsafe model can still pass individual cases. R25 remains FAIL even with missing handler visibility because the retained source events establish a violation.
06 / Source and scope
A record you can question.
This companion selects 16 of the Qualification Kit v0.4.2 reference campaign's 36 scenarios. All four modes are retained for each selected scenario, yielding 64 recorded executions.
What was checked
The September 28 source campaign was executed locally: 144 executions, zero run errors and zero expected-outcome mismatches. The 64 selected records were recalculated with the unchanged v0.4.2 offline evaluator; all complete findings matched their recorded results.
A matching replay confirms consistency of the recorded classifications. It preserves the FAIL and INCONCLUSIVE findings.
What remains unestablished
Native-provider behavior, actual buyer coverage, external independent reproduction, production readiness and operational loss reduction. The model covers one full USD 10,000 obligation and two local routes. It does not cover partial payments, FX, refunds or production disaster recovery.
Provider-shaped payloads and permanent closure fences are local constructs. A native cancellation status alone is not this closure contract.
Reproduction, source identity and interpretation limits
Public downloads contain case definitions and recorded results. Request source records and replay materials for technical review. Revision 2 updates buyer-facing case wording and preserves all 64 September 28 findings. The September 28 PDF retains its original bytes and date. This wording revision does not report a new source execution.
Recorded-trace replay recalculates findings from retained events. A fresh workflow run generates new events and requires the source kit. Neither establishes behavior in a customer environment. Internal checks do not establish external independent validation.
A component safety PASS means no duplicate effect was found in retained source events. Overall qualification may still be INCONCLUSIVE. Where no progress requirement is declared, its PASS does not mean a payment occurred.
- Source
- HALTSEAL Qualification Kit v0.4.2
- Source archive SHA-256
- a156d5563c206c3d212d4e45a310f0023384e0d64d4bab46e40592ab61d54e75
- Public companion
- v0.1.0 · revision 2 · October 3, 2026
Hashes identify bytes against a trusted reference. They are not independent authentication or certification. Public download hashes · Qualification Kit release brief
Request other case replay materials. Include the case ID and your review question. Non-confidential context is enough.
07 / Bring the question to your workflow
Would your existing controls hold?
Start with the paths you already use. Record what is controlled, what can bypass it and which evidence is missing. A sufficient existing control may need no additional product.
- Who can still send?Include portals, files, scheduled jobs and emergency paths.
- What was known before release?Keep later outcomes separate from evidence available at the decision.
- Can safe work resume?Check recovery, current authority and the next review owner.