Deriving the Convergence Deadline

Closing the determinism gap in convergence-aware pre-collections

Part two of two. Revision to Deciding Before the System Agrees, which models what a system knows about a payment attempt and when it knew it, so that no pre-collections action is taken while the outcome is still resolving. That model escalates an unresolved attempt once a convergence deadline elapses, and never says how to set it. Read it first: this paper assumes its state model and boundary and revises one part of it.

Problem

The companion paper defines a six-state knowledge model for payment attempts and escalates an attempt to Indeterminate when a convergence deadline $D$ elapses without the attempt reaching a settled outcome. It then leaves $D$ as a configured value with no rule for choosing it.

That is a determinism failure rather than an acknowledged limitation. Two teams implementing that specification against the same platform would pick different values, produce different escalation behaviour, and neither could justify their choice. Under any structural review standard, a condition where competent implementations diverge is not an incomplete edge case. It is the model failing its central claim.

The gap also has a specific operational shape, which is what makes it worth a paper rather than a footnote. $D$ sits between two failure conditions that pull in opposite directions:

Too short. Attempts escalate to Indeterminate routinely. The neutral, uncertainty-acknowledging message becomes the default customer experience, and the model has replaced a wrong message with a vague one.

Too long. Action is deferred past the point of usefulness. The pre-collections window closes unused, which is the original defect the model exists to prevent.

Any value between those is defensible and none is derivable. This paper supplies the derivation.

What Bounds the Value

$D$ is not free. Two constraints bound it, and they come from different places, which is why the value cannot be reasoned to from first principles alone.

Coverage is empirical. $D$ should be long enough that most attempts converge before it expires, and how long that is depends on the observed behaviour of the platform, not on anything the model can assert.

Usability is contractual. Whatever grace remains after $D$ elapses must still be usable by the customer, and how much that is depends on the arrangement, not on the platform.

The derivation is the intersection of the two.

The expression

Let $F$ be the empirical distribution of $Δ_{co n v}$ over a reference population of converged attempts. Let $r$ be the maximum acceptable proportion of attempts reaching Indeterminate. Let $G$ be the grace period and $g r a c e_{min}$ the minimum usable window. Then:

$D = min (q_{1 - r} (F), G - g r a c e_{min})$

where $q_{1 - r} (F)$ is the $(1 - r)$ quantile of observed convergence latency.

The first term satisfies coverage. With $r = 0.05$ , $D$ sits at the ninety-fifth percentile of observed latency and one attempt in twenty escalates. The second term satisfies usability. $D$ can never leave less than $g r a c e_{min}$ on the clock, whatever the latency distribution says.

Both terms are computed rather than chosen. The only remaining input is $r$ .

Why $r$ is configuration rather than judgement

The distinction matters, because a derivation that terminates in another arbitrary number has not achieved anything.

$r$ has a directly statable meaning: the proportion of payment attempts on which the customer receives a message acknowledging uncertainty instead of a definite one. That is a question an accountable person can answer, and two organisations answering it differently produce defensibly different systems rather than arbitrarily different ones.

It is also configured once, stated, and applied uniformly across the population. It is not an operator deciding per account, which is the condition the determinism test actually prohibits.

Contribution 1: The Feasibility Condition

This is the part of the paper I regard as the actual contribution, rather than the expression above.

The two constraints do not always admit a solution:

$q_{1 - r} (F) \leq G - g r a c e_{min}$

Where this holds, $D$ is well defined and both constraints are met. Where it does not, convergence latency is structurally incompatible with the grace period, and no value of $D$ satisfies both.

The dangerous property is that the expression still returns a number. A minimum is always defined, so an implementation computing $D$ without checking feasibility silently takes the usability term and abandons coverage. Indeterminate then fires at whatever rate the latency distribution dictates, which may be far above the stated $r$ , and nothing in the system reports that the tolerance is not being met.

The model therefore rejects an infeasible configuration at startup rather than degrading at runtime. Three remedies exist and the rejection states all three, because they are exhaustive:

Raise $r$ . Accept a higher escalation rate as a decision rather than an accident.
Extend $G$ . Give customers a longer grace period to absorb the latency.
Reduce latency. Fix the convergence pipeline.

The value of forcing this is not arithmetic. An organisation whose latency exceeds its grace period today is already choosing option one, at whatever rate its platform happens to produce, without anyone having decided it or being able to state what the rate is. The feasibility check converts an invisible trade into a stated one, and it does so before the system runs rather than during an incident review.

This is the transferable part of the paper. The pattern generalises beyond pre-collections: wherever a threshold is bounded by one empirical constraint and one contractual constraint, the intersection may be empty, and a formula that always returns a value will conceal that. Checking feasibility separately from computing the value is the structural move.

Contribution 2: Deadline Binding

$F$ drifts, so $D$ is recalculated over a rolling window of the last $N$ converged attempts and applied when it differs from the current value by more than a configured threshold, which prevents oscillation on noise.

