> ## Documentation Index
> Fetch the complete documentation index at: https://docs.go.aiinsurance.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Slots
> How slot-based medical malpractice coverage works in AI Insurance — slots and providers as exposures, mid-term reassignment, and the two ways to configure occupants.
> *"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](/entities/exposure), 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](/app/features/exposures#the-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](/app/getting-started/configuration).
## 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](/api-reference/policies/effective-dates).
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](/entities/exposure#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](/entities/person).
**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.
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](/app/features/policies#endorse).
Remove provider A from the policy and add provider B, linked to slot 3. The
slot exposure itself is untouched.
Rating runs over the endorsed state; binding the endorsement writes the new
version. See [Servicing a policy](/app/workflows/servicing-policies).
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.
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:
```json POST /api/v1/companies/{companyId}/policies/{policyId}/transaction/endorse theme={null}
{
"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](/api-reference/policies/concepts#within-transaction-path-conflicts)).
Send two endorsements, both effective 1 June:
```json 1. Remove the outgoing provider theme={null}
{
"effectiveDate": "2025-06-01",
"deltas": [
{
"startDate": "2025-06-01",
"endDate": "2025-12-31",
"path": "policy.additionalExposures",
"action": "Remove",
"value": { "id": "provider-a" }
}
]
}
```
```json 2. Add the incoming provider theme={null}
{
"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](/api-reference/policies/effective-dates#the-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](/api-reference/policies/concepts#path-notation).
## 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](/app/workflows/quoting); afterwards, one
rating run per exposure appears in the [rating logs](/app/admin/rating-logs).
Over the API, see the [Rating overview](/api-reference/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](/app/features/forms#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.
**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](/entities/exposure).
**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](/entities/overview#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](/api-reference/policies/concepts#segments).
**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](/api-reference/policies/concepts#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](/api-reference/entities/overview) and
[Policy Transactions](/api-reference/policies/overview). Configuration itself is
readable and writable through the
[Configuration API](/api-reference/configuration/overview).