> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/lifecycle/configure-reconciliation.md).

# Configure reconciliation

Run a reconciliation between OpenIAM and a managed system report-only first, read the CSV it produces, and only then let it act.

## What this is, and when you need it

**Reconciliation** compares the accounts in a managed system with the identities in OpenIAM and acts on each difference. It is driven by one `RECONCILIATION_CONFIG` row per managed system per object type, with four `RECONCILIATION_SITUATION` child rows — one per comparison outcome — each naming a **response** (what to do) and a **population script** (how to map attributes).

Not to be confused with synchronization, which pulls from an authoritative source in one direction and is configured on `SYNCH_CONFIG` — reconciliation is bidirectional, runs through the managed system's connector, and can write to either side.

The specific risk: the situation responses are the only thing standing between a wrong search filter and mass account creation or deletion. `REMOVE_FROM_IDM` issues a real delete, and `DELETE_FROM_RES` calls the connector's delete directly for any target account OpenIAM did not match. Run your first pass with every situation on `NOTHING`.

## At a glance

|                          |                                                                                                                                                                                                                                      |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **You will end up with** | One `RECONCILIATION_CONFIG` row and its four situation rows, and a report-only run whose `EXEC_STATUS` reads `FINISHED` and whose CSV report lists every test account with its situation. Nothing else changes on a report-only pass |
| **Where**                | **Provisioning → Managed System**, then **Reconciliation** on the system's edit menu — `/webconsole/reconciliations?id=<MANAGED_SYSTEM_ID>`                                                                                          |
| **You need first**       | A managed system with a working connector, a `USER_OBJECT` policy map, the query and population scripts registered, and the **Reconciliation** menu (`RESRECONCILE`)                                                                 |
| **Takes**                | 30–45 minutes to build the config; the run scales with the number of accounts the target search returns                                                                                                                              |
| **Reversible**           | Partly — the config and its situation rows can be edited or deleted at any time, but once a situation acts there is no undo: `REMOVE_FROM_IDM` deletes users and `DELETE_FROM_RES` deletes target accounts                           |

## Before you begin

* A managed system with a connector assigned and connectivity proven. A run fails immediately with `MANAGED_SYS_NOT_FOUND` unless the managed system exists, is active, and is one OpenIAM provisions automatically.
* A policy map on that managed system of type `USER_OBJECT` (or `GROUP_OBJECT` for a group config). Reconciliation asks the policy map which attributes to request from the target; with no map it fails with `POLICY_ATTRIBUTES_EMPTY_VALUE` and the message `Managed system policy not defined for USER_OBJECT for managedSysId=<MANAGED_SYSTEM_ID>`. See [Build a policy map](/administration-guide/lifecycle/policy-map.md).
* Four Groovy scripts registered and compiling: a target search query script, an OpenIAM search query script, at least one population script, and — only if you need them — pre/post-processors. See [Reconciliation scripts](/administration-guide/lifecycle/reconciliation-scripts.md).
* The target attribute that carries the account name (`sAMAccountName`, `uid`, `USERNAME` …) and the OpenIAM field it matches.
* `<MANAGED_SYSTEM_ID>` and a test container or OU you are willing to have modified.

## Run a report-only reconciliation

Every response stays on `NOTHING` for this pass, and the target search filter matches a handful of test accounts rather than the whole directory — that is the only way to find out which situation your records actually land in before a response acts on them.

{% stepper %}
{% step %}

### Open the reconciliation list for the managed system

Go to **Provisioning → Managed System**, open your system, and choose **Reconciliation** from its edit menu (`RESRECONCILE` under `MNGSYS_EDIT_MENU_ROOT`) — route `/webconsole/reconciliations?id=<MANAGED_SYSTEM_ID>`. If the managed system has no connector, the UI offers to send you to `/webconsole/mngsystem?id=<MANAGED_SYSTEM_ID>` instead: "A connector must be assigned to the managed system before reconciliation can proceed."
{% endstep %}

{% step %}

### Create the config with Active off

