Slots

“We write slot coverage. A slot is the thing we insure, not the physician — the slot stays on the policy all term while the provider occupying it changes. Can AI Insurance handle a slot being assigned, vacated, and reassigned mid-term, and still tell me who occupied it on any given date?”

The short answer

Yes — natively. Slots and slot coverage need no workaround. Different entity types — providers, slots, facilities — attach to a policy as exposures, and each attachment carries its own effective and end dates within the policy term. So a slot can be assigned and reassigned mid-term: the slot stays on the policy for the whole term, and the providers who occupy it come and go underneath it, each with their own dates. Because a policy’s state is resolved as of a date, the policy itself answers “who occupied slot 3 on 1 July?” — you don’t reconstruct it from an endorsement log.

How it’s modelled

A slot is not a special record type. It’s an exposure type — one value in your company’s exposure-type option set, alongside the other things a med mal program insures:

Exposure type	What it represents	Typically carries
Slot	The insured unit of capacity — the thing the limit and premium attach to.	Slot number, coverage form, limits, retroactive date, class/specialty rating basis.
Healthcare Provider	An individual physician, surgeon, CRNA, or allied provider.	Licence number, specialty, board certification, claims history, hours or patient volume, part-time flag.
Company / Facility	The insured entity itself — a practice, hospital, or clinic.	Legal name, tax ID, address, entity-level exposure counts.

All three are exposures, so all three get the things exposures get: their own detail page, their own cross-reference tabs (the quotes, policies, submissions, and claims that touch them), files, notes, and contacts. Slot coverage forms live in the policy-type option set, which is where a med mal program distinguishes the slot-specific forms from the ordinary ones — for example Slot Coverage – Claims Made, Slot Coverage – Occurrence, and Slot Coverage “Tail” (Reporting Endorsement) alongside the standard Claims Made, Occurrence, and Nose/Tail values.

These names are illustrations of a typical med mal configuration — the exposure types, field names, and option-set values in your app are your own. The platform requires only that every exposure has a name and a type; everything else is configured. See How your app is configured.

Why the slot can outlive its occupants

The mechanism behind mid-term reassignment isn’t slot-specific — it’s how every policy in AI Insurance handles time. A policy’s state is stored as a series of segments: contiguous date ranges over which the policy’s facts are identical. Adding or removing an exposure mid-term splits the term at that date, so the exposure is present in some segments and absent from others. Its presence is its effective and end dates. That gives you, for free:

A slot with a continuous term and a discontinuous occupant. The slot exposure spans the whole term; provider A occupies it from inception to 31 May, provider B from 1 June to expiry.
Point-in-time truth. Read the policy as of any date and you see the slot roster in force on that date — in the app, the View as of lens on the policies list and the policy timeline; over the API, a version or an as-of read.
A vacant slot. A slot with no occupant is a perfectly valid state — the slot exposure is still on the policy, still rated, with no provider attached for that stretch of the term.
An audit trail that survives corrections. Backdating a reassignment you learned about late doesn’t rewrite history: the correction is its own transaction, and the policy still reads correctly as of every date. See Effective dates & the policy timeline.

A policy holds its own copy of each exposure’s data, with a permanent pointer back to the canonical exposure record. Editing a provider’s baseline record does not change what a bound policy says about them — that takes an endorsement. This is what lets a provider’s details differ between the policy that covered them last year and the one covering them now. See How exposures attach to policies.

Configuring the occupants: two patterns

The slot is an exposure in both patterns. What differs is how the providers occupying it are modelled. Most programs want the first.

Pattern A — provider as its own exposure, linked to the slot

Each provider is an exposure in its own right, added to and removed from the policy individually, with a field on the provider naming the slot it occupies (a record link to the slot exposure, or a plain slot identifier where the roster of slots is fixed). Because the provider is its own exposure, its attachment to the policy carries its own dates — which is exactly what makes per-provider start and end dates work without any extra date-keeping. Choose this when — providers rotate, per-provider underwriting data matters (licence, specialty, claims history), providers move between slots or between policies, or you need a provider’s claims to attach to the provider rather than to the slot.

