ENGINEERING PATTERN

Hierarchical State Derivation

Derive historical parent state from independently changing child entities.

Parent histories such as policies, portfolios or departments must be rebuilt from child timelines and explicit business aggregation rules.

Problem

The parent entity has no direct historical state.

In many source systems, business state exists at a lower level than the reporting entity. Contracts have status history, while the policy status must be derived from all contracts belonging to the policy.

This is not a simple current-state aggregation. The parent timeline must be reconstructed from every relevant child boundary.

If child changes are skipped, the derived parent state can change too early, too late or become impossible to explain.

Child → parent derivationGenerated parent intervalsStatus priority rulesHidden child boundariesUnstable rollups

Interactive example

A policy state is derived from two contracts that become annulled at different times.

Compare a boundary-aware derivation with a naive rollup and an unresolved mixed-state rule.

Child histories

Contract A

Jan → Apr

Active

Contract A

Apr → ∞

Annulled

Contract B

Jan → Jun

Active

Contract B

Jun → ∞

Annulled

Derived parent state

The parent state changes at every child boundary

Policy historyActive → Active → Annulled

All contract boundaries are collected first. The policy is Active while at least one contract remains Active and becomes Annulled only after all child contracts are annulled.

Key idea

Never derive a historical parent state from one current child snapshot. Rebuild the shared timeline first, then apply the business rule interval by interval.

Core concepts

Child timelines define the boundaries; business rules define the parent value.

Hierarchical State Derivation first aligns all child state histories into common non-overlapping time slices.

Each slice is then probed for active child states and evaluated through a documented rule such as “Active if at least one child is Active.”

Build common child intervals

Collect every relevant valid_from and valid_to boundary and create non-overlapping parent-level slices.

Probe child states per interval

Evaluate which child states are valid inside each derived parent interval.

Apply business rules

Use explicit priority, threshold or aggregation semantics to derive the parent value.

Persist derivation evidence

Store the rule and contributing child states so the result remains explainable.

Example rule

If at least one contract is Active, the policy is Active.

January → April

Contracts A and B are Active, so the policy is Active.

April → June

Contract A is Annulled, but Contract B remains Active. The policy stays Active.

From June

Both contracts are Annulled, so the policy becomes Annulled.

Derived parent history

valid_from | valid_to | policy_status | evidence
Jan        | Apr      | Active        | A and B active
Apr        | Jun      | Active        | B still active
Jun        | ∞        | Annulled      | all contracts annulled

Why it happens

Children change independently while the parent is reported as one entity.

Contracts, accounts, positions or organizational units can start, end or change status on different dates.

A parent-level report compresses those separate histories into one derived state, which requires complete temporal alignment and an explicit aggregation rule.

Independent child historiesChanging hierarchiesMixed child statesTemporal aggregationDerived reporting attributesRule versioning

Common modeling approaches

Build parent history from atomic child-aligned intervals.

Boundary union

Create the parent timeline from the union of all child state boundaries.

Interval probing

Resolve child states inside every parent-level time slice.

Priority or aggregation rule

Apply explicit semantics such as any-active, all-closed or highest-severity.

Rule versioning

Historize derivation logic when business aggregation semantics change.

Validation checks

Historical derivation should be complete, deterministic and explainable.

✓ All child state boundaries are represented✓ Every parent interval has one deterministic value✓ Priority rules are explicit and testable✓ No child status change is hidden✓ Bitemporal visibility is preserved when required✓ Derived attributes can be explained from source evidence✓ Rule changes are versioned

Why it matters

Hierarchical derivation keeps parent reporting consistent with child history.

Without time-aware derivation, a parent state can contradict the child states that actually existed during the same period.

With atomic intervals and explicit rules, every parent state is reproducible and traceable to its contributing children.

This is essential for policy, portfolio, account and organizational reporting where the parent is not maintained as an independent source state.

RELATED TEMPORAL MODELS

How Hierarchical State Derivation connects to other historical patterns

Hierarchical derivation combines temporal alignment, relationship history and state modeling to produce one parent-level history.

State Modeling

Provides the interval representation used for child and derived parent state.

Relationship History

Defines which children belong to the parent during each historical period.

State–State Alignment

Aligns independently changing child histories at all relevant boundaries.

Rectangle Decomposition

Creates atomic temporal regions before complex derived state is resolved.

Related Patterns

State Modeling Relationship History State ↔ State Alignment Rectangle Decomposition Event-to-State Projection

Try it

Review a hierarchical historical derivation.

Use the Historical Data Assistant to reason about child boundaries, parent aggregation rules, changing hierarchies and derived state reproducibility.

Open Historical Data Assistant →