> ## Documentation Index
> Fetch the complete documentation index at: https://docs.topograph.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Standardization
> How we map local register data to clean international standards
Every country has its own way of describing companies. A "limited liability company" is a "GmbH" in Germany, an "SARL" in France, and an "S.r.l." in Italy. Standard activity codes vary, from NACE (EU) to SIC (UK) to ISIC (Global).
Topograph standardizes this kind of datapoints so you can build one integration that works everywhere. This standardization is crucial because it enables you to:
* **Build consistent logic** across countries without country-specific conditionals
* **Compare companies** from different jurisdictions using the same classification systems
* **Integrate with downstream systems** that expect standardized formats
* **Reduce complexity** in your codebase by handling variations at the API level
**Prefill mode varies by country**: with [`POST /v2/company`](/essentials/retrieve_company)
and [`mode: "prefill"`](/essentials/modes), the depth of standardization depends on the
country. Some countries return the same standardized legal forms, roles and statuses as
verification mode. Others return only the register's local values for some of these fields, for
example a legal form without its ISO 20275 code or a role without its ISO 5009 code. Activity
codes are usually standardized in both modes. Use default verification mode (omit `mode` or use
`mode: "verification"`) when you need fully standardized data.
## 1. Legal Forms
Understanding a company's legal structure is fundamental to risk assessment, compliance, and business relationships. Different legal forms carry different liability implications, regulatory requirements, and governance structures. However, each country uses its own terminology and classification system, making cross-border comparisons difficult.
We map thousands of local legal forms to both a standardized English translation and an **ISO 20275 code**. The ISO 20275 standard (Entity Legal Forms) provides a globally recognized classification system maintained by GLEIF (Global Legal Entity Identifier Foundation). This enables precise identification and comparison of legal entity types across jurisdictions.
**How we do it**: We use AI-powered translation and semantic matching against the official ISO 20275 code list. We are on **version 1.6**, published 19 February 2026, which contains 3,599 entity legal forms across 200 jurisdictions in 130 countries. When available, we also perform vector similarity search against the GLEIF-maintained database to find the most accurate ISO code match.
**Example: Germany**
* **Local**: "Gesellschaft mit beschränkter Haftung"
* **ISO 20275**: `2HBR`
* **Standardized**: `Limited Liability Company`
The ISO 20275 standard is maintained by GLEIF and provides a comprehensive,
internationally recognized classification system. Learn more about [ISO 20275
Entity Legal Forms Code
List](https://www.gleif.org/en/lei-data/code-lists/iso-20275-entity-legal-forms-code-list).
## 2. Roles
Identifying who has legal authority to represent a company is critical for due diligence, contract execution, and compliance checks. However, role titles vary dramatically across languages and legal systems. What's called a "Manager" in one country might be a "Gérant" in France or a "Geschäftsführer" in Germany, each with subtly different legal powers.
We map these diverse role titles to a standardized English classification and, for legal representatives, assign an **ISO 5009 code**. ISO 5009 (Official Organizational Roles) provides a standardized way to identify organizational roles within legal entities, enabling consistent role-based analysis across jurisdictions.
**How we do it**: We use AI to translate role titles to English and classify them into standardized categories. For legal representatives, we perform semantic matching against the ISO 5009 code list, which is contextually aware of both the role title and the company's legal form (ISO 20275 code), ensuring accurate role classification. We are on **ISO 5009 version 1.0.0**, published June 2023 — the only edition GLEIF has released.
An ISO 5009 code identifies a role **within a specific legal form**, so the same
job title carries a different code depending on the company it is held in. The
examples below are each scoped to that country's private limited company:
| Local Title | Country | Legal form (ISO 20275) | Standardized Role | ISO 5009 Code |
| - | - | - | - | - |
| Gérant | France | SARL (`V9QP`) | Manager | `4BIJAS` |
| Geschäftsführer | Germany | GmbH (`2HBR`) | Managing Director | `O3E52H` |
| Amministratore Unico | Italy | S.r.l. (`OV32`) | Sole Director | `IGKI9C` |
Because coverage is scoped this way, a legal form GLEIF has no role rows for
returns a role with no `iso5009Code`. That is an honest gap rather than a
near-miss from a neighbouring legal form.
ISO 5009 codes provide standardized role identification within legal entities.
The standard is maintained by GLEIF and enables consistent role-based
analysis. Learn more about [ISO 5009 Official Organizational Roles Code
List](https://www.gleif.org/en/lei-data/code-lists/iso-5009-official-organizational-roles-code-list).
## 3. Activity Codes (Activity Mapping)
Economic activity classification is essential for industry analysis, market research, regulatory compliance, and risk assessment. However, countries use different classification systems: Italy uses ATECO, the UK uses SIC, Germany uses WZ codes, and France uses NAF/APE codes. Even within the EU, while NACE is the standard, local implementations vary.
We map these diverse local activity codes to international standards: **ISIC Rev.5** (the global standard) and **NACE Rev.2.1** (the European standard). This enables you to compare companies across borders, perform industry-level analysis, and integrate with systems that expect standardized activity codes.
### Mapping Process
Topograph uses AI to standardize the activity sector of companies through a two-step process, prioritizing **precision over recall**.
#### Step 1: Local Classifications → ISIC Rev.5
We use AI to map local activity codes to ISIC Rev.5.
**Priority order:**
1. **Local Classification Codes** (Primary source)
* Country-specific codes (e.g., ATECO for Italy)
* Sector-specific codes (e.g., SIC, RAE, SAE)
* Official business register classifications
2. **Activity Descriptions** (Fallback source)
* Free-text activity descriptions when no local codes are available
**Process:** AI analyzes the activity code and description together to find the most semantically similar ISIC code. We favour accurate matches over complete coverage.
#### Step 2: ISIC Rev.5 → NACE Rev.2.1
Formal mapping from ISIC to NACE. NACE Rev.2.1 is the European implementation of ISIC Rev.5, so the two share the same structure and the correspondence is deterministic.
* **100% coverage** of ISIC Rev.5 classes
* **Deterministic correspondence**, derived from the official UNSD and Eurostat structures
* Register-native NACE codes are upconverted to NACE Rev.2.1 from the official Eurostat transition table
### Both standards, always together
When an activity can be placed in the current standardized classifications, the response carries `ISIC` and `NACE`, using the official ISIC Rev. 5 to NACE Rev. 2.1 correspondence where available. The register's own code is retained under its national key. An unknown revision or an unsupported correspondence can leave only the native code; no standardized class is invented.
These are absent only when the source register exposes no activity data at all for the company, or
when none of the codes it holds can be placed honestly in the standards:
* a NACE Rev. 2 class whose Rev. 2.1 successors scatter across unrelated divisions, with no activity
description to choose between them (see
[When you need the register's own NACE class](#when-you-need-the-registers-own-nace-class));
* in Croatia, a code stamped NKD 1994, which predates Croatia's NACE alignment and so cannot be
crosswalked from;
* in Latvia, a pre-2008 NACE Rev. 1 or Rev. 1.1 code that cannot be placed in Rev. 2.
In each case the register's own code is still published under its own key. See
[Where two revisions run side by side](#where-two-revisions-run-side-by-side).
### Which version of each classification?
Two revisions are fixed platform-wide, for every country and every source:
| Key | Standard | Revision |
| - | - | - |
| `ISIC` | UN ISIC | **Rev. 5** |
| `NACE` | Eurostat NACE | **Rev. 2.1** |
These never vary by country. A register that publishes NACE Rev. 2 is upconverted to Rev. 2.1
using the official Eurostat transition correspondence before we publish it, so `activities.NACE`
is Rev. 2.1 even where the source is not.
Every other key is the register's **own** national code, published exactly as the register records
it. We do not restate, renumber, or re-version those.
#### Revision-explicit keys
Each classification and revision has one canonical response key. `ISIC` means Rev. 5 and `NACE` means Rev. 2.1. National keys name their revision when the source establishes it, such as `SIC_2007` for UK SIC.
```json theme={null}
"activities": {
"NACE": [{ "code": "62.10", "description": "Computer programming activities" }],
"ISIC": [{ "code": "621", "description": "Computer programming activities" }]
}
```
Source aliases are merged into the canonical key, keeping distinct codes and deduplicating repeated codes. For editions resolved per record, bare keys contain only unresolved records; they do not repeat the revision-key arrays.
Earlier responses could return several spellings for the same classification. Current responses return only the canonical key. Update consumers of earlier spellings using the table below. See [alternate spellings](/essentials/activity-codes#alternate-spellings).
| Earlier or source key | Current response key | Country | Classification and revision |
| - | - | - | - |
| `ISIC_REV5` | `ISIC` | all | International Standard Industrial Classification, Rev. 5 |
| `NACE_REV21` | `NACE` | all | NACE, Rev. 2.1 |
| `ISAT` | `ISAT_2008` | Iceland | ÍSAT 2008, including the register’s national subclass digit |
| `KD` | `KD_BIH_2010` | Bosnia and Herzegovina | KD BiH 2010, the register’s NACE Rev. 2 harmonisation |
| `NACE_BEL` | `NACE_BEL_2003` / `NACE_BEL_2008` / `NACE_BEL_2025` | Belgium | NACE-BEL, per the version the register stamped |
| `WZ2008` | `WZ_2008` | Germany | Klassifikation der Wirtschaftszweige 2008 |
| `WZ2025` | `WZ_2025` | Germany | Klassifikation der Wirtschaftszweige 2025 |
| `DBR` | `DB25` | Denmark | Dansk Branchekode 2025 |
| `CNAE` | `CNAE_2009` | Spain | CNAE-2009 |
| `EMTAK` | `EMTAK_2008` / `EMTAK_2025` | Estonia | EMTAK, per the edition stamped on each assignment |
| `TOL` | `TOL_1995` / `TOL_2002` / `TOL_2008` / `TOL_2025` | Finland | Toimialaluokitus, per the edition the register stamped on the company's code |
| `NAFREV2` / `NAFRev2` | `NAF_REV2` | France | NAF rév. 2 (code APE) |
| — | `NACE_REV2` | France, Latvia, Malta, Ireland, Estonia | NACE Rev. 2 — the register's own class, see [When you need the register's own NACE class](#when-you-need-the-registers-own-nace-class) |
| — | `NACE_REV1` / `NACE_REV11` | Latvia | NACE Rev. 1 / Rev. 1.1 — the register's own pre-2008 class, per the revision it stamped |
| — | `NAF_2025` | France | NAF 2025 (INSEE's implementation of NACE Rev. 2.1), the code INSEE has assigned the company — provisional until 2027-01-01, see [France](https://www.topograph.co/countries/fr#activity-code-mapping) |
| `SIC` | `SIC_2007` | United Kingdom | UK SIC 2007 |
| `KAD` | `KAD_2025` | Greece | ΚΑΔ 2025 |
| `NKD` | `NKD_1994` / `NKD_2007` / `NKD_2025` | Croatia | NKD, per the revision the entry was filed under |
| `TEÁOR` | `TEAOR_2008` / `TEAOR_2025` | Hungary | TEÁOR, per the nomenclature the extract stamps on each entry |
| `ATECO` | `ATECO_2007` | Italy | ATECO 2007 (aggiornamento 2022) |
| `ATECO2025` | `ATECO_2025` | Italy | ATECO 2025 |
| `CAEN` | `CAEN_REV2` / `CAEN_REV3` | Romania | CAEN, per the revision stamped on each assignment |
| `CAEM-1.1` | `CAEM_REV11` | Moldova | CAEM Rev. 1.1 |
| `CAEM-2` | `CAEM_REV2` | Moldova | CAEM Rev. 2 |
| `SBI_2025` | `SBI` | Netherlands | No guaranteed edition; current active registrations use 2025, but historical and deregistered records can retain 2008 |
| `CAE` | `CAE_REV3` | Portugal | CAE Rev. 3 |
| `OKVED` | `OKVED_REV2` | Russia | OKVED Rev. 2 (ОК 029-2014) |
| — | `SNI_2025` | Sweden | SNI 2025 (Statistics Sweden's implementation of NACE Rev. 2.1) |
| `KVED` | `KVED_2010` | Ukraine | KVED-2010 |
`SBI` does not guarantee an edition. Check historical and deregistered records against the register before assigning a year.
These are the revisions the **registers** serve, which is not always the revision the national
statistics office has most recently adopted. The two routinely disagree, in both directions: a
register can serve an older revision for years after a new one is published, and sometimes the
register moves first. The Dutch Handelsregister converted every active registration to SBI 2025
in September 2025 while CBS is still phasing SBI 2025 into its own statistics through 2029.
#### Where two revisions run side by side
Belgium, Estonia, Croatia, Hungary, Romania and Latvia stamp each activity record with the revision it was filed
under, so a single company can carry codes from more than one. Rather than average that into one
answer, you get a key per revision:
* **Belgium.** The register's activity file marks every row `2003`, `2008` or `2025`, so the codes
arrive under `NACE_BEL_2003`, `NACE_BEL_2008` or `NACE_BEL_2025` accordingly.
* **Estonia.** RIK stamps each assignment with its EMTAK edition. EMTAK 2025 feeds standardized `NACE` directly; explicitly labelled EMTAK 2008 also preserves the declared class under `NACE_REV2` before transition. Unknown or conflicting editions retain native `EMTAK` and `NACE_EE`, without a guessed standardized class.
* **Romania.** ONRC assignments stamped Rev. 2 or Rev. 3 retain their national codes under `CAEN_REV2` or `CAEN_REV3`. Only recognized revisions feed the corresponding formal NACE transition.
* **Croatia.** The court register stamps each business-scope entry, giving `NKD_1994`, `NKD_2007`
or `NKD_2025`. A company filed across revisions returns one key for each. NKD 2007 and NKD 2025
are Croatia's NACE Rev. 2 and Rev. 2.1 transpositions, so both also feed `NACE`; codes stamped
NKD 1994 predate that alignment and are excluded, since reading one as Rev. 2 would produce a
class the register never declared.
* **Hungary.** The company extract stamps every activity `'08` (TEÁOR'08, the NACE Rev. 2
implementation) or `'25` (TEÁOR'25, the Rev. 2.1 one), so the codes arrive under `TEAOR_2008` or
`TEAOR_2025`. Only the `'08` entries are transitioned on their way into `NACE`.
* **Latvia.** The Enterprise Register stamps every NACE code `1`, `1.1` or `2`. Rev. 2 codes arrive
under `NACE_REV2` and are transitioned into `NACE`. Pre-2008 codes arrive under `NACE_REV1` or
`NACE_REV11` exactly as declared; where a model can place one in Rev. 2 it also reaches `NACE`,
marked `isAIInferred: true`, and where it cannot, the register's own code is still there rather
than dropped.
* **Malta.** The Business Registry records one area of activity per entity, from its own NACE Rev. 2
list. It arrives under `NACE_REV2` as declared and is transitioned into `NACE`.
#### Where we do not state a revision
The following keys have no revision-explicit sibling. The response does not identify their edition, so do not assign a revision from the key alone:
| Key | Country | Why |
| - | - | - |
| `CAE_QC` | Canada, Quebec | The register’s own economic activity codes, without an edition marker on the enterprise record. These are distinct from Portuguese CAE. |
| `NAICS` | US states | Each state records the NAICS vintage current when the entity registered and does not publish which one. The code is passed through exactly as the state holds it. |
| `NACE_SK` | Slovakia | Retains the register’s activity assignment when its code-list marker does not establish a recognized NACE edition. |
| `SSIC` | Singapore | The retrieved ACRA company dataset does not identify the edition on each record; native assignments are retained without asserting a revision. |
| `PKD` | Poland | The registers publish PKD codes without stating the revision, and PKD 2007 and PKD 2025 overlap in code shape. |
| `CAEN` | Romania | CAEN preserves older or unstamped assignments; recognized Rev. 2 and Rev. 3 stamps publish only `CAEN_REV2` or `CAEN_REV3`. |
| `NACE_EE` | Estonia | The original source NACE string, retained across editions, including unknown or unstamped legacy records. |
| `NKID` | Bulgaria | Recording an NKID code is optional and it is never retroactively migrated, so a filed code may be КИД-2003, КИД-2008 or КИД-2025 depending only on when the company last amended it. |
| `NAF` | any | Emitted by our AI profile parser rather than read from a French register, so the key does not fix a revision. France's own register code is `NAF_REV2`. |
| `RNA` | France | The associations register's nomenclature des objets sociaux describes association purposes. We publish no revision identifier; label it as RNA without a year. |
Country-specific revision keys are published on the [pricing page](https://topograph.co/pricing) and in `/v2/catalog` under `activityCodes.responseKeys`. That field lists declared canonical classification keys, rather than every possible response key, such as unstamped and association-purpose classifications. See the [activity-code page](/essentials/activity-codes#alternate-spellings) for spelling compatibility.
If you need one revision you can rely on across every country without tracking national
transitions, read `ISIC` or `NACE`. The national keys are there for round-tripping
back to the register, not for cross-border comparison.
### One code in, one code out
**We never publish an activity the register did not declare.** You get one standardized class per
declared code — never a list of candidates we could not choose between.
This matters because classification systems do not line up one-to-one. When a company's declared
class maps to several classes in the target standard, the true one is unknowable from the code
alone. Rather than return all of them, we return the most precise class the correspondence actually
supports:
| The declared code maps to | What you get |
| - | - |
| Exactly one class in the target standard | That class |
| Several classes in the same group | Their shared group (for example `64.2` rather than guessing `64.21` or `64.22`) |
| Several classes across different groups or divisions | Their shared division (for example `47`) |
| Classes scattered across unrelated divisions | No standardized code — the register's own local code only |
A shorter code is not missing data: `64.2` means the register told us the company is a holding
company but not which kind. It is the most specific statement the source supports. The register's
own code is always published in full alongside it.
The one exception is when the register also publishes a free-text activity description. That is
independent evidence about the actual trade, so we use it to pick the precise class — and mark the
result `isAIInferred: true` so you can tell it apart from a formal mapping.
#### When you need the register's own NACE class
Upconverting to Rev. 2.1 is the right default, but it has a hard limit: **Rev. 2.1 deleted some
Rev. 2 classes**. `86.90` has no Rev. 2.1 class of its own, so the most precise standardized answer
is the group `86.9`; for 17 further classes the successors scatter across unrelated divisions and
there is no honest Rev. 2.1 code at all, so `activities.NACE` is absent.
Where the register itself publishes NACE Rev. 2, we also publish that class verbatim under
**`NACE_REV2`**. Today that includes France, Latvia, Malta, Ireland and Estonia’s explicitly labelled EMTAK 2008 assignments. In France, NAF rév. 2 *is* the French implementation of NACE
Rev. 2 — an APE code's first four digits are the Rev. 2 class, the trailing letter a French
subdivision below it — so the key is present on every French company whose APE code we hold:
```json theme={null}
"activities": {
"NAF_REV2": [{ "code": "8690F", "description": "Activités de santé humaine non classées ailleurs" }],
"NACE_REV2": [{ "code": "86.90", "description": "Other human health activities" }],
"NACE": [{ "code": "86.9", "description": "Other human health activities" }]
}
```
Read `NACE_REV2` when you need a 4-digit class for every company and can accept the older revision;
read `NACE` when you need one revision you can compare across countries. They are
different revisions of the same classification, so never mix them in one field: `86.90` is not a
NACE Rev. 2.1 code and `86.9` is not a Rev. 2 class.
#### The register's own answer beats any table
Where the register itself publishes the company's class in the target revision, we read that and convert
nothing. France is the worked case: INSEE assigns every active company its **NAF 2025** code — the French
implementation of NACE Rev. 2.1, i.e. a Rev. 2.1 class with one French letter appended — and publishes it in
Sirene ahead of the 2027 cutover. A code-level correspondence can only say where a *code* went; INSEE says
where the *company* went, and the two differ whenever INSEE recoded the company on its actual activity
(a consultancy filed as `62.02A` that INSEE recoded to `73.12Y`, media representation). So for France,
`NACE` is the first four digits of the NAF 2025 code, the code itself is published under `NAF_2025`, and the
rules below only apply to the small population INSEE has not assigned one (units still coded in
pre-2008 nomenclatures, almost all ceased).
#### National sub-classes are used as evidence
Some registers publish a code that is *finer* than the standard class it sits in. France's APE/NAF
code is the clearest case: `8690F` is the NACE Rev. 2 class `86.90` plus a French sub-class letter,
and the letter says something the class does not.
Where the national statistics office publishes an official correspondence for those sub-classes, we
resolve through it rather than through the class. So `6420Z` returns NACE `64.21` (INSEE maps that
sub-class to a single Rev. 2.1 class) instead of the group `64.2` the bare class `64.20` would give.
The sub-class is only preferred when it names exactly one class; when it straddles several, the
class-level answer stands. Both codes are always published, so you can see the reasoning:
`activities.NAF_REV2` holds the register's own code and `activities.NACE` the standardized class.
If you previously filtered or de-duplicated `activities.NACE` and `activities.ISIC` yourself to
work around long lists, that logic is no longer needed. Counts are now proportional to what the
register declared: a company with three declared activities returns three NACE and three ISIC
codes, not several dozen.
### The main activity
Many registers designate one activity as the company's **main** (primary, prevailing) activity —
Belgium's `MAIN` classification, Poland's *działalność przeważająca*, Croatia's *pretežita
djelatnost*, Hungary's *főtevékenység*, and others — and some registers publish only the main
activity in the first place (France's APE code, Finland's main business line).
Where the register makes that distinction, the corresponding activity item carries
`isMainActivity: true`, and every code derived from it (NACE, ISIC, local crosswalks) inherits the
flag. At most one code per classification carries it, so
`activities.NACE.find(a => a.isMainActivity)` is a safe way to pick one code per company.
Where activity codes are AI-inferred from a free-text activity description, the single best-match
code is flagged as the main activity and is marked `isAIInferred: true` alongside, so a
register-declared main activity is always distinguishable from an inferred one.
Absence of `isMainActivity` means the register does not say — not that the code is secondary. Do
not rely on array order to identify the main activity; the flag is the only guaranteed signal.
### Example: Italy
Italy's register publishes a company's ATECO 2025 code together with its NACE class. ATECO 2025 is
Italy's implementation of NACE Rev. 2.1, so the NACE class is published as the register declared it,
and ISIC Rev. 5 is derived from it through the official correspondence. No AI step is involved, so
the ISIC code is `isAIInferred: false`, and the main-activity flag carries over to every derived
code. Each classification appears under its canonical key.
### API Response
```json theme={null}
{
"activities": {
"ATECO_2025": [
{ "code": "01.11", "description": "Growing of cereals", "isMainActivity": true }
],
"NACE": [
{ "code": "01.11", "description": "Growing of cereals", "isMainActivity": true }
],
"ISIC": [
{
"code": "0111",
"description": "Growing of cereals (except rice), leguminous crops and oil seeds",
"isAIInferred": false,
"isMainActivity": true
}
]
}
}
```
## 4. Addresses
Addresses are critical for verification, communication, and compliance (especially for KYC/AML requirements), but registries store them as unstructured text strings in various formats. Parsing addresses correctly is challenging because formats vary by country, and components like street numbers, postal codes, and administrative divisions are positioned differently.
We parse and structure unstructured address strings into standardized component parts, enabling you to validate addresses, perform geocoding, and integrate with address validation services without writing country-specific parsing logic.
**How we do it**: We use pattern recognition and country-specific parsing rules to extract address components, then normalize them according to international standards. Country codes follow ISO 3166-1 alpha-2 format for consistency.
* Street
* House Number
* Postal Code
* City
* Country (ISO 3166-1 alpha-2)
## 5. Status
Company status information is crucial for risk assessment. You need to know if a company is active, dissolved, in liquidation, or bankrupt before entering into business relationships. However, registries use different terminology and status codes, and some countries have complex status hierarchies that don't map cleanly to simple active/inactive states.
We normalize company status to a simple active/inactive boolean plus a standardized status enum, a closure reason, and key dates. This makes it easy to filter and reason about company status across jurisdictions without learning each country's specific status terminology.
**How we do it**: We map local status codes and descriptions to a three-layer model (boolean `active`, raw `localName`, and standardized `statusDetails`), preserving the original status information while providing a clean cross-country view.
* **`active`**: `true` / `false` (omitted when the register's status cannot be classified)
* **`statusDetails.status`**: `ACTIVE`, `UNDER_INSOLVENCY_PROCEEDING`, `INACTIVE_NOT_CLOSED`, `PENDING_DISSOLUTION`, `CLOSED`, `UNKNOWN`
* **`statusDetails.closureReason`** (when closed or under insolvency): `BANKRUPTCY`, `LIQUIDATION`, `VOLUNTARY_DISSOLUTION`, `ADMINISTRATIVE_DISSOLUTION`, `COURT_ORDER`, `MERGER`, `SPLIT`, `ACQUISITION`, `OTHER`, `UNKNOWN`
See the [Company Status guide](/guides/company-status) for the full model and usage patterns.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.