A defect is something that went wrong with the delivery itself — a package that did not complete, a customer who escalated. Two rungs live here, and one of them is the only rung on the entire ladder that can be cleared by data we pull ourselves.
Rung 7. The threshold is zero: anything above 0 excludes. There is no band, no rate, no research step. One escalation is the whole rule.
CED is also the only rung that generates a message as well as a verdict — it drafts to Jaimee. A customer escalation is not purely a payroll fact; somebody needs to know it happened.
| CED | Result | Side effect |
|---|---|---|
| 0 | Passes this rung | — |
| > 0 | Ineligible | Draft to Jaimee |
Rung 8. Over 3000 defects per million is the trigger — but on its own it proves nothing. A DPMO is a rate, and the number can spike off a single erroneous or out-of-their-control package. So rather than accept the number at face value, the rule asks the question the number cannot answer: of that driver's exceptions that week, how many were genuinely theirs?
A SIM'able exception is one that was not within the DA's control — the kind Ripple takes to Amazon to have excluded from the DSP's metrics. That data is already pulled from logistics.amazon.com every day for its own reasons, which is what makes this gate possible at no extra cost.
So the useful figure is the inverse: the non-SIM'able count, the exceptions that really were on the driver.
| Non-SIM'able TBAs that week | Reading | Result |
|---|---|---|
| > 1 | Real controllable failures | Ineligible |
| 0 or 1 | Everything was SIM'able — outside their control | Cleared |
Three situations must never be confused with a clean result. "No data" and "checked, came back clean" look identical if you only count rows — they are opposite answers, and only one of them should pay.
| Situation | What happens |
|---|---|
| No SIM data for that station/week | Exclusion stands — this is DII5 today |
| SIM week present but missing days | Exclusion stands |
| SIM rows still marked "Needs Research" | Exclusion stands until reviewed |
| Complete data, 0–1 non-SIM'able | Cleared |
Recomputing the DPMO from the non-SIM'able TBAs was tried, and measured. The implied defect count matches the non-SIM'able count within ±1 for only 24 of 39 W37 drivers. The two datasets overlap but they do not describe the same packages — so substituting one into the other's formula would invent a number and put it on payroll. The gate uses the SIM data to answer a yes/no question it can actually answer, and leaves the DPMO alone.
no_data there and DII5 keeps behaving exactly as it did — flat
over 3000 excludes. The rule is identical on both stations; only the input
is missing. The path is already defined and waiting
(tools/sim-data/data/DII5_W<NN>_<YYYY>/), so the gate starts working on its
own the day a DII5 pull exists, with no code change.
| Kind | Lives on |
|---|---|
| DSB events — simultaneous deliveries, delivered > 50 m, no POD, incorrect scan usage | Quality (rung 10) |
| Customer feedback — CDF DPMO | Quality (rung 9) |
| A package scanned, not delivered and not returned — a genuinely missing package | Quality — it routes to a person, not a rule |
| Physical package, vehicle or property damage | Damage (rung 1) |
Most completion defects come from the same handful of situations, and each has a correct path in the Flex app. Taking the right one is usually the difference between a documented exception and a defect. Full step-by-step for every one of these is in Ripple Resources.
| Situation | Correct path |
|---|---|
| Package missing | “?” → Return Items → Package Missing → the correct TBA |
| Cannot find the address | Other maps app → call → call or text again → Unable to Deliver → Unable to Locate |
| Animal on the property | Horn → call → call or text again → Unable to Deliver → Unsafe Due to Dog |
| Package damaged | “?” → Return Items → Package Damaged → the correct TBA |
| Cannot get into the building | Check notes → call → call or text again → Unable to Deliver → Unable to Access |
| Unsafe road or driveway | Call → call or text again → Unable to Deliver → Due to Bad Weather |
| Customer unavailable | See Ripple Resources |
| Business closed | See Ripple Resources |
| No safe location | See Ripple Resources |
| Rogue packages | See Ripple Resources |
| Reattempt delivery | See Ripple Resources |
rules.py (CED_MAX, DC_DPMO_MAX). SIM gate
behaviour from sim_gate.py and
references/ripple-bonus-rules-at-a-glance.md. Field paths from
Ripple Resources. Last checked 2026-09-20.