**Add** goes to `/webconsole/reconciliationEdit?managedSysId=<MANAGED_SYSTEM_ID>`. Set **Type** to `USER` or `GROUP` — it is required, and locked once saved. Leave **Active** unticked and **Frequency** empty: an inactive config cannot be started accidentally and has no batch task.

Saving the configuration audits `RECONCILIATION_CONFIG_SAVED`.
{% endstep %}

{% step %}

### Point the target search at a narrow scope

Fill **Custom Processor Script** with your query script and **Target system search query filter** with a filter that matches a handful of test accounts. The filter reaches the script as the `searchFilter` binding; whatever string the script returns is sent verbatim to the connector as `customSearchQuery`.

This field is the blast-radius control for the whole run. `(&(objectclass=inetOrgPerson)(uid=*))` against a production base DN is every account in the directory.

{% hint style="warning" %}
The two fields are crossed. The target search query is taken from **Custom Processor Script**, and **Target system search query script** is never read — yet the built-in processing only runs at all when **Custom Processor Script** holds no processor class. In this build, therefore, put the query script that returns the target search string in **Custom Processor Script**, and leave **Target system search query script** empty. A config that fills only the latter fails at the first stage with `NOT_FOUND` and "Search query not defined for this reconciliation config" — that error, on a config that plainly has a query script, is this crossing and nothing else. If a later release fixes it, the **Target system search query script** field is where the query belongs; confirm which field your build reads with one report-only run before you migrate configs.
{% endhint %}
{% endstep %}

{% step %}

### Configure matching

Three fields decide whether a target row is recognised as an existing OpenIAM identity:

* **Source Attribute Name** — the target attribute holding the match value, e.g. `sAMAccountName`.
* **OpenIAM field name** — how to look that value up: `MANAGED_SYS_PRINCIPAL` searches logins on this managed system, `PRINCIPAL` searches logins on the default managed system, `EMPLOYEE_ID`, `EMAIL`, `USERID`, `NAME`, or `ATTRIBUTE`.
* **OpenIAM Custom Attribute Name** — only for `ATTRIBUTE`.

Then fill **OpenIAM search query script** and **OpenIAM search query filter** for the reverse pass.

A blank Source Attribute Name is silent: the match value comes out null for every row, every row is skipped, and the run completes having matched nothing and reporting no error. The report CSV with every row in `SYS_EXISTS__IDM_NOT_EXISTS` is the symptom.
{% endstep %}

{% step %}

### Add all four situation rows

The **Situations List** table only appears once the config has been saved. Add four rows, one per situation, each with a **Response** and a **Script**. For the first pass set every Response to `NOTHING`.

Missing rows are not tolerated — the part throws a `NullPointerException`. Missing scripts are: each record fails its child audit entry with "Population script wasn't set for situation `<SITUATION>`".
{% endstep %}

{% step %}

### Run it

Tick **Active**, then **Save and Reconcile** — audited as `START_RECONCILIATION`. The config is saved first, then the start message is sent. **Stop** is audited as `STOP_RECONCILIATION`.

Both start and stop turn on one counter, held in the distributed map `RUNNING_RECON` and keyed by config id. Starting increments it and refuses to start at all if it is already positive (`RECON_CONFIG_ALREADY_RUNNING`); every subsequent stage checks it, and aborts that batch with `INTERRUPTED_EXCEPTION` and "Reconciliation was stopped cannot continue" if the counter is *not* positive. **Stop** zeroes it — which is why a stop does not interrupt work in flight, it takes effect at the next batch.

The consequence: if a run dies hard the counter is never decremented and further starts are refused until you **Stop** the config. There is no screen that shows the counter, so the only symptom is `RECON_CONFIG_ALREADY_RUNNING` on a config whose `EXEC_STATUS` looks idle; pressing **Stop** on a config that is not running is safe and is the fix.
{% endstep %}

{% step %}

### Read the report, then let it act

Download the CSV with **Download latest report** on the reconciliation configuration, and check every row before changing any response away from `NOTHING`.
{% endstep %}
{% endstepper %}

## Worked example: a first reconciliation against a test OU

