@claritylabs/cl-sdk 3.2.10 → 3.2.11

package/dist/index.js

@@ -4149,9 +4149,11 @@ Task:
 Projection defects to look for:
 - Generic labels such as "Column 3" that should be renamed from nearby row/header evidence.
 - Declaration or section headers projected as coverage names when the row evidence is actually a specific coverage, sub-limit, deductible, retention, retroactive date, or premium.
+- Premium-only, tax-only, fee-only, rating, exposure, reporting-value, or payment-plan rows projected as coverage rows.
 - Dangling continuation punctuation such as a trailing "/" copied into values.
 - Item references such as "shown in Item 7" or bare item numbers treated as money amounts.
 - Policy wording, exclusions, or unsupported prose copied into operational limit/deductible fields.
+- Premium, MGA Fee, taxes, stamping fees, total premium, total due, reporting values, or exposure annual rate used as a coverage limit.
 - Header/value splits where "Limit of Liability", "Deductible", "Retroactive Date", "Aggregate", "Each Claim", or similar terms are attached to the wrong coverage row.
 - Repeated schedule headings projected as separate coverages when they only introduce the next coverage group.
 
@@ -4161,7 +4163,8 @@ Rules:
 - Use sourceNodeIds and sourceSpanIds only from the provided source nodes or from the existing candidate entry.
 - Prefer dropping a malformed fact over speculative rewriting.
 - Keep a coverage when it is a real operational coverage/benefit even if only one term needs cleanup.
-- Never drop a declaration or schedule coverage row that names a coverage and states policy-specific amounts, dates, deductibles, retentions, premiums, or coverage terms. Repair its terms instead.
+- Drop a coverage row when its only facts are premium, tax, fee, rating, reporting-value, exposure, or payment-plan facts and it has no source-backed limit, deductible, retention, retroactive date, sublimit, or benefit term.
+- Never drop a declaration or schedule coverage row that names a coverage and states policy-specific limits, dates, deductibles, retentions, sublimits, or benefit terms. Repair its terms instead.
 - When changing a term's semantic meaning, set kind to the corrected normalized term kind.
 - Do not add new coverage rows or new terms; this pass cleans the existing projection.
 - If one existing term combines multiple real limit bases, such as "Each Claim / Aggregate", keep the combined term unless another existing term already represents the other basis. Do not relabel it to only one basis and lose information.
@@ -5502,8 +5505,10 @@ Rules:
 - When citing an evidence entry, copy its sourceSpanId into the returned sourceSpanIds array.
 - If a value is not directly supported, omit it.
 - Prefer declarations, schedules, premium tables, and endorsement schedules over generic policy wording.
+- For effective, expiration, retroactive, and other date fields, return a normalized YYYY-MM-DD value when the source date is unambiguous, including month-name dates such as "20 Feb 2026". Do not emit fragmented date text such as "20 2 2026".
 - For broker/producer, extract the agency or company legal name, not the license role, credential, or type. In a block like "Bayshore Insurance Brokers, LLC" followed by "Surplus Lines Broker - CA License No. ...", broker.value must be "Bayshore Insurance Brokers, LLC"; the surplus-lines role and license number are not the broker name.
 - On declarations pages, treat "Item N" labels as section boundaries. Use Item 6 or equivalent coverage-schedule rows for coverage limits, deductibles, aggregate terms, and retroactive dates; do not merge Item 7 premium, Item 8 ERP, Item 9 producer, or Item 10 forms into Item 6 coverage facts.
+- Premium, tax, fee, payment-plan, rating, exposure, and reporting-value schedules are billing evidence, not coverage schedules. Extract the total policy premium into premium when supported, but do not create coverages[] entries from premium-only or fee-only rows, and never use Total Premium, MGA Fee, tax, stamping fee, reporting values, or exposure annual rate as a coverage limit.
 - A coverage schedule row's coverage name should come from the "Coverage Part" or equivalent row label. Limit, deductible, aggregate, sublimit, retention, and retroactive-date values belong as nested terms under that coverage, not in the coverage title.
 - If a coverage schedule continues onto the next page before the next item marker, include the continuation rows in the same coverage or declaration item.
 - If one schedule row or continuation row states the same amount with multiple bases, such as "$1,000,000 Each Claim / Aggregate", return separate limit terms for each basis using the same value instead of one combined "Each Claim / Aggregate" term.
@@ -5553,7 +5558,10 @@ var NORMALIZED_COMPATIBILITY_FIELDS = /* @__PURE__ */ new Set([
   "policyNumber",
   "namedInsured",
   "insurer",
-  "broker"
+  "broker",
+  "effectiveDate",
+  "expirationDate",
+  "retroactiveDate"
 ]);
 function valueOf(profile, key) {
   const value = profile[key];