Competing-outcome contracts at a fixed horizon

Last updated: 5 Oct 20265 min read

tutorial

A competing outcome permanently prevents the event of interest in its original form; it is an observed outcome, while loss of follow-up leaves the outcome unknown.

Name the event and its blockers

For a support case, the question may be whether it is resolved by day nine. Cancellation first makes later resolution of that same case impossible. Cancellation is a competing event, not a missing status. A case still open and observed through day nine is also a known negative for the nine-day resolution indicator. A case whose status feed ended on day five is unknown at day nine. Treating all three as one zero discards why the outcome was not seen. Competing-risk basics establish the target.

Pin the first terminal transition

A case can have a resolution record and a later cancellation correction. The analysis needs a deterministic policy for which terminal transition counts and whether the later row is a correction or a genuinely new case. Retain event ID, effective timestamp, recorded timestamp and policy version. Exclude a record with an impossible negative age or duplicate case ID before calculating rates. An unresolved case may have many activity events, but it still contributes one case-level terminal status.

Build a horizon state without future leakage

The code accepts one final outcome and the age at which that outcome or last observation occurred. A resolution by day nine is a positive; a cancellation by day nine is a known negative. An event after nine implies the case was still under observation at nine, so the nine-day target is negative. Early loss is unknown. This single-indicator contract is appropriate for a fixed-horizon score; it does not estimate an event-time incidence curve.

Do not rename a counterfactual

If cancellation had been prevented, some cancelled cases might later have resolved. That hypothetical probability is not observed nine-day resolution incidence under the actual workflow. Censoring cancellation and running ordinary Kaplan–Meier analysis answers a different hypothetical question under strong assumptions. For capacity planning, the observed chance of resolution before cancellation is often the useful quantity. Cumulative incidence retains the competing outcome.

Reconcile event shares

At a common mature horizon, resolution, cancellation and still-open shares must add to one among cases with known state. Report cases lost before the horizon separately. Changes in cancellation policy can change the resolution share even if the team’s conditional resolution pace did not change. The event taxonomy belongs in every saved model version and validation report.

Implementation

def resolution_by_horizon(case_id, observed_day, outcome, horizon_days):
    if not case_id or observed_day < 0 or horizon_days <= 0:
        raise ValueError("invalid case or horizon")
    if outcome not in {"resolved", "cancelled", "open", "lost"}:
        raise ValueError("unknown outcome")
    if outcome == "open" and observed_day < horizon_days:
        return None
    if outcome == "lost" and observed_day < horizon_days:
        return None
    return int(outcome == "resolved" and observed_day <= horizon_days)

cases = [("E241", 4, "resolved"), ("E242", 6, "cancelled"),
         ("E243", 12, "open"), ("E244", 5, "lost")]
states = [resolution_by_horizon(case_id, day, outcome, 9)
          for case_id, day, outcome in cases]
assert states == [1, 0, 0, None]

Performance and operating cost

Classifying N already deduplicated case records takes O(N) time and O(N) output space; a streaming count needs O(1) extra space. The real cost is resolving event-log conflicts and reconstructing observation status at the historical cutoff.

Common Mistakes

Do not censor a cancellation while claiming to estimate observed resolution incidence.
Do not call early loss a known nine-day non-resolution.
Do not use a later correction as a predictor available at case creation.