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

# Quote ↔ Policy conversion rules

> How values travel between a quote and a policy: every mapping is written down as a rule, nothing is copied just because two fields share a name.

When a quote is [bound](/app/workflows/binding), its values become a policy.
When a policy is [endorsed, renewed, cancelled, or reinstated](/app/workflows/servicing-policies),
its values pre-fill a new quote. **Conversion rules** are the small, explicit
instructions that say *which* values make that trip, *where* they land, and
*how* they change on the way.

This page explains the idea in plain language. The technical reference for
authoring rules through the API is [Conversion Rules](/api-reference/configuration/conversion-rules).

## The one rule to remember

**Nothing moves between a quote and a policy unless a rule says so.**

Two fields having the same name on the quote and on the policy does *not*
create a connection. That sounds like extra work, and sometimes it is, but it
is what makes the following possible:

* **Different names on each side.** Your quote can collect `Insured First Name`
  and `Insured Last Name` while your policy stores one `Named Insured`.
* **Values that change in transit.** Combine two fields into one, pick one of
  two values based on a yes/no answer, add a year to a date, or count how many
  times a policy has renewed.
* **Values that deliberately stay put.** Internal underwriter notes can live on
  the quote and never appear on the policy, even if both records have a field
  with that name.

## What a rule looks like

A rule has four parts. You can read one like a sentence: *"When binding new
business, set the policy's Named Insured to the quote's first and last name
joined with a space."*

| Part            | Plain meaning               | Example                                                         |
| --------------- | --------------------------- | --------------------------------------------------------------- |
| **Direction**   | Which way the values flow   | Quote → Policy                                                  |
| **Transaction** | When it applies             | New business, endorsement, renewal, cancellation, reinstatement |
| **Destination** | The field that gets written | `namedInsured` on the policy                                    |
| **Expression**  | How the value is worked out | `source.insuredFirstName + ' ' + source.insuredLastName`        |

The expression always reads from `source` (the record the values come *from*)
and can also read `transaction.effectiveDate`, the date the change takes
effect. Expressions are deliberately simple and predictable: the same inputs
always give the same result, so a bind done today and the same bind done next
week produce the same policy.

## Each direction is written separately

A rule that joins first and last name into one policy field does not tell the
system how to split that name back apart when the policy is later renewed. So
the return trip is its own rule, for example: *"When renewing, set the quote's
Named Insured Override to the policy's Named Insured."*

| Direction          | Runs when                                                                                                   |
| ------------------ | ----------------------------------------------------------------------------------------------------------- |
| **Quote → Policy** | You bind a new-business, endorsement, or renewal quote.                                                     |
| **Policy → Quote** | You start an endorsement, renewal, cancellation, or reinstatement and the wizard pre-fills from the policy. |

Cancellations and reinstatements only change the policy's lifecycle. Their
Quote → Policy step carries the framework rules and nothing else; ordinary field
edits belong in an endorsement.

## What you see in the app

* **Binding a quote.** The new policy shows whatever the Quote → Policy rules
  wrote. A field with no rule is simply blank on the policy.
* **Endorsing or renewing.** The wizard opens pre-filled with whatever the
  Policy → Quote rules produced. A renewal can arrive with its end date already
  moved forward a year, or a description that reads "Renewal of GLP-2026-1001".
* **Viewing your rules.** Administrators can browse the rules under
  **Admin → Configuration → Conversion Rules**, grouped by direction and
  transaction type.

## Framework rules you keep

A handful of rules ship with every company and cannot be removed or edited:
the policy type, time zone, start and end dates, and the two pricing and rating
containers. They keep the policy's identity and money consistent. Everything
else in the list is yours to add, change, or leave out.

## When you change fields

Adding a field to both the quote and the policy does not connect them. Decide
what should happen and add a rule if you want the value to travel. Renaming or
removing a field means updating any rule that mentions it; the configuration
import tells you exactly which rule is affected and why.

<Tip>
  A missing rule is a valid choice, not an error. If a value should not cross
  from quote to policy, leave it unmapped and it stays where it is.
</Tip>