> ## 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.

# Policy

> A bound, in-force contract of insurance. Placeholder — fuller writeup to come.

A **policy** is a bound, in-force contract of insurance — the result of a
[quote](/entities/quote) being accepted. It records the agreed term, the insured
risks ([exposures](/entities/exposure)), and accrues [events](/entities/event)
(claims) over its life.

<Frame caption="A policy in the app — the Overview tab shows the term as a version/segment timeline with endorsement history, alongside policy details and coverages.">
  <img src="https://mintcdn.com/ai-insurance-fmv1/nmTQjI4bY9Oj6vrb/assets/entities/policy.png?fit=max&auto=format&n=nmTQjI4bY9Oj6vrb&q=85&s=d6918b6eb27258ec039f14257498d599" alt="Policy detail page showing a single-segment term timeline, a View Endorsement History control, policy details, and General Liability coverage limits." width="1853" height="904" data-path="assets/entities/policy.png" />
</Frame>

<Note>
  Working in the app? See the [Policies feature reference](/app/features/policies) for the list view, the as-of lens, detail tabs, and renewal chains.
</Note>

<Note>
  **This page is a placeholder.** Policies work differently enough from the other
  entities to warrant their own detailed writeup, which is coming. The summary below
  captures what makes them special; the full data-model documentation will be filled
  in later.
</Note>

## What makes policies different

Unlike the other entities — which you create and edit directly — a policy's data
is **snapshotted** and every change goes through a **transaction API**. You don't
edit a policy in place; you apply a transaction (new business, endorsement,
cancellation, reinstatement, renewal), and each transaction produces a new
versioned snapshot of the policy. This is what lets the platform answer "what did
this policy look like on this date?" and keep an accurate history.

Because of this, a policy is **not** part of the unified create/update/delete
surface that the other entities share.

## What it connects to

| Connects to                     | How                                                                          |
| ------------------------------- | ---------------------------------------------------------------------------- |
| [Quotes](/entities/quote)       | The quotes that bound into this policy.                                      |
| [Events](/entities/event)       | Claims and incidents reported against this policy (one policy, many events). |
| [Exposures](/entities/exposure) | The insured risks on the policy, tracked per segment of the term.            |

## Learn more

The transaction model, versioning, effective dates, and lifecycle are documented
in the API reference today:

* [Policy Transaction API — overview](/api-reference/policies/overview)
* [Concepts](/api-reference/policies/concepts)
* [Effective dates](/api-reference/policies/effective-dates)
* [Lifecycle walkthrough](/api-reference/policies/lifecycle-walkthrough)

<Accordion title="Technical reference">
  **API.** Policy is **not** a CRUD entity. It has a read-only `/configuration`
  schema (slug `policy`), but its writes go exclusively through the [Policy
  Transaction endpoints](/api-reference/policies/overview).

  **Framework-required fields (selected).** `policyNumber`, `policyStartDate`,
  `policyEndDate` (the whole-term facts — caller-supplied at the policy root, and
  invariant across the term); `policyStatus`, `policyType`, `policyTimeZone`;
  `primaryInsuredName`, `primaryInsuredId` (the primary-insured identity, derived
  from the policy's own exposures); `fullTermPricingInfo` (the pricing contract:
  `pricingComponents` plus five server-computed rollups),
  `fullTermPolicyRatingResult` (objects);
  `cancellationEffectiveOnDate`; `referencingExposures` (written on the policy, per
  segment), `referencingQuotes` and `referencingEvents` (reverse-read).
</Accordion>