One rule governs how a recalculated $D$ interacts with work in progress:

$D$ is bound to the attempt at creation and recorded on it. A recalibration never changes the deadline of an attempt already in flight.

This is the rule most likely to be missed in implementation, and missing it is not a minor defect. Without binding, an attempt's escalation time depends on whether a recalibration job happened to run during its life. The same input history replayed twice produces different knowledge states, which breaks deterministic replay, which is the property the entire model was built to provide. A team could implement every state and transition correctly, store $D$ as a single current value in configuration, and destroy the model's central guarantee without any test failing.

The symptom, if it reaches production, is that historical reconstruction disagrees with what the system did at the time, and it disagrees intermittently and only for attempts spanning a recalibration. That is an unpleasant class of defect to diagnose from the symptom backwards.

Contribution 3: Bootstrap and Segmentation

Cold start

Before a distribution exists, $F$ is undefined and the coverage term cannot be evaluated:

$D_{b oo t s t r a p} = G - g r a c e_{min}$

This is the maximum feasible value. It maximises coverage, satisfies usability by construction, and produces the lowest possible escalation rate at the cost of the slowest possible action. It is conservative in the correct direction, since the failure it risks is acting late, which is the condition already prevailing before the model was introduced.

Recalibration occurs once $N$ converged attempts have been observed.

The bootstrap has a second use worth stating: an implementation that never measures $Δ_{co n v}$ runs permanently at this value and remains correct, merely slow. The model degrades to safe behaviour rather than to undefined behaviour when the measurement discipline is absent, which matters because the measurement discipline is frequently absent.

Segmentation

Convergence latency is not uniform. A Friday evening attempt and a Tuesday morning attempt on the same platform have materially different distributions, which is precisely what the opening scenario of the companion paper illustrates.

$D$ may be derived per segment subject to one constraint: the segment must be determinable from inputs available at attempt time, because the attempt needs its deadline at creation. Payment channel and attempt day-of-week qualify. Anything known only after the outcome does not.

Segmenting on day-of-week is the highest-value refinement available. It targets the weekend latency producing the worst cases while leaving weekday behaviour unchanged, and it requires no new inputs.

What Implementers Are Likely to Get Wrong

Collected explicitly, because each of these produces a system that looks correct.

Exposing $D$ as a settable configuration value. The derivation removes judgement, and an implementation that offers $D$ in a settings file has reintroduced it. Expose $r$ , $g r a c e_{min}$ , $N$ , and the change threshold. Do not expose $D$ .

Computing $D$ without checking feasibility. The expression always returns a value, so nothing fails. The stated escalation tolerance is silently not met. This is the failure that will not be noticed for months.

Holding a single current $D$ rather than binding it per attempt. Breaks deterministic replay intermittently, as above.

Deriving segment values from thin samples. A quantile over twelve observations is not a distribution. Where a segment has fewer than $N$ converged attempts, fall back to the parent population rather than computing something numerically valid and statistically meaningless.

Measuring $D$ in business hours while grace runs in elapsed time. Reintroduces exactly the clock mismatch the companion paper's model exists to remove. Where the weekend materially changes latency, that belongs in segmentation, not in the clock.

Normalising away mixed deadlines in a population. A batch spanning a recalibration legitimately contains attempts with two different values of $D$ . That is correct, and an implementation that reconciles them to one value has undone the binding rule.

Revisions to the Companion Paper

State model. Unchanged. Six states, same transitions.

Transitions. The two Clock rows now read against the $D$ recorded on the attempt rather than a global value.

Invariants. Two added:

The deadline is bound at creation. Every attempt records the $D$ in force when it was created, and escalation is evaluated against that recorded value.
The configuration is feasible. $q_{1 - r} (F) \leq G - g r a c e_{min}$ holds, or the system does not run.

Constraints. $D$ is removed from the configuration list and replaced by $r$ , $N$ , and the change threshold. Added: measurement of $Δ_{co n v}$ is required before the model leaves its bootstrap value, and the feasibility condition is checked at startup and on every recalibration.

Edge cases. Three added: recalibration landing while attempts are in flight, abrupt distribution shift, and segments with insufficient volume.

Unresolved tensions. The $D$ entry is removed. One narrower entry replaces it, below.

What Remains Open

$D$ is derived from a rolling window, so a genuine shift in convergence latency is absorbed over $N$ attempts rather than immediately. During that interval the escalation rate departs from $r$ without any rule being violated and without the feasibility check failing, since the check runs against the window's contents rather than against current behaviour.

Detecting a distribution shift faster than the window that defines it requires a change-detection mechanism outside this model. Choosing $N$ trades responsiveness against stability, and this model does not resolve that trade.

This is a genuine surfaced tension rather than an escalating one. It does not cause two implementations to diverge, since both would use the same window and the same rule, and it does not undermine an invariant. It bounds how quickly the derived value tracks reality, which is a stated property of the mechanism rather than a gap in it.

Find a specification.