You get	Because
Independent start and end dates per provider	The policy attachment is dated per exposure.
A provider record that persists across terms and policies	Exposures exist independently of any one policy.
Claims that attach to the provider	Events reference exposures directly.
Per-provider rating output	Rating runs fan out per exposure.
Reassignment without touching the slot	The slot’s own attachment is unchanged.

Pattern B — occupants stored as an object on the slot

The slot exposure carries a list object of its occupants — a configured structure with sub-fields for the provider’s name, licence, specialty, and their occupancy start and end dates. Providers are entries in that list, not separate records. Where you still want the link to a real record, a sub-field can point at a person in the directory. Choose this when — the slot is unambiguously the rated unit, occupant detail is light (a name and a date range on a schedule), and you’d rather keep one row per slot than a record per provider.

Trade-off	Consequence
The occupant is data, not a record	No exposure page, no cross-reference tabs, no claims attaching to the occupant.
Occupancy dates are fields you maintain	They’re not the policy’s attachment range, so they don’t split segments on their own.
Rating sees one exposure per slot	Fine when you rate the slot; limiting if you rate the provider.
Lighter data entry	One slot row to edit instead of a record per provider.

The patterns compose. A common setup is Pattern A for the providers who need their own record and rating, with a small object on the slot capturing the schedule as it should print on the policy form.

Reassigning a slot mid-term

Provider A vacates slot 3 on 31 May; provider B occupies it from 1 June. The slot and its limits don’t change.

Endorse effective 1 June

On the policy, Actions → Endorse. The dialog asks for the effective date (1 June) and the date the change applies through — the end of the policy here, which is the default. See Endorse.

Change the roster

Remove provider A from the policy and add provider B, linked to slot 3. The slot exposure itself is untouched.

Re-rate and bind

Rating runs over the endorsed state; binding the endorsement writes the new version. See Servicing a policy.

The result is two segments, with the slot in both:

Segment	Range	Slot 3	Occupant
1	1 Jan – 31 May	Present	Provider A
2	1 Jun – 31 Dec	Present	Provider B

Provider A’s coverage under this policy ends 31 May and their history of it is permanent — reading the policy as of any date in the first segment still shows them in slot 3.

The same reassignment over the API

Two shapes, depending on whether the outgoing provider leaves the policy entirely.The provider stays on the policy, only the slot link changes. One endorsement carrying two element-scoped deltas — sibling predicates on the same collection are not a conflict:

POST /api/v1/companies/{companyId}/policies/{policyId}/transaction/endorse

{
  "effectiveDate": "2025-06-01",
  "deltas": [
    {
      "startDate": "2025-06-01",
      "endDate": "2025-12-31",
      "path": "policy.additionalExposures[id = 'provider-a'].assignedSlot",
      "action": "Overwrite",
      "value": null
    },
    {
      "startDate": "2025-06-01",
      "endDate": "2025-12-31",
      "path": "policy.additionalExposures[id = 'provider-b'].assignedSlot",
      "action": "Overwrite",
      "value": "slot-3"
    }
  ],
  "fullTermPolicyBillingInfo": {
    "policyPremium": 84000, "policyTaxes": 4200,
    "policyFees": 500, "policyGrandTotal": 88700
  }
}

The outgoing provider comes off the policy and a new one goes on. That’s a Remove and an Add on the exposures collection itself — the same path, so they cannot share one transaction (within-transaction path conflicts). Send two endorsements, both effective 1 June:

1. Remove the outgoing provider

{
  "effectiveDate": "2025-06-01",
  "deltas": [
    {
      "startDate": "2025-06-01",
      "endDate": "2025-12-31",
      "path": "policy.additionalExposures",
      "action": "Remove",
      "value": { "id": "provider-a" }
    }
  ]
}

2. Add the incoming provider

{
  "effectiveDate": "2025-06-01",
  "deltas": [
    {
      "startDate": "2025-06-01",
      "endDate": "2025-12-31",
      "path": "policy.additionalExposures",
      "action": "Add",
      "value": {
        "id": "provider-b",
        "exposureType": "healthcareProvider",
        "assignedSlot": "slot-3",
        "specialty": "Anesthesiology"
      }
    }
  ],
  "fullTermPolicyBillingInfo": {
    "policyPremium": 84000, "policyTaxes": 4200,
    "policyFees": 500, "policyGrandTotal": 88700
  }
}

