Prop Filled Quantity: Cumulative Snapshots Are Not New Executions
A filled-quantity field can be cumulative for an order rather than a new execution amount. Read the schema before adding rows. Summing successive totals can overstate account activity even when every exported number is accurate.
Explore this site’s existing research resource
Identify the field’s aggregation level
Record the account, order, product, quantity unit and whether the value is incremental or cumulative. Preserve the source definition and observation order. A field rename or export-format change can require a new interpretation rather than a reused formula.
For a fictional cumulative sequence 0,2,2,5, the increments from the supplied zero baseline are 0,2,0,3. The unchanged second 2 is another snapshot of the same total, not another two-unit fill. A full order key is needed before comparing the rows.
Reconcile the final quantity
The final supplied cumulative total is 5. Adding the raw snapshots gives 9, which counts earlier activity again. The increment sum is 5 when the sequence is valid and the starting baseline is known. Unique execution rows, if supplied, can provide another reconciliation path.
A decrease in a cumulative field might indicate a correction, reset or another scope. It should not automatically be treated as a negative execution. Retain the discrepancy and actual source definition. Without an initial baseline, the observed delta window is not necessarily the order’s whole history.
| Snapshot | Cumulative filled | New increment |
|---|---|---|
| First | 0 | 0 |
| Second | 2 | 2 |
| Third | 2 | 0 |
| Fourth | 5 | 3; total increments 5 |
Keep the account consequence separate
The related resource preserves this site’s original cumulative-snapshot audit. A Canadian report still needs original units and any explicit CAD conversion for cash amounts. Quantity alone does not supply execution prices, fees or a completed account result.
The optional sponsored HashHedge link offers current programme rules. This page reads no private order and performs no trade. The example provides a reliable five-unit subtotal under its stated schema without presenting it as qualifying activity or successful evaluation evidence.
Sources and rule dates
- HashHedge: challenge types
Checked 2026-10-23. Selected published description only. Worked numbers and event records are fictional; no actual provider account, search result, live price, eligibility or payment is established. - HashHedge: daily loss calculation
Checked 2026-10-23. Selected published description only. Worked numbers and event records are fictional; no actual provider account, search result, live price, eligibility or payment is established. - HashHedge: terms and conditions
Checked 2026-10-23. Selected published description only. Worked numbers and event records are fictional; no actual provider account, search result, live price, eligibility or payment is established.