An LDAP managed system whose test accounts live under one OU. Object type `USER`, matching on `uid`.

**Pass 1 — report only.** Nothing is written on either side, but the full comparison CSV is still produced: the report row is written for every record whatever the response did, including `NOTHING`.

| Field                                     | Value                                                                          |
| ----------------------------------------- | ------------------------------------------------------------------------------ |
| Type                                      | `USER`                                                                         |
| Active                                    | ticked (required to start)                                                     |
| Frequency                                 | *empty* — no batch task, manual runs only                                      |
| Custom Processor Script                   | your query script, returning `(&(objectclass=inetOrgPerson)(uid=recon.test*))` |
| Target system search query filter         | `(&(objectclass=inetOrgPerson)(uid=recon.test*))`                              |
| OpenIAM search query script               | `UserSearchScript_1.0.groovy`                                                  |
| OpenIAM search query filter               | `{"employeeId":"not_found"}`                                                   |
| OpenIAM field name                        | `MANAGED_SYS_PRINCIPAL`                                                        |
| Source Attribute Name                     | `uid`                                                                          |
| Email Address for Completion Notification | *empty on the first pass*                                                      |

All four situation rows — `SYS_EXISTS__IDM_NOT_EXISTS`, `IDM_EXISTS__SYS_EXISTS`, `IDM_EXISTS__SYS_NOT_EXISTS` and `IDM_DELETED__SYS_EXISTS` — take Response `NOTHING` and Script `ldap/LDAPPopulationScript_1.0.groovy`.

Keep the real population script rather than `BlankSituationScript_1.0.groovy`. `NOTHING` runs the script and then discards the result, so you get the mapping exercised and the diff reported without a single write. The shipped `{"employeeId":"not_found"}` OpenIAM filter is a deliberate match-nothing value — leave it until you have read the report, because it keeps the OpenIAM → target pass empty.

**What the CSV contains.** The header row is `SITUATION,RECON_COMMAND,IDM_PRINCIPAL,TARGET_PRINCIPAL,EMPLOYEE_ID,FIRST_NAME,LAST_NAME`, and then a `TARGET_VALUE_<attr>` / `IDM_VALUE_<attr>` pair for every attribute in the managed-system viewer. Unmatched accounts show `N/A` in the OpenIAM columns.

## Verification

**Audit.** The parent event for a run carries action `RECONCILIATION` and source `RECONCILIATION`, with target attributes `RECON_ID` and `MAN_SYS_ID`. Beneath it:

| Constant                         | Recorded                              | Level          |
| -------------------------------- | ------------------------------------- | -------------- |
| `START_RECONCILIATION`           | when you press **Save and Reconcile** | the UI request |
| `STOP_RECONCILIATION`            | when you press **Stop**               | the UI request |
| `RECONCILIATION`                 | when the run begins                   | one per run    |
| `RECONCILE_PART_TARGET_WITH_IDM` | per batch, target → OpenIAM           | one per batch  |
| `RECONCILE_PART_IDM_WITH_TARGET` | per batch, OpenIAM → target           | one per batch  |
| `RECONCILE_TARGET_WITH_IDM`      | per record, target → OpenIAM          | one per record |
| `RECONCILE_IDM_WITH_TARGET`      | per record, OpenIAM → target          | one per record |
| `RECONCILIATION_CONFIG_SAVED`    | when you save the config              | on save        |
| `RECONCILIATION_CONFIG_DELETED`  | when you delete it                    | on delete      |

Search them at `/webconsole/viewAuditLog`; open one with `/webconsole/auditLog?id=<auditLogId>`. Every record-level entry carries the situation name in its `INFO` attribute, the target attribute map as its request body, and succeeds or fails individually. Batch-level entries also carry `MAX_TIME`, `MIN_TIME`, `AVERAGE_TIME`, `SUCCESS_COUNT` and `FAIL_COUNT`, which is the cheapest place to see whether records failed at all. Retention for each of these actions is governed by `org.openiam.audit.log.prune.days.<ACTION>`, all shipping as `-1` — see [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md).