Both deltas start on the transaction’s effective date — that’s the one effective-date rule: a change starts applying exactly when the endorsement takes effect. To reach back and correct an assignment you learned about late, endorse with the true past effective date; the booking axis records that you filed it today. The embedded-exposure collection is named by your configuration — additionalExposures here is the example key used throughout the Policy Transactions API.

Rating slots

Rating follows whichever unit you price. A rating workflow stage can run once per exposure, so:

Rate the slot — the slot exposure is the rating target; the occupant’s characteristics ride along as inputs where they affect the rate.
Rate the provider — each provider exposure gets its own rating call and its own rating output.

Either way, rating results land per exposure, so an underwriter can see which slot or provider contributed which premium. On a quote, that’s the per-exposure tab on the underwriter workbench; afterwards, one rating run per exposure appears in the rating logs. Over the API, see the Rating overview. Mid-term reassignment prices the way the rest of the policy does: the endorsement re-rates the changed segments, and the full-term billing summary is updated with the transaction.

Slot schedules on policy documents

A slot schedule is generated like any other policy document, as of a date — so the schedule prints the occupants in force on the date you pick, and the same template can be composed at several dates across the term. See Generating on a policy.

What you configure

#	Configuration	Detail
1	Exposure types	Add `Slot` (plus `Healthcare Provider` and the facility type) to the exposure-type option set.
2	Slot fields	Slot number, limits, retroactive date, coverage form, rating basis — laid out on the slot’s cards.
3	Provider fields	Licence, specialty, board certification, claims count, hours or volume, part-time flag.
4	The occupancy link	Pattern A: a link field on the provider naming its slot. Pattern B: a list object of occupants on the slot.
5	Policy type	The slot coverage forms your program writes (claims-made, occurrence, tail).
6	Rating workflow	A stage that runs once per slot, or once per provider, matching the unit you price.
7	Forms	A slot schedule template, filled from the roster as of the generation date.

Configuration is managed for you as part of onboarding — this list is what to bring to that conversation, not work you do yourself.

Technical reference

Exposure type. exposureType is a framework-required option-set field on Exposure. Slot is an option value in your exposure-type option set, not a platform-level type. The full exposure field contract is on the Exposure entity page.Occupancy link. Pattern A’s link is a relationship field between two exposures — the id lives in the relationship junction, not in either exposure’s field data. Pattern B’s occupant list is a configured object on the slot exposure, stored inline in the slot’s field data; a sub-field can reference a top-level record (a directory person) by id. See How entities relate.On the policy. Exposures reach a policy as embedded exposures — a snapshot of the exposure’s data plus a pointer to the canonical exposure id. The policy ↔ exposure link is per segment, which is why an exposure’s presence on the policy is inherently dated and why removing one splits the term rather than erasing history. See Concepts.Per-exposure rating. Rating output attaches to its host exposure — an exposure-level rating response object, plus a crossSegmentRatingOutputs container for values that span the segments the exposure appears in. See Per-segment and element-level rating.Managing it over the API. Slot and provider exposures are ordinary entities on the unified CRUD surface (exposure); their attachment to a policy is a policy transaction. See the Entities API and Policy Transactions. Configuration itself is readable and writable through the Configuration API.

Overview

Medical Malpractice

The short answer

How it’s modelled

Why the slot can outlive its occupants

Configuring the occupants: two patterns

Pattern A — provider as its own exposure, linked to the slot

Pattern B — occupants stored as an object on the slot

Reassigning a slot mid-term

Rating slots

Slot schedules on policy documents

What you configure

​The short answer

​How it’s modelled

​Why the slot can outlive its occupants

​Configuring the occupants: two patterns

​Pattern A — provider as its own exposure, linked to the slot

​Pattern B — occupants stored as an object on the slot

​Reassigning a slot mid-term

​Rating slots

​Slot schedules on policy documents

​What you configure

The short answer

How it’s modelled

Why the slot can outlive its occupants

Configuring the occupants: two patterns

Pattern A — provider as its own exposure, linked to the slot

Pattern B — occupants stored as an object on the slot

Reassigning a slot mid-term

Rating slots

Slot schedules on policy documents

What you configure