> ## 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. # Entities Overview > The top-level entities in AI Insurance — what they are, how their data works, and how they connect. AI Insurance is built around a small set of **top-level entities** — the real-world things the platform keeps track of. Each one is a *record*: it exists in its own right, has its own detail page, shows up in lists, and can be linked to other records. There are seven top-level entities: | Entity | What it represents | | -------------------------------------- | ------------------------------------------------------------------ | | [Submission](/entities/submission) | An incoming request to be quoted — the start of the workflow. | | [Quote](/entities/quote) | A priced offer worked up from a submission. | | [Policy](/entities/policy) | A bound, in-force contract of insurance. | | [Event](/entities/event) | A claim or incident reported against a policy. | | [Exposure](/entities/exposure) | A thing being insured (a business, building, vehicle, person). | | [Person](/entities/person) | An individual in the directory — a broker, attorney, contact, etc. | | [Organization](/entities/organization) | A company or firm in the directory. | ## What every entity has in common **They all carry fields.** Every entity's data is just a set of fields, and the exact set is **configured per company**. Some fields are required by the platform (for example, an exposure always has a name and a type), but beyond those you can add as many custom fields as you like — text, numbers, dates, yes/no, dropdowns, and nested objects. Two companies using AI Insurance can model the same entity very differently. **They all connect to each other.** A submission fans out into quotes, a quote binds into a policy, a policy accrues events, and exposures sit at the center — referenced by submissions, quotes, policies, and events alike. See [How entities relate](#how-entities-relate) below. **They support Files, Notes, and Contacts — though not uniformly.** **Notes** are available on nearly every entity; **Files** and **Contacts** appear on a smaller set (Exposure, Event, and Submission). Where they appear, each works the same way: * **Files** — upload arbitrary documents and attachments. * **Notes** — free-text notes recorded against the record. * **Contacts** — link people (from the directory) to the record. See the table below for exactly which entity has which. These three are **not** present on every entity. Today they appear as follows: | Entity | Files | Notes | Contacts | | ------------ | :---: | :---: | :------: | | Exposure | ✓ | ✓ | ✓ | | Event | ✓ | ✓ | ✓ | | Submission | ✓ | ✓ | ✓ | | Quote | — | ✓ | — | | Person | — | ✓ | — | | Organization | — | ✓ | — | | Policy | — | — | — | This table reflects the **in-app tabs**: Exposure, Event, and Submission show all three; Quote, Person, and Organization show Notes only; Policy shows none. The **API is broader** than the in-app tabs. Through the API, **notes** can be recorded against every top-level entity type (Policy included), and **files** can be attached to every entity type as well as at the company level — even where the app doesn't surface a tab for it. ## How entities relate For most entities, a link is stored on **one** side (the side you edit) and read back automatically from the other side. The full set of relationships: | Relationship | How many | Notes | | ---------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------------- | | Quote → Submission | Many quotes belong to one submission | **Required** — every quote belongs to a submission. | | Quote → Policy | Many quotes can bind into one policy | Set when a quote is bound. | | Event → Policy | A policy has many events | Each event names the policy it was reported against. | | Submission / Quote / Policy / Event → Exposure | Many-to-many | Exposures are the shared hub — every part of the workflow can reference them. | | Person → Organization | A person belongs to at most one organization | Optional. | | Event / Exposure / Submission → Person | Many-to-many ("Contacts") | People linked to a record as contacts. | Diagram of Submission, Quote, Policy, Event, and Exposure showing their referencing fields and cardinalities (1:N, N:1, N:N), with Exposure at the center as the hub. ## The building blocks Under the hood, everything in the platform is built from four ideas. You don't need these to use AI Insurance, but they explain *why* the entities behave the way they do: * **Record** — a thing that exists on its own, with its own id, page, and place in a list. Every top-level entity is a record. * **Field** — a single value on a record. The set of fields is configured per company. * **Link (Join)** — two records pointing at one shared record (a person linked to an organization, a contact linked to an event). A link is readable from both sides. * **Embedded copy** — a record that another record keeps its *own private copy* of, with a permanent pointer back to the original. This is how a [policy carries exposure data](/entities/exposure#how-exposures-attach-to-policies) it can change over time without rewriting history for everyone else. **Entity types (API slugs).** Six entities are managed through the unified CRUD surface, keyed on a lowercase-kebab `{entityType}` slug: `event`, `exposure`, `quote`, `submission`, `person`, `organization`. **Policy is not a CRUD entity** — its writes go through the [Policy Transaction API](/api-reference/policies/overview). See the [Entities API overview](/api-reference/entities/overview) for the request/response envelope, `PATCH` merge semantics, configuration discovery, and permissions. **Relationship fields.** Cross-entity links use `referencing*` fields. The link is written on one entity and read back from the other (for most pairs the reverse is read-only; Event ↔ Exposure can be written from either side): | Relationship | Written on | Reverse field | | -------------------------------------------------- | --------------------------------- | --------------------------------- | | Quote ↔ Submission (N:1, required) | `Quote.referencingSubmission` | `Submission.referencingQuotes` | | Quote ↔ Policy (N:1) | `Quote.referencingPolicy` | `Policy.referencingQuotes` | | Event ↔ Policy (N:1) | `Event.referencingPolicy` | `Policy.referencingEvents` | | Policy ↔ Exposure (N:N, per-segment) | `Policy.referencingExposures` | `Exposure.referencingPolicies` | | Quote ↔ Exposure (N:N) | `Quote.referencingExposures` | `Exposure.referencingQuotes` | | Submission ↔ Exposure (N:N) | `Submission.referencingExposures` | `Exposure.referencingSubmissions` | | Event ↔ Exposure (N:N) | `Event.referencingExposures` | `Exposure.referencingEvents` | | Person ↔ Organization (N:1) | `Person.organization` | `Organization.people` | | Contacts: Event/Exposure/Submission ↔ Person (N:N) | `contacts` on the record | — | Note `referencingSubmission` is **singular** (a quote has exactly one submission); the rest are lists. Relationship ids are stored in a separate join table, not in the entity's own field data — they are stripped from the request body on write and injected back on read.