**The report file.** OpenIAM writes `<confpath>/upload/recon/<managed system name>/<USER|GROUP>/Reconciliation_report_<MM_dd_yyyy_HH_mm_ss>.csv` where `<confpath>` is the deployment's configuration directory — `iam.files.location` resolves to `<confpath>/upload/`, and on a default deployment `<confpath>` is `/data/openiam`. If you do not know what it is on your deployment, ask its owner; it is set outside the Webconsole. The timestamp in the filename is `LAST_EXEC_TIME`, which is how **Download latest report** finds the file — so if `LAST_EXEC_TIME` and the file on disk disagree, the download returns nothing.

**Config state.** Reopen the config: `EXEC_STATUS` should read `FINISHED` and **Last Execution time** should be the run you just did. `FAILED` means the run aborted — the parent audit entry carries the exception class and message.

Reading the stored responses back is worth doing before every run that is not report-only, because the Response dropdown offers values OpenIAM does not implement:

{% code overflow="wrap" expandable="true" %}

```sql
SELECT c.NAME,
       c.RECON_TYPE,
       c.ACTIVE,
       c.EXEC_STATUS,
       c.LAST_EXEC_TIME,
       s.SITUATION,
       s.SITUATION_RESP,
       s.GROOVY_SCRIPT_ID,
       s.CUSTOM_COMMAND_SCRIPT_ID
FROM   RECONCILIATION_CONFIG c
       JOIN RECONCILIATION_SITUATION s
         ON s.RECON_CONFIG_ID = c.RECON_CONFIG_ID
WHERE  c.MANAGED_SYS_ID = '<MANAGED_SYSTEM_ID>'
ORDER  BY c.RECON_TYPE, s.SITUATION;
```

{% endcode %}

