State Reduction

Operational history often contains more state changes than reporting needs.

Source systems may store technical refreshes, temporary workflow states, repeated values or intermediate transitions.

If every source version is carried into the reporting model, the resulting history becomes fragmented, expensive to query and difficult to explain.

State Reduction separates real business transitions from operational noise while preserving the original audit history.

A detailed workflow history is reduced to reporting-relevant states.

Reduce only consecutive versions with the same business meaning.

Reduction compares the attributes that define the published business state, not every technical column in the source.

Adjacent equivalent versions can be merged into one interval when their boundaries connect under the confirmed interval semantics.

Equal states separated by a different state remain separate historical episodes and must never be merged across that change.

Analyze this State Reduction example

Use these sample target tables to test whether redundant historical versions were reduced safely:

1. Select one of the target tables below.
2. Start an investigation with the example data.
3. Confirm the closed-open valid-time semantics.
4. Check whether compaction preserves the same historical state.

contract_id,status,valid_from,valid_to,reduction_status
C1,Draft,2024-01-01,2024-01-12,reduced
C1,Submitted,2024-01-12,2024-01-20,reduced
C1,Approved,2024-01-20,9999-12-31,reduced

contract_id,status,valid_from,valid_to,reduction_status
C1,Draft,2024-01-01,2024-01-03,redundant_state
C1,Draft,2024-01-03,2024-01-07,redundant_state
C1,Draft,2024-01-07,2024-01-12,redundant_state
C1,Submitted,2024-01-12,2024-01-13,redundant_state
C1,Submitted,2024-01-13,2024-01-20,redundant_state
C1,Approved,2024-01-20,9999-12-31,reduced

Source state and reporting state are not always the same thing.

Operational systems capture workflow detail, retries, refreshes and temporary states. Reporting models usually need stable business states at a coarser grain.

The reduction rule defines which attributes and transitions change analytical meaning and which versions remain only in raw history for audit and debugging.

Preserve raw history, but publish reduced reporting state.

Validate that reduction removes noise without losing business meaning.

State Reduction turns operational history into analytical history.

Compact histories are easier to query, cheaper to store and simpler to validate.

Without a controlled reduction rule, historical models can be technically accurate but analytically unusable.

How this pattern relates to other temporal models

State Reduction is usually applied after raw temporal ingestion or rectangle decomposition and before publishing reporting history.

It bridges detailed operational history and the stable temporal grain required by analytical models.