Give the on-time result its eligible denominator, and show pending and unclassifiable orders beside it. A dispatch record is a separate event; it cannot supply a missing actual arrival.
Declare a date-only rule
Original fictional order ledger, as of October 13, 2026. This exercise compares calendar dates. Arrival on or before the promised date is on time; arrival after it is late. There is no early-arrival restriction and no late tolerance. No times, shipment quantities or actual customer records are supplied.
| Order | Promised arrival | Actual arrival | Classification at snapshot |
|---|---|---|---|
| D1 | October 12 | October 12 | Arrived; on time |
| D2 | October 12 | October 13 | Arrived; late by one calendar day |
| D3 | October 12 | Missing | Overdue; awaiting recorded arrival |
| D4 | Unknown | October 13 | Arrived; cannot classify timeliness |
D3 is past its promised date with no arrival evidence in this ledger. Do not call it delivered. D4 has arrival evidence but lacks the promised date needed for a timeliness comparison. Do not turn its unknown promise into a zero-day delay.
Calculate the completed-arrival result
The arrived set is D1, D2 and D4: three orders. The fully classifiable arrived set is D1 and D2: two orders. Only D1 meets the declared on-time rule.
The result is 1 on-time order ÷ 2 classifiable arrivals = 50%. Label it on-time rate among classifiable arrivals and list D1/D2 as its denominator. D2's recorded lateness is October 13 minus October 12: one calendar day.
Using 1 ÷ 4 = 25% would instead report the share of the four-order cohort already documented as arrived on time. It is a different measure, not the completed-arrival on-time rate. If the business needs that measure, give it that explicit name rather than silently replacing the denominator.
Put coverage beside the rate
Of the four supplied orders, two can currently receive a completed-arrival timeliness classification. Classification coverage is 2 ÷ 4 = 50% of this cohort. That percentage happens to equal the on-time rate here, but its numerator, denominator and meaning differ.
Show these quantities together:
- Cohort: D1–D4, four orders.
- Arrived: D1, D2 and D4, three.
- Classifiable arrivals: D1 and D2, two.
- Overdue awaiting arrival: D3, one.
- Arrived with missing promise: D4, one.
These labels are not all mutually exclusive categories to add together. Arrived includes both classifiable arrivals and D4. Use the IDs to reveal the relationships rather than presenting a row of unexplained totals.
Preserve the source events and policy
IBM's historical on-time delivery report documentation compares planned or appointment arrival with actual arrival, includes tolerance settings and uses reported orders as its on-time percentage denominator. This original date-only exercise applies its own stated rule, not an exact implementation of that report.
Keep order ID, promised arrival, actual arrival and dispatch details in separate ledger fields. A recorded dispatch does not establish arrival at the destination. Do not invent dispatch dates for these four orders or calculate transit time from absent departure evidence.
If an arrival or promise is corrected in the maintained ledger, recompute the affected scopes from the corrected record. Record the snapshot and rule used. The review design can expose arrived, pending and unclassifiable records locally; the companion is a local review display, not live shipment tracking.
No ordered or delivered quantities are provided, so this example cannot establish an on-time-in-full result. Four fictional orders also do not support a whole-carrier grade, a route prediction or a promised service improvement.
Copy an arrival-reconciliation brief
Create one complete, self-contained US-English HTML companion for “Arrival ledger • promise and coverage”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for All orders; Arrived; Awaiting arrival; Missing promise; Classifiable arrivals; Recalculate date; Restore October 13. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Prepare a logistics dashboard specification in US English.
Maintained order ledger/workbook and required format: [enter]
Order IDs, promised arrival, actual arrival and separate dispatch fields: [paste]
Snapshot date and date/time basis: [enter]
Early/late tolerance and classification rule: [paste or TO CONFIRM]
Chosen cohort and filters: [enter]
Classify timeliness only when promised and actual arrival values are present
under the supplied rule. Keep awaiting arrival and arrived-but-unclassifiable
orders visible. Do not infer arrival from dispatch or impute missing dates. Show the exact on-time numerator and classifiable-arrival denominator. Report classification coverage separately, naming its cohort denominator. Expose IDs and overlapping groups; do not add every displayed group together. Do not claim on-time-in-full without quantities, carrier performance from
insufficient evidence, live tracking or route predictions.
Return checked source rows, calculations and labeled review views in the
required format. If requested, specify a sanitized HTML snapshot with local
scope selection. No shipment-status editing, system connection, automatic
notifications, saved record changes or live-map promises.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Logistics Dashboard Template: Show Which Arrivals Can Actually Be Classified
Three orders have arrived, but only two have a recorded promised date. Reporting an on-time percentage over all three arrivals would hide the missing comparison. Dividing by every order would mix unfinished deliveries with completed outcomes.
Give the on-time result its eligible denominator, and show pending and unclassifiable orders beside it. A dispatch record is a separate event; it cannot supply a missing actual arrival.
## Declare a date-only rule
**Original fictional order ledger, as of October 13, 2026.** This exercise compares calendar dates. Arrival on or before the promised date is on time; arrival after it is late. There is no early-arrival restriction and no late tolerance. No times, shipment quantities or actual customer records are supplied.
| Order | Promised arrival | Actual arrival | Classification at snapshot |
| --- | --- | --- | --- |
| D1 | October 12 | October 12 | Arrived; on time |
| D2 | October 12 | October 13 | Arrived; late by one calendar day |
| D3 | October 12 | Missing | Overdue; awaiting recorded arrival |
| D4 | Unknown | October 13 | Arrived; cannot classify timeliness |
D3 is past its promised date with no arrival evidence in this ledger. Do not call it delivered. D4 has arrival evidence but lacks the promised date needed for a timeliness comparison. Do not turn its unknown promise into a zero-day delay.
## Calculate the completed-arrival result
The arrived set is **D1, D2 and D4: three orders**. The fully classifiable arrived set is **D1 and D2: two orders**. Only D1 meets the declared on-time rule.
The result is **1 on-time order ÷ 2 classifiable arrivals = 50%**. Label it **on-time rate among classifiable arrivals** and list D1/D2 as its denominator. D2's recorded lateness is October 13 minus October 12: **one calendar day**.
Using **1 ÷ 4 = 25%** would instead report the share of the four-order cohort already documented as arrived on time. It is a different measure, not the completed-arrival on-time rate. If the business needs that measure, give it that explicit name rather than silently replacing the denominator.
## Put coverage beside the rate
Of the four supplied orders, two can currently receive a completed-arrival timeliness classification. **Classification coverage is 2 ÷ 4 = 50% of this cohort.** That percentage happens to equal the on-time rate here, but its numerator, denominator and meaning differ.
Show these quantities together:
- **Cohort:** D1–D4, four orders.
- **Arrived:** D1, D2 and D4, three.
- **Classifiable arrivals:** D1 and D2, two.
- **Overdue awaiting arrival:** D3, one.
- **Arrived with missing promise:** D4, one.
These labels are not all mutually exclusive categories to add together. Arrived includes both classifiable arrivals and D4. Use the IDs to reveal the relationships rather than presenting a row of unexplained totals.
## Preserve the source events and policy
[IBM's historical on-time delivery report documentation](https://www.ibm.com/support/pages/time-delivery-summary-report) compares planned or appointment arrival with actual arrival, includes tolerance settings and uses reported orders as its on-time percentage denominator. This original date-only exercise applies its own stated rule, not an exact implementation of that report.
Keep order ID, promised arrival, actual arrival and dispatch details in separate ledger fields. A recorded dispatch does not establish arrival at the destination. Do not invent dispatch dates for these four orders or calculate transit time from absent departure evidence.
If an arrival or promise is corrected in the maintained ledger, recompute the affected scopes from the corrected record. Record the snapshot and rule used. The review design can expose arrived, pending and unclassifiable records locally; the companion is a local review display, not live shipment tracking.
No ordered or delivered quantities are provided, so this example cannot establish an on-time-in-full result. Four fictional orders also do not support a whole-carrier grade, a route prediction or a promised service improvement.
## Copy an arrival-reconciliation brief
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Check D3's absent arrival and D4's absent promise before presenting the 50% result. Keep the order ledger as the maintained source, and obtain the missing evidence before assigning either order a completed-delivery timeliness outcome.