Four rows per config, each with a non-null `GROOVY_SCRIPT_ID`. On a `GROUP` config every `SITUATION_RESP` must be one of the seven responses group reconciliation implements — see [Reconciliation situations and responses](/administration-guide/reference/reconciliation-situations-and-responses.md#group-reconciliation-supports-only-seven-of-the-eleven-responses). A non-null `CUSTOM_COMMAND_SCRIPT_ID` means `SITUATION_RESP` on that row is decorative.

**The target and the users.** For `ADD_TO_IDM`, the new users exist with a login on `<MANAGED_SYSTEM_ID>` and one on the default managed system. For `DELETE_FROM_RES`, the account is gone from the target. Verify at the far end, not at the audit entry.

## When it goes wrong

| Symptom                                                                               | Cause                                                                                                                                                                                                     | Fix                                                                                                                                                                                                                     |
| ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Start fails immediately, `RECON_CONFIG_INACTIVE`                                      | `RECONCILIATION_CONFIG.ACTIVE` is `N`                                                                                                                                                                     | Tick **Active**.                                                                                                                                                                                                        |
| Start fails, `RECON_CONFIG_ALREADY_RUNNING`                                           | The Redisson map `RUNNING_RECON` still holds a positive count for this config id, usually from a run that died                                                                                            | **Stop** the config — that clears the entry — then start again.                                                                                                                                                         |
| `MANAGED_SYS_NOT_FOUND`                                                               | The managed system named on the config is missing, or is not an automatically provisioned one                                                                                                             | Check the managed system exists and is active.                                                                                                                                                                          |
| `POLICY_ATTRIBUTES_EMPTY_VALUE`, "Managed system policy not defined for USER\_OBJECT" | No `MNG_SYS_POLICY` row of that type on the managed system                                                                                                                                                | Create the policy map — [Build a policy map](/administration-guide/lifecycle/policy-map.md).                                                                                                                            |
| `NOT_FOUND`, "Search query not defined for this reconciliation config"                | `RECON_CUSTOM_PROCESSOR_ID` is empty, or its script returned an empty string                                                                                                                              | Put the query script in **Custom Processor Script**; confirm the script assigns to `output`.                                                                                                                            |
| `RESULT_INVALID_CONFIGURATION`, "target system match script is not defined"           | `MATCH_SCRIPT_ID` blank on a user config                                                                                                                                                                  | Fill **OpenIAM search query script**.                                                                                                                                                                                   |
| `INVALID_ARGUMENTS` from the match rule                                               | `MATCH_FIELD_NAME` blank, or not a `MatchObjectConstant` value                                                                                                                                            | Set **OpenIAM field name** from the dropdown.                                                                                                                                                                           |
| Run completes, zero records processed, no errors                                      | `CUSTOM_MATCH_SRC_ATTR` blank or naming an attribute the target does not return, so every row is skipped — the reconciliation service log says "Line object doesn't contain the match field" for each one | Set **Source Attribute Name** to an attribute that appears in the policy map *and* comes back from the connector.                                                                                                       |
| Group run completes, changes nothing                                                  | A response group reconciliation does not implement — `UPDATE_RES_FROM_IDM`, `DISABLE_IN_IDM`, `DISABLE_IN_RES` or `NOTHING_AND_INFORM`                                                                    | Change `RECONCILIATION_SITUATION.SITUATION_RESP` to one of the seven supported group responses.                                                                                                                         |
| A batch fails with `NullPointerException` on a group config                           | Either an unimplemented response was reached while the reconciliation service log was at debug level, or the OpenIAM → target pass met a group that has no identity on this managed system                | Fix the response, and narrow the **OpenIAM search query filter** so the OpenIAM pass returns only groups that already have an identity on `<MANAGED_SYSTEM_ID>`.                                                        |
| `INTERRUPTED_EXCEPTION`, "cannot define recon command properly"                       | A user config uses `DISABLE_IN_RES` or `NOTHING_AND_INFORM`                                                                                                                                               | Neither is implemented. Use `DELETE_FROM_RES`, `DISABLE_IN_IDM` or `NOTHING`.                                                                                                                                           |
| Records all skipped, log says "Incorrect return code from population groovy script"   | The population script returned non-zero                                                                                                                                                                   | Return `0` from the paths that should act. See [Reconciliation scripts](/administration-guide/lifecycle/reconciliation-scripts.md).                                                                                     |
| Every record's child audit says "Population script wasn't set for situation X"        | `RECONCILIATION_SITUATION.GROOVY_SCRIPT_ID` empty, or the script is set but failed to instantiate — that failure is logged at error level in the reconciliation service log and nowhere else              | Set the **Script** on that situation row and check the reconciliation service log for the compilation error.                                                                                                            |
| The Response you chose is ignored entirely                                            | `RECONCILIATION_SITUATION.CUSTOM_COMMAND_SCRIPT_ID` is set, and a custom command always wins over the Response                                                                                            | Clear **Custom Command** on that row.                                                                                                                                                                                   |
| Report email never arrives but the file exists                                        | `NOTIFICATION_EMAIL_ADDRESS` is null; OpenIAM only mails the report when an address is set                                                                                                                | Fill **Email Address for Completion Notification**.                                                                                                                                                                     |
| **Download latest report** returns nothing                                            | The download rebuilds the filename from `LAST_EXEC_TIME`; if the run failed before the report was written, there is no file and no timestamp                                                              | Re-run report-only to get a fresh report. Earlier reports are still on the server under `<confpath>/upload/recon/<managed system name>/<type>/`, but retrieving one needs filesystem access — ask the deployment owner. |
| The scheduled run reconciles the wrong config                                         | Both configs on this managed system share the batch task `Reconcile=<managed system name>`, and `PARAM1` was set when the task was first created                                                          | Delete the batch task and re-save the config you want scheduled first, or schedule only one.                                                                                                                            |
| Values leak between runs                                                              | `dataMap` is not cleared between runs: it belongs to the reconciliation service, not to the run, so a counter left in it is still there on the next run of any config on that instance                    | Do not use `dataMap` for per-run state, or clear your keys from the pre-processor — see [Reconciliation scripts](/administration-guide/lifecycle/reconciliation-scripts.md#how-bindings-reach-a-script).                |

## Rollback

Reconciliation is in the "reversible with consequences" category described in [Change configuration safely](/administration-guide/start/change-safely.md#reversibility-honestly).

* Set every situation back to `NOTHING` and untick **Active**. That stops further damage but undoes nothing.
* `ADD_TO_IDM` created users you can find by their creation timestamp and the audit entries under the `RECONCILIATION` parent event — the child `RECONCILE_TARGET_WITH_IDM` entries name each principal.
* `REMOVE_FROM_IDM` and `DELETE_FROM_RES` are not reversible from OpenIAM. Recovery is a restore on the side that lost the object.
* `UPDATE_IDM_FROM_RES` overwrote attributes; the previous values are in the `IDM_VALUE_*` columns of the report CSV from the run *before* the one that overwrote them, if you kept it. Keep every report.

## Letting reconciliation act

**Pass 2 — make it act.** Exactly two edits, in this order, testing after each:

1. `SYS_EXISTS__IDM_NOT_EXISTS`: `NOTHING` → `ADD_TO_IDM`. Every orphan in the report becomes an OpenIAM user. Confirm the count first — this is where a too-broad target filter shows up as thousands of new users.
2. `IDM_EXISTS__SYS_EXISTS`: `NOTHING` → `UPDATE_IDM_FROM_RES`. Target values now overwrite OpenIAM values for matched users, as your population script maps them.

Leave `IDM_EXISTS__SYS_NOT_EXISTS` on `NOTHING` until you are certain the target search returns *every* account it should. That situation's plausible responses — `ADD_TO_RES` (recreate the account), `DISABLE_IN_IDM` (deactivate the identity), `REMOVE_FROM_IDM` (delete the user) — all act on the assumption that "not found in the target" is true, and a search filter that is too narrow makes it false for everyone it excludes.

## How a run is put together

Reconciliation is a four-stage pipeline, each stage a separate RabbitMQ message so it can be spread across reconciliation service instances :

1. **Start.** OpenIAM builds the target search query from the query script and sends one search request to the connector. Audited as `START_RECONCILIATION`, then `RECONCILIATION` for the run.
2. **Match and split.** Every returned row is matched against OpenIAM using the match configuration, and the results are split into batches.
3. **Target → OpenIAM.** Each batch is processed in that direction, one audit entry per batch, `RECONCILE_PART_TARGET_WITH_IDM`. On the last batch the OpenIAM-side search runs and its results are split into batches too.
4. **OpenIAM → target.** Those batches are processed, `RECONCILE_PART_IDM_WITH_TARGET` per batch. On the last one OpenIAM runs the post-processor, writes the CSV report, emails it if an address is set, and sets `EXEC_STATUS` to `FINISHED`.

Because each stage is a separate message, a run in progress shows as a growing set of part-level audit entries and nothing else — there is no progress bar. Count `RECONCILE_PART_*` entries against the record count divided by the batch size if you need to know how far along it is.

Every record ends up in exactly one of four situations, and the situation decides which `RECONCILIATION_SITUATION` row applies. The four situations, the eleven responses and what each one actually writes are in [Reconciliation situations and responses](/administration-guide/reference/reconciliation-situations-and-responses.md).

## Related

* [Reconciliation situations and responses](/administration-guide/reference/reconciliation-situations-and-responses.md) — the four situations, the eleven responses and every field on the form.
* [Reconciliation scripts](/administration-guide/lifecycle/reconciliation-scripts.md) — the population, query, match and pre/post script contracts, with signatures that compile.
* [Build a policy map](/administration-guide/lifecycle/policy-map.md) — the attribute rows reconciliation asks the connector for.
* [Enumerated values](/administration-guide/reference/enums.md#reconciliation-situations) — the raw situation and response constants.
* [Shipped Groovy scripts](/administration-guide/reference/shipped-groovy-scripts.md) — the 41 scripts under `recon/`.
* [Change configuration safely](/administration-guide/start/change-safely.md) — why the first pass is report-only.

*Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openiam.com/administration-guide/lifecycle/configure-reconciliation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.