Endorse Policy Transaction

Applies an ENDORSE transaction to an existing policy. An endorsement carries one or more of five channels. The engine recomputes segments after applying every channel — adjacent segments with identical data are automatically merged — and the response includes the full resulting segment set.

Input channel:

• deltas — changes to policy field data. Each carries its own startDate / endDate within the policy term, a path, an action (Add / Remove / Overwrite), and a value.

Amending the term. Shortening a term is a deltas write to the ROOT policy.policyEndDate (or policy.policyStartDate) stating the whole term as its window. There is no separate policy-info channel — the retired fullTermDeltas container channel was removed once the root fields became the single writable source.

Whole-term policy fields. Four ROOT paths hold values that are invariant across the policy term — policy.policyNumber, policy.policyStartDate, policy.policyEndDate and policy.previousPolicy. A delta on deltas that touches one of them (at any depth, and including an ancestor path such as a whole-policy Overwrite) must state the whole term as its window (startDate = the policy start, endDate = the policy end) or the write is rejected.

A term bound may not move outward, through either input channel and at any path depth: moving policyEndDate later or policyStartDate earlier is rejected (TermLengtheningNotSupported), because no endorsement path can create the extra days.

Date values. A deltas value written to a Date field — at any depth, including a Date nested inside a custom object or an embedded exposure — must be the canonical { date: "YYYY-MM-DD", timezone } object (the Fmv1Date schema) with both members stated. Delta values are stored exactly as sent, so this channel never converts: the retired { day, month, year, timezone } spelling is refused (400, InvalidDelta), and so is a write to a single member of a Date (policy.policyEndDate.year) — a Date is written whole.

Derived channels (additive on either input channel):

• fullTermPricingInfo — whole-object overwrite of the policy-root pricing contract. Supply pricingComponents (each {label, value, classification[, qualifier, earningSchedule]} — every component must name a live classification from your company’s classification registry); the four rollups (premium, taxes, fees, total) are computed by the platform from the components — any caller-supplied rollup value is ignored and recomputed.
• fullTermBillingInfo — whole-object overwrite of the policy-root Billing Aggregate: { lines: [{ invoiceType, lineItem, direction, amount }] }, the term’s billing obligations free of invoices, with no rollup and no classification. An endorsement that moves the price must restate these lines: a stated aggregate’s receivable lines must sum to fullTermPricingInfo.total, so moving the price without restating them is refused.
• fullTermPolicyRatingResult — whole-object overwrite of the policy-root canonical rating result (the twin of fullTermPricingInfo).
• crossSegmentRatingOutputs — element-level rating output, [{ path, value }]. Each path terminates at a crossSegmentRatingOutputs container on a list element (or the policy); value is the whole rating-output object for that host. There is no action (always an Overwrite) and no dates — the server derives each write’s range from the host’s presence across segments, so it applies cleanly to part-term hosts.

At least one channel is required — satisfied by any of deltas, fullTermPricingInfo, fullTermBillingInfo, fullTermPolicyRatingResult or crossSegmentRatingOutputs. An endorsement that restates only the Billing Aggregate is therefore a legal transaction on its own.

Path syntax — predicate addressing. Index into a list by a predicate on any field: policy.exposures[id = '<uuid>'].bedCount, policy.coverages[coverageType = 'GL'].limits[name = 'occurrence']. The predicate must resolve to exactly one element wherever it is applied (throws on zero or multiple matches) — this uniqueness rule is the cross-segment identity guarantee.

Policy invoices. Optionally send invoicePlan, a fully explicit keep/void/create plan. Nothing is defaulted or inferred. Once active invoices exist, a pricing restatement must carry a conserving plan for the new target; the version and invoices commit atomically.

Required permission: policy.endorse