# A completion counter that resets inside a period

Illustrative planning brief; no automatic product import.

Synthetic case: The known counter is 10 at period start, 13 just before a zero reset, 0 after the reset and 4 at period end. Both epochs are complete in the invented log.

## Decision

Count 3 events before reset plus 4 after reset, yielding 7; hold reconstruction if the pre-reset boundary is missing.

## Owned work

- Verify epoch boundaries
  - Owner role: Data owner
  - Acceptance evidence: The reset and both boundary values are recorded without a missing interval.
- Calculate within epochs
  - Owner role: Reviewer
  - Acceptance evidence: 13−10=3 and 4−0=4 are separate within-epoch changes.
- Label reconstruction limits
  - Owner role: Report owner
  - Acceptance evidence: Seven depends on complete epoch boundaries; unknown reset loss remains unknown.

## Workflow

1. Inspect whether the measure is cumulative or a current-state gauge.
2. Separate epochs at known resets.
3. Sum only evidenced within-epoch increments and disclose missing boundaries.

## Judgment

The manual ledger assumes complete reset boundaries. Scrape gaps and unknown increments can prevent exact reconstruction; no PromQL extrapolation is implemented.


## Filled review note

Epoch note: 3 before reset plus 4 after reset equals 7 under complete boundary evidence. If the pre-reset count is unknown, the exact total is held.


## Workflow questions

### Why not subtract 4−10?

Those endpoints belong to different counter epochs. Their negative difference is not a negative completion count.

### Can I assume the last sampled value was the pre-reset total?

No. If observations missed increments, exact reconstruction is unavailable.

## Product connection

Bring this manual reporting policy and its owned checks into your TeamBoostAI work discussion. Native report/export fields and historical reconstruction depend on your account and implementation; this worksheet does not import or change product records.

Confirm account availability before adopting this manual outline.

## Decision workshop

Synthetic examples only. Manual worksheet; no automatic import or product writes.

### Synthetic reporting records

Observation | Counter epoch | Count
--- | --- | ---
Period start | Epoch 1 | 10
Known pre-reset boundary | Epoch 1 | 13
Reset | Epoch 2 | 0
Period end | Epoch 2 | 4

### Version changes

Boundary | Draft | Revised
--- | --- | ---
Epoch handling | One subtraction across reset | Separate within-epoch differences
Coverage | Missing observations silently assumed complete | Exact reconstruction requires complete boundaries

### Draft or earlier version (review its limits)

Draft: period count 4−10=−6.

### Revised example

Epoch note: 3 before reset plus 4 after reset equals 7 under complete boundary evidence. If the pre-reset count is unknown, the exact total is held.

### Decision situations

- Both epoch boundaries are known and complete: Show the separate increments and their sum.
- A pre-reset observation may miss increments: Report known observations and hold the exact period total.
- The value can freely rise and fall: Treat it as a state observation, not this cumulative counter policy.

### Evidence dependencies

- Complete epoch 1 → Period increments: 3 events
- Complete epoch 2 → Period increments: 4 events

### Method references

- Prometheus metric types: https://prometheus.io/docs/concepts/metric_types/ — Counter and gauge definitions only; this worksheet is not a PromQL recipe or a TeamBoost integration.