Interactive Pattern

Hierarchical State Derivation

A policy has multiple historized contracts. The policy status is not stored directly. It must be derived from the contract states over time.

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, but the policy status must be derived from all contracts belonging to the policy.

This is not a simple aggregation. The parent timeline must be rebuilt from child timelines, and business rules decide which derived state is valid in each interval.

Child → parent derivationStatus priority rulesGenerated parent intervalsBitemporal state projection

Example

Contract states are historized. Policy status is derived.

Contract A

Active

Annulled

Contract B

Active

Annulled

Derived Policy

Active

Annulled

Derivation rule

The policy remains active until all related contracts are annulled. The parent state changes in June, not in April, because Contract B is still active.

Common mistake

Do not derive the parent state from only one child row.

Naive derivation

Input

Contract A becomes annulled in April

Assumption

Policy becomes annulled in April

Problem

Contract B is still active

Wrong.

This copies one child status to the parent and hides the remaining active child state.

Correct derivation

Rule

Any active contract → Policy active

May state

Contract B is still active

Result

Policy remains active until June

Correct.

The parent state changes only when the rule result changes across all relevant child states.

Interactive decision

What should the policy status be in May?

Contract A is already annulled in May. Contract B is still active until June. Apply the rule: the policy is active if at least one contract is active.

Child states in May

Contract A

Annulled

Contract B

Active

Rule

Any active contract → Policy active

Choose derived parent state

Pick the status that should be generated for the parent policy interval.

Key idea

Derive parent states by probing historized child states.

Hierarchical State Derivation creates a historized parent attribute from multiple historized child entities. The child records define the timeline boundaries. The business rules define the derived parent value.

In your internal implementation this may look like a function such as probe_by_attribute: generate time slices, probe child values in each slice, apply rules, and output new parent intervals.

Example rule

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

Rule 1

Any active contract → Policy active

Rule 2

All contracts annulled → Policy annulled

Output

Bitemporal policy status intervals

Child state input

Contract states define the parent timeline.

Child entity	Valid period	Status
Contract A	Jan → Apr	Active
Contract A	Apr → ∞	Annulled
Contract B	Jan → Jun	Active
Contract B	Jun → ∞	Annulled

Derived parent state

The policy status changes only when the derived rule result changes.

Policy interval	Policy status	Reason
Jan → Apr	Active	A and B active
Apr → Jun	Active	B still active
Jun → ∞	Annulled	All contracts annulled

Why it happens

Source systems often store operational detail below the reporting grain.

Insurance

Policy status is derived from multiple contract, coverage or risk-object states.

Orders

Order state is derived from line-item, shipment or cancellation states.

Subscriptions

Customer subscription state is derived from multiple products or service components.

Claims

Case status is derived from multiple claim parts, decisions or processing steps.

Typical approach

Generate parent intervals before applying business rules.

Build common child intervals

Collect all relevant valid_from and valid_to boundaries from child entities and build non-overlapping parent-level intervals.

Probe child states per interval

For each parent interval, evaluate which child states are valid inside that time slice.

Apply business rules

Derive the parent attribute from child states using explicit priority or aggregation rules.

Persist derived evidence

Store the rule, source entities or derivation method so the parent state can be explained later.

Validation checks

Before publishing the derived state, validate the derivation.

✓ All child state boundaries are represented✓ Every parent interval has a deterministic derived value✓ Priority rules are explicit and testable✓ No child status change is hidden by a parent interval✓ Bitemporal visibility is preserved if corrections arrive✓ Derived attributes can be explained from source evidence

Why it matters

Without explicit derivation, parent state becomes unstable or unexplainable.

A policy may look active, cancelled or suspended depending on which contract row was joined first, which status was prioritized, or which child history was visible at the time of publication.

Hierarchical State Derivation makes the business rule explicit. The parent state is no longer an accidental side effect of joins, but a reproducible historical data product.

Related Concepts

This pattern connects several historical modeling problems.

Rectangle Decomposition

Child state boundaries often need to be decomposed into common non-overlapping intervals.

State Reduction

Multiple lower-level states are reduced into one parent-level state.

Relationship History

The relationship between parent and child entities must itself be valid over time.

Bitemporal Modeling

Derived parent states may need valid-time and visible-time semantics.

Related Patterns

Rectangle Decomposition State Reduction Relationship History Bitemporal Modeling State ↔ State Alignment

Try it

Review your own model for derived state risks.

Paste SQL, PySpark, dbt model logic or an architecture description and check whether derived parent states are explicit, explainable and historically reproducible.

Review My Model →