effectiveDate, transactionTimestamp, and each delta’s startDate relate, see Effective Dates & the Policy Timeline.
Scenario
Delta Actions Reference
Premiums and Billing
Policy financial data lives at two levels: per-segment rating and full-term billing.Per-Segment Rating
Each segment carries its own rating data — a per-segmentratingResponse on the policy and on each exposure. (These illustrative fields are tenant-configured per-segment fields, distinct from the reserved crossSegmentRatingOutputs container, which is invariant across its host’s span.) They typically include:
annualPremium— the premium as if that segment’s state applied for the full policy yeardailyProratedPremium— the daily premium rate for that segment’s risk profile
Full-Term Pricing
fullTermPricingInfo is a cross-segment invariant — it’s identical across every segment in a version. It is the pricing contract for the entire policy term: pricingComponents plus five server-computed, read-only rollups (premium, taxes, fees, brokerCommission, programCommission — each the sum of its kind’s components). You send the components:
fullTermPricingInfo channel (a whole object applied across the full policy term, not just the endorsement effective date). This keeps the pricing contract current.
fullTermPricingInfo is not necessarily derivable from per-segment rates. Full-term pricing can include flat premium minimums, surplus lines taxes, policy fees, or other adjustments that are independent of per-segment rating. The fullTermPolicyRatingResult (a separate policy-root container) captures these aggregate rating details.Minimal vs Full Tracking
In This Walkthrough
Each transaction below includes structural per-segment deltas, per-segmentratingResponse rating on the policy and exposures, and the fullTermPricingInfo update. The segment tables include a Policy Annualized Premium column — notice that this per-segment rate typically does not match the fullTermPricingInfo.premium rollup shown below each table.
Creation
Transaction 1 — NEW_BUSINESS
Transaction 1 — NEW_BUSINESS
Effective: Jan 1 · Version: 1Initial policy creation. One exposure (Main Campus), three named physicians.Segments (1):
Request
fullTermPricingInfo rollups: Premium 85,000 · Taxes 4,250 · Fees 500 · Total 89,750With a single full-year segment, the annualized premium matches the billing premium. This won’t last.
Endorsements
Transaction 2 — ENDORSE: Add satellite clinic
Transaction 2 — ENDORSE: Add satellite clinic
Effective: Apr 1 · Version: 2A satellite clinic opens April 1. The new exposure is Added to the collection. The Apr–Dec segment gets updated rating reflecting the additional exposure. Jan–Mar rating is unchanged — the risk profile didn’t change, only the segment’s duration.Segments (2):
deltas
fullTermPricingInfo
+1fullTermPricingInfo rollups: Premium 98,000 · Taxes 4,900 · Fees 500 · Total 103,400The annualized premiums are 85,000 and 104,000 — neither matches the billing premium of 98,000. The billing total reflects the blended cost across both periods plus a flat surplus lines assessment.
Transaction 3 — ENDORSE: Add physician + specialty
Transaction 3 — ENDORSE: Add physician + specialty
Effective: Jun 1 · Version: 3A new surgeon (Dr. Okafor) joins the main campus June 1. Neurology added as a covered specialty. Both deltas use Add on nested exposure fields. Rating updated for Jun–Dec where the risk profile changed; Apr–May is unchanged.Segments (3):
deltas
fullTermPricingInfo
+1fullTermPricingInfo rollups: Premium 106,000 · Taxes 5,300 · Fees 500 · Total 111,800The Apr–Dec segment from version 2 split at the June boundary. Three different annualized rates (85k, 104k, 118k) but a single billing premium of 106k.
Transaction 4 — ENDORSE: Remove physician, reduce beds
Transaction 4 — ENDORSE: Remove physician, reduce beds
Effective: Jun 1 · Version: 4Dr. Nguyen leaves the practice effective June 1. 10 beds decommissioned. Uses Remove on a primitive collection and Overwrite on a scalar.Segments (3):
deltas
fullTermPricingInfo
unchangedfullTermPricingInfo rollups: Premium 101,000 · Taxes 5,050 · Fees 500 · Total 106,550Same segment count — the boundaries didn’t move, only the Jun–Dec data and rate changed. The annualized rate dropped from 118k to 112k reflecting fewer beds and one fewer physician.
Transaction 5 — ENDORSE: Backdate corrections to Apr 1
Transaction 5 — ENDORSE: Backdate corrections to Apr 1
Effective: Apr 1 · Version: 5Internal audit reveals the bed decommissioning actually happened in April, not June. Dr. Nguyen’s departure was also effective April 1. Dr. Okafor started in April too. Retroactive corrections applied.Segments (3):
deltas
fullTermPricingInfo
unchangedfullTermPricingInfo rollups: Premium 100,000 · Taxes 5,000 · Fees 500 · Total 105,500The structural deltas span Apr 1 – Dec 31, but the Jun–Dec segment already had beds=110, Nguyen removed, and Okafor present — no-ops there. Only Apr–May changed. Segment 2’s annualized rate is 108,000 (vs segment 3’s 112,000) because it lacks Neurology.
Setup for what’s next: Segments 2 and 3 now share the same beds, physicians, and exposures. They differ only in whether Neurology is a covered specialty — which also produces different annualized rates (108k vs 112k). One more endorsement that adds Neurology to segment 2 will converge both the structural data and the rating.
Transaction 6 — ENDORSE: Retroactive Neurology → MERGE
Transaction 6 — ENDORSE: Retroactive Neurology → MERGE
Effective: Apr 1 · Version: 6Neurology coverage was contractually effective from the clinic opening date (April 1), not June 1 as originally recorded. Correction applied retroactively.The Neurology delta adds it to Apr–May. Jun–Dec already has Neurology — no-op. The rating delta updates Apr–May’s annualized rate from 108,000 to 112,000 to match Jun–Dec.After applying, segments 2 and 3 have identical per-segment state — same structural data, same rating. The system merges them.Segments (2):
deltas
fullTermPricingInfo
-1fullTermPricingInfo rollups: Premium 101,000 · Taxes 5,050 · Fees 500 · Total 106,550
Cancellation and Reinstatement
Transaction 7 — CANCEL
Transaction 7 — CANCEL
Effective: Sep 1 · Version: 7Greenfield is acquired by a hospital network with its own coverage. Policy cancelled effective September 1. The system expands the cancellation date into the per-segment Segments (3):
policyStatus flip plus a single cancellationEffectiveOnDate internally — and it computes the money too, so the caller sends only the date.Request
A cancel never reprices — the pricing contract is derived. Every charge keeps its
label/group/kind/earningBasis and drops to what it had earned through September 1: Policy Premium to 72,000, Taxes to 3,600, and the non-refundable Policy Fee — fully earned at inception — untouched at 500. Send fullTermPricingInfo only to ADD a charge (a short-rate penalty, a cancellation fee), and an added charge must carry earningBasis: "fully-earned-at-inception". To change an existing charge, endorse at the same effective date and then cancel: same-date transactions apply in booking order, so the cancellation floors against the corrected figures.Cancel and reinstate take no per-segment deltas — only a date plus the optional whole-object fullTermPricingInfo / fullTermPolicyRatingResult channels. The system handles the date ranges and the status change internally.+1fullTermPricingInfo rollups: Premium 72,000 · Taxes 3,600 · Fees 500 · Total 76,100The Apr–Dec segment split at September. The annualized rate stays 112,000 in both segments — the underlying risk profile didn’t change, only the status. But the billing dropped to 72,000 reflecting the shortened coverage period.
Transaction 8 — REINSTATE → MERGE
Transaction 8 — REINSTATE → MERGE
Effective: Sep 1 · Version: 8The acquisition falls through. Policy reinstated at the same effective date as the cancellation. A 250 reinstatement fee is added.A reinstate restores the pre-cancel contract — every charge, at the value and Segment 3 returns to
earningBasis it carried before the cancellation. So the request states only the ADDED fee; the three restored charges come back on their own. (Send them too if you like, but they must match the pre-cancel values exactly.)Request
"active" — now identical per-segment state to segment 2. They merge.Segments (2): -1fullTermPricingInfo rollups: Premium 101,000 · Taxes 5,050 · Fees 750 (was 500) · Total 106,800
Cancel + Reinstate are invisible in the segments — and in the earned curve. Both transactions are preserved in the audit trail, but the per-segment state is identical to version 6 (pre-cancellation) and every restored charge picks its schedule back up where it left off, so earned premium reads flat straight through the round trip. The only lasting change is the added
Reinstatement Fee, which took fees from 500 to 750. This is the second type of segment reduction: reversal, where an action directly undoes a prior change’s per-segment effects.Transaction Deletion
Transaction 9 — DELETE (undo reinstatement)
Transaction 9 — DELETE (undo reinstatement)
Latest version after delete: 7The acquisition is back on. The reinstatement was premature — delete it.Transaction deletion removes the most recent transaction (the REINSTATE) and its segments. No new version is created — version 7 (the CANCEL version) becomes current again via
MAX(policy_version). The deleted transaction is archived for audit purposes.Segments (3): +1fullTermPricingInfo rollups: Premium 72,000 · Taxes 3,600 · Fees 500 · Total 76,100The deleted transaction still exists in the audit trail — it’s archived, not erased. But the live policy state has reverted to the cancelled state, including the pre-reinstatement billing.
Summary
Segment Count Over Time
Two Types of Segment Reduction
Convergence (Version 6)
Retroactive corrections made the Apr–May segment identical to the Jun–Dec segment — both structurally and in rating. Adjacent identical segments merged.Segments can reduce through normal business operations — corrections, reconciliations, and backdated adjustments that happen to converge per-segment state across a boundary.
Reversal (Version 8)
Reinstatement undid the cancellation, making Sep–Dec identical to Apr–Aug. Adjacent identical segments merged.An action that inverts a prior change can collapse the segments that action created — but the audit trail preserves both transactions.
Key Takeaways
Transactions are authored. Policy state is derived. Segments are compressed representations of per-segment state.Segment count may increase, decrease, or stay the same with each transaction — independently of whether a change was added, corrected, or reversed.
fullTermPricingInfo and other cross-segment invariants do not affect segment boundaries at all — only per-segment data (including per-segment rating) drives merging.