# Claim Adjudication Ontology — Development Standards & Governance Guidelines

| | |
|---|---|
| **Document ID** | `CLAIMS-ADJ-ONTOLOGY-STANDARDS` |
| **Version** | 1.0.0 |
| **Status** | Standard — binding on all contributors to the claims adjudication ontology |
| **Audience** | Ontology creators, reviewers, vocabulary stewards, mapping engineers, data governance |
| **Derived from** | `CHUBB-CLAIMS-ADJ-ONTOSPEC 1.0.0` (build specification) and the Chubb ontology-engineering briefs (namespace policy, modularization, controlled vocabularies, RDFS/OWL/SHACL, anti-patterns, versioning, workflows & provenance, reuse of standards, mapping strategy, security & privacy) |
| **Target profile** | OWL 2 DL at design time; OWL 2 QL projection for runtime OBDA rewriting |
| **Canonical serialization** | Turtle. JSON-LD is generated at the serving edge only — never hand-authored |

**How to read this document.** Rules marked **MUST** are invariants — a reviewer, a reasoner, or a SHACL shape can check them, and a change that violates one does not ship. Rules marked **SHOULD** are strong defaults you break only with a recorded reason in `skos:editorialNote`.

---

## Table of contents

1. [Purpose and scope](#1--purpose-and-scope)
2. [Guiding principles](#2--guiding-principles)
3. [The development method](#3--the-development-method)
4. [Standards baseline and the reuse policy (W3C · SKOS · OMG · FIBO · ACORD · FHIR)](#4--standards-baseline-and-the-reuse-policy)
5. [Namespace and IRI policy](#5--namespace-and-iri-policy)
6. [Naming and metadata conventions](#6--naming-and-metadata-conventions)
7. [Modular architecture and the import DAG](#7--modular-architecture-and-the-import-dag)
8. [Modelling patterns and guardrails](#8--modelling-patterns-and-guardrails)
9. [RDFS vs OWL vs SHACL — where each rule belongs](#9--rdfs-vs-owl-vs-shacl--where-each-rule-belongs)
10. [Controlled vocabularies (SKOS)](#10--controlled-vocabularies-skos)
11. [Data governance](#11--data-governance)
12. [Versioning and change management](#12--versioning-and-change-management)
13. [Provenance strategy](#13--provenance-strategy)
14. [Lineage and source-mapping strategy](#14--lineage-and-source-mapping-strategy)
15. [Privacy, security and AI governance](#15--privacy-security-and-ai-governance)
16. [Quality assurance and the CI pipeline](#16--quality-assurance-and-the-ci-pipeline)
17. [Definition of done](#17--definition-of-done)
18. [Reference registers](#18--reference-registers)

---

## 1 · Purpose and scope

This document is the **normative standard** for building the Claim Adjudication Process Ontology: the adjudication of a General Liability or Auto claim from First Notice of Loss (FNOL) through post-settlement closure, together with the two processes that run alongside it — fraud detection and straight-through processing (STP).

It governs **how** the ontology is built, not just what it contains:

- which external standards are reused, and by what mechanism;
- how namespaces, IRIs, prefixes and files are structured;
- how modules are layered and how imports are constrained;
- which modelling patterns are mandatory and which moves are prohibited;
- how governance, versioning, provenance, lineage, privacy and AI accountability are engineered into the ontology rather than bolted on.

**Out of scope of the ontology** (and therefore of this standard): Workers Compensation, underwriting, policy servicing, billing, reinsurance, and the physical schemas of the operational/analytical source systems — sources are mapped upward, never lifted.

---

## 2 · Guiding principles

1. **Reuse the generic; reserve your effort for what makes you different.** Time, parties, organizations, places, money, codes, metadata and provenance are already modelled by W3C and OMG standards. Import them. Spend modelling effort only on what is genuinely claims adjudication: the stages, the gates, the decisions, the evidence trace.
2. **Apply the lightest reuse mechanism that meets the need**, in strict order of preference: *use as-is* → *subclass under it* → *align by mapping / MIREOT* → *model it yourself*.
3. **Competency questions drive scope.** Every term must trace to a source-workbook cell **and** a competency question (CQ). If neither exists, the term is not built. CQs are also the doneness test: a module ships when its CQs return correct answers.
4. **Model the domain, never the message or the table.** Source schemas (relational tables, ACORD XML payloads) are mined for *terms*; structure is derived from the domain and the CQs.
5. **Meaning in OWL, quality in SHACL, values in SKOS.** Reasoning adds facts you didn't state; validation rejects data you don't want. Never ask one to do the other's job.
6. **Plan vs. execution is sacred.** A stage in the adjudication *plan* is one shared individual; a stage *execution* is a `prov:Activity`, one per claim, with a start, end, agent and inputs. Confusing them makes duration and audit questions unanswerable.
7. **Every fact must answer: where did you come from, and by what process?** Insurance is regulated; provenance and lineage are not optional metadata, they are first-class deliverables.
8. **Deprecate, never delete.** Published IRIs are permanent commitments.
9. **Nothing flagged as an open SME question may be silently resolved.** Emit it with `skos:editorialNote` and the build-metadata open-question flag, and list it in the conformance report. Model gaps visibly rather than leaving them silently absent.

---

## 3 · The development method

Follow this loop for every module and every substantial change:

| Step | Activity | Gate |
|---|---|---|
| 1 | **Collect competency questions** for the module from the question bank and SME sessions | CQ recorded with an ID and a target SPARQL sketch |
| 2 | **Reuse check** — walk the standards baseline (§4) before minting anything | Reuse decision recorded (as-is / subclass / align / mint) |
| 3 | **Choose the pattern** — run every candidate concept through the six-shapes test (§8.1) | Pattern recorded; prohibited moves (§8.3) checked |
| 4 | **Author in Turtle** in the correct module, per the namespace (§5) and naming (§6) policies | Header template complete; metadata block complete |
| 5 | **Author the SHACL shapes and SKOS schemes** that accompany the terms | One `.shapes.ttl` and the referenced schemes exist |
| 6 | **Reason** — OWL 2 DL consistency over the merged import closure | Reasoner green (CI) |
| 7 | **Validate** — SHACL over the *reasoned* graph; CQ regression | Shapes and CQs green (CI) |
| 8 | **Classify the change, version, document, release** (§12) | The nine review gates (§11.2) all pass |

Build in **waves**, thin vertical slices first: prove the highest-value questions answerable end to end (for this domain: the coverage-position rationale and the guided-adjudication accept/reject rationale), then widen.

---

## 4 · Standards baseline and the reuse policy

### 4.1 W3C — the substrate (use as-is, canonical IRIs, never re-mint)

| Standard | Prefix | Role in this ontology |
|---|---|---|
| RDF 1.1 / 1.2 | `rdf:` | Graph substrate. RDF 1.2 triple terms **only** for statement-level provenance (§13) |
| RDF Schema 1.1 | `rdfs:` | Labels, hierarchy, `isDefinedBy` |
| OWL 2 (DL profile) | `owl:` | Meaning: restrictions, disjointness, equivalence, `hasKey`, versioning |
| SHACL | `sh:` | **Every** constraint: cardinality, required fields, value sets, patterns, cross-class rules |
| SPARQL 1.1 | — | Competency questions, validation queries, serving |
| SKOS + SKOS-XL | `skos:` `skosxl:` | **All** controlled values: statuses, perils, document types, dispositions, fraud indicators |
| PROV-O | `prov:` | Entity–activity–agent backbone for the adjudication process *and* the pipelines that build the graph |
| P-Plan | `p-plan:` | Prospective provenance: the adjudication *plan* as distinct from a *run* |
| OWL-Time | `time:` | Instants and intervals: loss date, reported date, deadlines, coverage terms |
| W3C Organization | `org:` | Adjuster teams, SIU unit, law firms, CAT workforce |
| Dublin Core Terms | `dct:` | Titles, creators, dates, identifiers, `isReplacedBy`, `source` |
| VANN | `vann:` | Preferred prefix/namespace declarations on every module |
| R2RML / RML | `rr:` `rml:` | Relational and file/API lifting — the lineage layer (§14) |
| DCAT | `dcat:` | Cataloguing the served graph and datasets |
| ODRL | `odrl:` | Access policy as data (§15) |
| DPV | `dpv:` | Personal-data categories on PII-bearing predicates. *W3C Community Group report, not a Recommendation — use it, and state the status* |
| JSON-LD 1.1 | — | Edge serialization only; contexts are generated from Turtle |

Also reused where a CQ pays for it: **QUDT** (quantities with units), **GeoSPARQL** (loss-location geometry), **RDF Data Cube** (`qb:`, aggregate/KPI serving).

**MUST:** reuse these at their canonical IRIs. Re-minting SKOS, PROV, Time, Org or Dublin Core under the corporate host is prohibited (P-9/AP-14). Add local axioms in your own module — never by editing a vendored file.

### 4.2 OMG — the business-semantics layer

| Standard | Verdict | How to use it |
|---|---|---|
| **FIBO** (EDM Council / OMG) | **Align, don't absorb** | FIBO's insurance content covers the enterprise/agreement/monetary side, not P&C claims adjudication. Add `skos:closeMatch` / `rdfs:subClassOf` bridge axioms **in your own module** — e.g. the insurer to `fibo-fbc-fse:InsuranceCompany`, the policy to `fibo-fbc-dae-gty:InsurancePolicy`, financial concepts to FIBO monetary/agreement classes. **Do not import the FIBO closure** — MIREOT the handful of terms you reference. |
| **OMG Commons (cmns)** | **Use as-is** | Prefer `cmns-id:` identifier patterns over minting a new identifier scheme where the foundation does not already provide one. |
| **OMG LCC** | **Use as-is** | Model state/county/venue jurisdictions against LCC country and subdivision concepts; never mint a private geography. |
| **OMG DTV** | **Reference; prefer OWL-Time** | OWL-Time is primary; cite DTV where an ISO-8601 business date definition is needed in the glossary. |
| **OMG DMN** | **Align as data — do not re-implement** | Every adjudication rule and gate criterion carries a `dmnDecisionRef` annotation pointing at the DMN decision that implements the logic. The ontology records *which* rule fired and *what* it concluded; DMN owns the logic. OWL is not a rules engine. |
| **OMG SBVR** | **Align the glossary** | The business glossary is the SKOS realisation of an SBVR-style vocabulary; record the SBVR natural-language rule statement alongside the DMN reference. |
| **OMG BPMN / CMMN** | **Align the process shape** | Stages are BPMN activities; gates are BPMN gateways / CMMN decision tasks. Carry `bpmnProcessRef` / `bpmnActivityRef` annotations so the modelled and executable processes stay reconcilable. Never encode BPMN structure in OWL axioms. |

### 4.3 ACORD — the insurance terminology authority

| ACORD asset | Verdict |
|---|---|
| **ACORD Information Model (AIM)** | ✅ **Primary terminology alignment target.** For every core class, record `skos:exactMatch` / `skos:closeMatch` to the corresponding AIM concept and carry the AIM term as `skos:altLabel`. |
| **ACORD Business Glossary** | ✅ Seed `skos:definition` where an in-house definition does not exist; record `dct:source`. |
| **ACORD Capability Model** | ✅ Align the process stages and the module map to it (Claims Lifecycle Management, Claims Handling, Fraud Management, Claims Recovery, Dispute Resolution, Claims Inquiry). This makes the process model legible to enterprise architecture. |
| **ACORD Process Model** | ✅ Reference from each stage via an `acordProcessRef` annotation. |
| **ACORD P&C / XML message standards, NGDS** | ⚠️ **Terminology only.** Mining an XML schema for *structure* is prohibited (P-10/AP-15) — envelopes, arrays and string-typed codes are transport accidents. Harvest nouns and code lists; derive structure from the domain and CQs. |
| **ACORD code sets** | ✅ Mint your concepts in your own scheme and link with `skos:exactMatch` / `skos:broadMatch`. **Never add a concept to an ACORD scheme** (CV-8). |

### 4.4 schema.org — edge only, with one hard caution

> ⚠️ **`schema:Claim` is NOT an insurance claim.** It is a fact-checking claim, `rdfs:subClassOf schema:CreativeWork`. Using it for an insurance claim is a category error and is **prohibited (P-8)**.

Use schema.org **only at the serving edge** for discoverability (Person, Organization, Place, MonetaryAmount, Vehicle, medical types), emitted as a **generated JSON-LD context** — never as OWL axioms in core modules. Where no schema.org equivalent exists (adjudication decision, coverage position), do not force a fit. `schema:domainIncludes` / `schema:rangeIncludes` are, however, the standard tool-readable property-signature annotations throughout (§9).

### 4.5 HL7 FHIR and clinical terminologies — the medical branch anchor

- **FHIR `Claim` / `ClaimResponse`**: the closest published machine-readable model of a line-item adjudication decision with a stated reason. Use as a **design reference and terminology anchor for the medical branch only**; align medical-line adjudication categories to the HL7 adjudication code system via `skos:exactMatch`. **Never import FHIR structure into the P&C adjudication spine.**
- **ICD-10-CM / CPT / HCPCS**: the code lives in `skos:notation` on a `skos:Concept`, with `skos:exactMatch` to the published concept. **Never a class per code.** Respect licensing — carry the notation and the match; do not redistribute licensed code sets.
- **X12 837/835 (CARC/RARC)**: reference for medical-invoice billed-vs-allowed reason codes where invoice mapping requires them.

### 4.6 Regulatory anchors

| Anchor | What it grounds |
|---|---|
| **NAIC Model #900** (Unfair Claims Settlement Practices Act) | Compliance requirements and statutory deadlines. Model timings are the canonical family; the jurisdiction-specific value is **data** on a jurisdiction-rule individual, never hard-coded. |
| **NAIC Model Bulletin on Insurers' Use of AI** (2023-12-04) | AI outputs, human overrides, AIS-programme governance metadata, and the STP audit log as **first-class classes**, not annotations (§15.3). |
| **ISO ClaimSearch (Verisk)**, state DOI filings / fraud bureaux | The fraud/SIU external-reference concepts. |
| **GDPR-style subject rights** | The erasure and pseudonymisation design (§15.2). |

### 4.7 The honest gap

Insurance has **no single authoritative domain ontology** the way finance has FIBO. The strategy this standard mandates is therefore: reuse the cross-domain W3C building blocks as-is; mine ACORD, FIBO and FHIR for **agreed terminology** and alignment targets; and model the genuinely domain-specific claims-adjudication concepts yourself, in your own namespace, aligned outward.

---

## 5 · Namespace and IRI policy

Every minted IRI is `https`, on the corporate semantic host (`data.chubb.com`), structured `/{root}/{layer}/{module}/{local-name}`.

| Rule | Level | Requirement |
|---|---|---|
| **NS-1** | MUST | Use `https` and the corporate host for all minted IRIs. |
| **NS-2** | MUST | Separate roots by artifact kind — `/ontology/` for schema, `/vocabulary/` for SKOS schemes, `/resource/` for instances. Never place a class and an individual under the same root. |
| **NS-3** | MUST | Slash namespaces with a **trailing slash** for in-house terms. Reserve hash (`#`) IRIs for the vendored W3C vocabularies, which keep their canonical namespaces. |
| **NS-4** | MUST | Structure the path `/{root}/{layer}/{module}/`. Module names are short, lowercase, singular, stable. Layers: `fnd` (foundation), `ins` (insurance domain), `claims` (this layer), `misc`. |
| **NS-5** | MUST | The `owl:Ontology` IRI **equals** the module namespace (with trailing slash); the file's `# baseURI` and `@prefix` are byte-identical to it. |
| **NS-6** | MUST | Declare `owl:versionIRI` as `{namespace}{version}` with `owl:versionInfo`. The namespace itself carries no version and never changes. |
| **NS-7** | SHOULD | Register exactly one preferred prefix via `vann:preferredNamespacePrefix` — short, lowercase, stable, identical everywhere it appears. |
| **NS-8** | MUST | Set `vann:preferredNamespaceUri` to the full namespace **including** the trailing slash. |
| **NS-9** | MUST | Keep header comments (`# baseURI`, `# prefix`, `# imports`) in sync with the real `owl:imports` and `vann:*` triples. |
| **NS-10** | MUST | Reuse external standards at canonical IRIs. Never re-mint SKOS, Org, Time, PROV or Dublin Core under the corporate host. |

**The extension golden rule.** Module authors never write into `fnd/` or `ins/` — those are Information Architecture (IA)-owned. Mint every new term in your own module namespace, `owl:imports` the upper module, and connect upward with `rdfs:subClassOf` / `rdfs:subPropertyOf`, or an object property when it is not a kind.

**Prefix registry.** One prefix, one namespace, everywhere, in every file — maintained as a single normative registry (Appendix-style, §18.1). Never invent an ad-hoc prefix or reuse a registered prefix for a different namespace.

**Instance IRIs (A-Box).** Stable IRIs are the join. Mint canonical resource IRIs from source keys with **fixed templates** (e.g. `…/resource/claims/claim/{CLAIM_ID}`, `…/resource/claims/line/{CLAIM_ID}-{LINE_SEQ}`, `…/resource/claims/trace/{CLAIM_ID}/{GATE_TOKEN}`). Fix templates once; never change them. Where a source code is not a safe IRI token, resolve it through a lookup view joining to the concept's local name — never template a raw code into an IRI.

---

## 6 · Naming and metadata conventions

### 6.1 Naming

| Artifact | Convention | Example |
|---|---|---|
| Class | PascalCase, domain context | `adj:AdjudicationDecision`, `cvp:ReservationOfRights` |
| Datatype property | camelCase noun, **never** a `has` prefix | `adj:decisionDate`, `lia:liabilityPercentage` |
| Object property | camelCase; `has`/`is` for attribute relations, verb phrases for domain relations; **always declare the inverse** | `adj:hasDecisionOutcome`, `dtr:usedDocument` |
| Boolean property | `is`/`has` prefix | `evd:isSystemGenerated` |
| SKOS concept | PascalCase, in its own scheme | `cvpos:ReservationOfRights`, `doctype:PoliceReport` |
| File | kebab-case Turtle, one stem per module | `adjudication.ttl`, `adjudication.shapes.ttl`, `adjudication.cq.ttl` |

**One name, one meaning, one place.** Property sprawl (`decisionDate`, `determinationDate`, `positionDate`, `adjudicatedOn` coexisting) and identifier sprawl (`claimId`, `claim_no`, `ClaimNbr`) are review-blocking defects. Reuse `prov:`, `time:` and `dct:` before minting; where a source column name differs, add `skos:altLabel`, not a second property.

### 6.2 Mandatory metadata on every class and property

| Predicate | Requirement |
|---|---|
| `rdfs:label` | Required. English, per the conventions above. |
| `skos:definition` | Required. State what the term **is**, what it **is not**, and why it lives in this module. `rdfs:comment` may be added but never substitutes (P-18). |
| Explicit type (`owl:Class` / `owl:ObjectProperty` / `owl:DatatypeProperty`) | Required. |
| `rdfs:subClassOf` / `rdfs:subPropertyOf` | Required — a resolving parent in an imported module or standard, and a genuine is-a. |
| `rdfs:isDefinedBy` | Required — points at the module's ontology IRI. |
| `dct:source` | Required for every term derived from source workbooks/systems — cite the tab and row (traceability, §14.5). |
| `schema:domainIncludes` / `schema:rangeIncludes` | Required on properties, as the tool-readable signature. |
| `rdfs:domain` / `rdfs:range` | **Only** where type inference is deliberately wanted on trusted data (§9). `rdfs:range xsd:*` on datatype properties is retained as convention. |
| `owl:hasKey` | On identity-bearing classes. Never a datatype inverse-functional property (P-6). |
| `dpv:hasPersonalDataCategory` | On every predicate carrying personal data (§15.2). |
| `prov:wasAttributedTo`, `prov:generatedAtTime` | On the `owl:Ontology` node. |

**Version metadata is per module, not per class.** Per-term history goes in `skos:changeNote` / `dct:modified`.

### 6.3 The module header template

Every module file opens with the standard header: `# baseURI` / `# imports` / `# prefix` comments mirroring the real triples; `dct:title`, `dct:description`, `vann:` prefix declarations; `owl:imports` **pinned to versionIRIs**; `owl:versionIRI` + `owl:versionInfo`; `dct:created/modified/creator`; `prov:wasAttributedTo` + `prov:generatedAtTime`; `dct:source`; and the build-metadata validation status (e.g. `adjmeta:validationStatus adjmeta:DraftPendingSMEValidation`) with an explicit draft disclaimer in `rdfs:comment` until SME validation completes.

---

## 7 · Modular architecture and the import DAG

### 7.1 Layers

```
Layer 3 · meta      misc/competency · resource/ samples     — consume everything; nothing imports them
Layer 2b · claims   evidence → adjudication → concern modules → decision-trace   (authored under this standard)
Layer 2a · ins      ins/policy · ins/claim · ins/coverage · ins/business         (IA-owned — import & subclass only)
Layer 1  · fnd      fnd/core · fnd/agreement · fnd/process                       (IA-owned; vendored skos/org/time/prov/dct)
```

Modules are **deliberately right-sized** — not one blob (AP-16), not a hundred shards. Each module answers a coherent cluster of competency questions and owns a coherent group of subject areas. Every subject area in scope is assigned exactly one home module; nothing is dropped.

### 7.2 Import rules

- **MUST:** the import graph is a **DAG**. Every edge runs upward; no path may return to where it started (AP-17, P-15). *Data may point back* — a decision trace may reference a coverage position without `coverage-position` importing `decision-trace` — *imports may not*.
- **MUST:** each module imports the process spine plus **only what it actually uses**, and nothing more.
- **MUST:** no sideways smuggling. If a shared concept emerges that two sibling modules need, it belongs one layer down — raise a change request to the foundation/domain layer owner; never create a lateral import.
- **MUST:** when a needed foundation module does not yet exist, author against a **shim** module with identical local names, and plan the migration as a MAJOR version bump with `dct:isReplacedBy` on every shimmed term. Never write into the foundation namespace yourself.
- **SHOULD:** pin `owl:imports` to a specific `versionIRI` in anything you release; float to latest only in development (V6).

### 7.3 Artifact separation — five artifacts, five jobs, five files

| Artifact | Answers | Logic | Language | Directory |
|---|---|---|---|---|
| Ontology (T-Box) | What does this mean? What can be inferred? | Open-world (OWL 2 DL) | OWL | `ontology/` |
| Vocabulary | What are the allowed values? | Reference data | SKOS | `vocabulary/` |
| Shapes | Is this data valid and complete? | Closed-world | SHACL | `shapes/` |
| Competency questions | What must the model answer? | Tests | `cq:` + SPARQL | `competency/` |
| Samples (A-Box) | What does a real instance look like? | Fixtures | Instance RDF | `samples/` |
| *(generated)* Context | How does an app consume it? | — | JSON-LD | `context/` |

**Rule of thumb:** if a human authors it or a reasoner consumes it → Turtle. If an application consumes it → JSON-LD, generated. Never hand-author JSON-LD; never author SHACL or OWL in JSON-LD. Shapes and CQs use the same filename stem as their module. One `CHANGELOG.md` per module.

---

## 8 · Modelling patterns and guardrails

### 8.1 The six shapes — choose before you write

Run every candidate concept through one question first: *is this a genuine kind of thing — or a thing in a state, a thing playing a role, a value it holds, a part of something, or one particular thing?* Almost every modelling error in this domain is one of those wearing the mask of a class.

| | If the concept is… | Test | Model it as |
|---|---|---|---|
| **A** | A genuine kind | "Every X is a Y" is true for **all** members | `rdfs:subClassOf` the parent kind |
| **B** | A part / association | "X is a Y" false; "X is part of / relates to Y" true | An object property, with an inverse, under the foundation part-of / related-to properties |
| **C** | A role an agent plays | The agent can stop being it without ceasing to exist | The **role-reification triangle** (§8.2) |
| **D** | A value / code | It only ever labels or classifies | `skos:Concept` in a scheme — never an OWL class per code value |
| **E** | A particular | It names one specific thing | A named individual, linked by a property |
| **F** | An attribute it has | Something the thing **has**, not **is** | A datatype/object property, or a Quality / MoneyAmount node |

Domain applications of these: a file note is *not* a kind of claim (B); adjuster/claimant/attorney are roles (C); claim status, peril, document category, STP disposition are values (D); a named stage or gate is a particular (E); reserve amount, liability percentage, STP score are attributes (F) — and **money is never a bare decimal**: every amount is a MoneyAmount node with currency.

### 8.2 The two mandatory reification patterns

**The role-reification triangle** — copy exactly for every role. Three parts: a **role individual** carrying `core:roleProperty`; the **property** the role realises; and a **role-filler class** defined by an `owl:hasValue` restriction on `core:hasRole`:

```turtle
asg:AdjusterRole  a core:AgentRole ;
    rdfs:label "Adjuster role"@en ;
    core:roleProperty asg:adjuster ;
    skos:definition "The role a social agent plays when assigned to handle a
        claim or coverage line. Not a kind of person."@en .

asg:adjuster  a owl:ObjectProperty ;
    schema:domainIncludes claim:Claim, cvp:CoverageLine ;
    schema:rangeIncludes  core:SocialAgent ;
    rdfs:subPropertyOf core:isRelatedTo ;
    owl:inverseOf asg:isAdjusterFor .

asg:Adjuster  a owl:Class ;
    rdfs:subClassOf core:SocialAgent ;
    owl:equivalentClass [ a owl:Restriction ;
        owl:onProperty core:hasRole ; owl:hasValue asg:AdjusterRole ] .
```

No role (Adjuster, Claimant, Supervisor, Attorney, Payee, Witness, SIU Investigator, Vendor, …) is ever `rdfs:subClassOf core:Person` (P-16): the same person may be a claimant on one claim and a witness on another. Where the role is a contract party, use the agreement-layer `PartyRole` in place of `AgentRole`. Reuse an already-minted role (e.g. `claim:ClaimantRole` in `ins/claim`) rather than re-minting.

**The reified n-ary pattern.** The most important facts are n-ary: a decision at a gate using a document; an evidence use with a disposition and observations; an identity link with confidence. Reify them as first-class classes with **global IRIs** — never a junction-table-shaped blank node, and never flattened to a datatype property.

**Plan vs. execution.** Prospective concepts (process definition, stage, gate — `prov:Plan` / `p-plan:` altitude, one individual shared by every claim) are strictly separate from retrospective ones (stage execution, gate evaluation — `prov:Activity`, one per claim). Executions link back to their plan via `prov:hadPlan`. Status is a time-indexed **StatusAssignment**, never a mutable flag; derived measures (e.g. reporting lag) are computed in a view or SPARQL, never double-stored.

### 8.3 The hard stops (prohibited moves)

| # | Never | Instead |
|---|---|---|
| P-1 | `rdfs:subClassOf` to inherit properties | Association, role reification, or a SKOS value |
| P-2 | An OWL class per code value (peril, status, document type…) | `skos:Concept` in a `skos:ConceptScheme` |
| P-3 | `owl:oneOf` for a code list | SKOS scheme + `sh:in` (`owl:oneOf` only with `owl:AllDifferent`, for a small closed set feeding a required inference, documented) |
| P-4 | `owl:cardinality` / `minCardinality` to make a field mandatory | `sh:minCount` / `sh:maxCount` with `sh:message` |
| P-5 | `rdfs:domain` as an "only allowed on X" constraint | `schema:domainIncludes` + `sh:targetSubjectsOf`/`sh:class` |
| P-6 | A datatype property typed `owl:InverseFunctionalProperty` | `owl:hasKey ( … )` on the class |
| P-7 | Cardinality or `owl:FunctionalProperty` on a transitive property | Counts on a simple property designed for it |
| P-8 | `schema:Claim` for an insurance claim | The domain `claim:Claim` — `schema:Claim` is a fact-checking claim |
| P-9 | Re-minting `skos:`, `prov:`, `time:`, `org:`, `dct:` under your own host | Reuse at canonical IRIs; local axioms in your own module |
| P-10 | Deriving class structure from source tables or an ACORD XML payload | Mine them for terms; structure from the domain and CQs |
| P-11 | A version number inside a term IRI or namespace | `owl:versionIRI` only |
| P-12 | Deleting a published term | `owl:deprecated true` + `dct:isReplacedBy` |
| P-13 | Adding a concept to a scheme you do not own (ACORD, ICD-10, shared perils) | Mint in your own scheme + `skos:*Match` |
| P-14 | `owl:sameAs` to merge two source records for the same party | A reified identity link carrying method, confidence, timestamp |
| P-15 | An import cycle | Data may point back; imports may not |
| P-16 | A role modelled as `⊑ core:Person` | The role-reification triangle |
| P-17 | A state ("closed claim", "litigated claim", "CAT claim") as a subclass | A status property + a time-indexed assignment |
| P-18 | Free-text `rdfs:comment` as the only definition | `skos:definition` required on every class and property |

### 8.4 The five failure modes reviewers watch for

1. **Hierarchy explosion** — a subclass per state, LOB, status, geography (`GLSlipAndFallClaimInCalifornia`). These dimensions are properties or SKOS values, never subclasses.
2. **Concept–instance confusion** — a document *category* modelled as a class. Categories are `skos:Concept`; document instances are individuals of one small class tree.
3. **Inconsistent taxonomy** — synonym sprawl. One naming policy + one prefix registry.
4. **Property sprawl** — one property per meaning; reuse `prov:`/`time:`/`dct:` before minting.
5. **Modelling by association** — a term with no workbook cell and no CQ behind it. Do not build it.

Additional taxonomy pitfalls: demote named vendors/firms/providers to instances (instance trap); industry/occupancy types are SKOS concepts on one structural class (industry trap); traverse hierarchies fully then subtract closures (diamond trap); prune inherited code-list leaves without evidence of use, and log what was dropped (threshold illusion).

**Disjointness discipline.** Declare `owl:AllDisjointClasses` for partitions you are certain of — without them the reasoner has nothing to falsify (e.g. Person ⊥ Organization; Decision ⊥ Document ⊥ Rule; a coverage line is not a claim). But never combine disjointness with `rdfs:domain` on shared identifier properties — that is the exact explosion R-2 (§9) exists to prevent.

---

## 9 · RDFS vs OWL vs SHACL — where each rule belongs

> **Reasoning adds facts you didn't state. Validation rejects data you don't want.** Model meaning in RDFS/OWL; enforce quality in SHACL — and never ask one to do the other's job.

| Dimension | RDFS | OWL 2 DL | SHACL |
|---|---|---|---|
| Job | Name & relate terms | Define meaning precisely | Validate data shape |
| World assumption | open | open | **closed** over targets |
| A missing value means | unknown | unknown | **a violation** |
| Can it reject bad data? | no | **no** | **yes** |
| Effect | infers a little | infers a lot | reports; changes nothing |

### The three rebuttal rules (normative — they override any contrary instinct)

**R-1 — Cardinality: shapes count; axioms classify.** Mandatory/single-valued → `sh:minCount`/`sh:maxCount`. Uniqueness across records → SHACL-SPARQL, not `owl:InverseFunctionalProperty`. Automatic classification → `owl:equivalentClass` + `someValuesFrom`, with the intended inference documented. *Why:* under the open world a missing "mandatory" value silently passes `minCardinality`; two literals on a cardinality-1 property make the **whole model inconsistent**. Under-constrained OWL is harmless; over-constrained OWL is poison.

**R-2 — Property signatures: `rdfs:domain` converts, it does not check.** Default: `schema:domainIncludes`/`rangeIncludes` as the signature, plus `sh:targetSubjectsOf` + `sh:class` + `sh:message` for enforcement. Use `rdfs:domain`/`range` only where the type inference is deliberately wanted on trusted data, documented and disjointness-audited. *Why:* one glitched triple silently re-types an individual; combined with disjointness, the entire ontology becomes inconsistent and entails everything. SHACL reports one record, loudly.

**R-3 — Code lists: SKOS scheme, not `owl:oneOf`.** Default: `skos:ConceptScheme` + `sh:in`. *Why:* adding one value under `owl:oneOf` means editing a published axiom, a release, and every consumer re-importing; and without `owl:AllDifferent` a resource carrying two values makes the reasoner infer they are `owl:sameAs` — silently, model-wide.

**Pipeline order (MUST):** load and merge the modules → run the DL reasoner to materialise inferences → run SHACL **over the reasoned graph**. Meaning first, quality gate second. A shape validated against raw triples misses every inferred type.

---

## 10 · Controlled vocabularies (SKOS)

| Rule | Level | Requirement |
|---|---|---|
| **CV-1** | MUST | Model every controlled vocabulary as a `skos:ConceptScheme` of `skos:Concept`s — never a hierarchy of OWL classes. |
| **CV-2** | MUST | One scheme per file, in its own `/vocabulary/` namespace, versioned and prefixed exactly like an ontology module (NS-4…NS-8 apply unchanged). |
| **CV-3** | MUST | Every concept: one `skos:prefLabel` per language + a scheme link (`skos:inScheme`, or `skos:topConceptOf` for roots). |
| **CV-4** | MUST | The business code goes in `skos:notation`, not the IRI. The local name is a stable, readable token. |
| **CV-5** | SHOULD | `skos:altLabel` for synonyms and ACORD/AIM terms; `skos:hiddenLabel` for misspellings and retired forms; keep the three label types disjoint. |
| **CV-6** | MUST | Hierarchy via `skos:broader`/`narrower` (asserted one level at a time; query with `broaderTransitive`); association via `skos:related`; never both between the same pair. |
| **CV-7** | MUST | The ontology references a scheme by `rdfs:range skos:Concept`, constrained to the scheme in SHACL (`sh:in` / scheme-membership shape). Codes are never embedded as classes. |
| **CV-8** | MUST | Extend a scheme you don't own from your own scheme, linking with `skos:broadMatch`/`narrowMatch`/`exactMatch`/`closeMatch`/`relatedMatch`. Never add, renumber or delete another team's concepts — including ACORD code sets, ICD-10, CPT. |
| **CV-9** | MUST | Deprecate, don't delete: `owl:deprecated true` + `skos:historyNote`/`changeNote`, IRI and notation stable forever. |
| **CV-10** | SHOULD | Record `dct:creator`, `dct:issued`, `dct:modified`, `owl:versionInfo` and a **named steward** on every scheme. |

Reserve `skos:exactMatch` for genuine equivalence — it is transitive and symmetric, so a careless one propagates. When two concepts are "basically the same" but you are not certain, `skos:closeMatch` is the honest choice. Where ordering matters (stage order, severity tiers), use a `skos:OrderedCollection` — never abuse `skos:broader`.

---

## 11 · Data governance

### 11.1 Ownership and stewardship

| Artifact | Owner | Cadence |
|---|---|---|
| `fnd/*`, `ins/*` (foundation and insurance domain) | Information Architecture | Slow, heavily reviewed; **change requests only** |
| `claims/*` modules and shapes | Claims Data & Semantics team | Own sprint cadence |
| `/vocabulary/claims/*` schemes | Named scheme steward per scheme | Independent of the model's clock |
| Mappings | Source-facing teams | Own clock |
| Ontology contract, IRI policy, identity crosswalk | Central platform function | — |
| Foundation edits and cross-domain changes | Change-review board | Planned, announced, batched |

**Promotion upward.** When two lines of business independently need a `claims/` term, that cross-team demand — not proof of use in one LOB — is the signal to promote it to `ins/`. IA generalises the term, mints a permanent `ins/` IRI; the local term becomes `owl:deprecated true` + `dct:isReplacedBy`, resolving throughout the compatibility window. Never deleted.

### 11.2 The nine review gates

A change ships only when **all nine** pass (gates 6 and 7 run in CI):

1. **Justified by a competency question.**
2. **Reuse-checked** against the standards baseline (§4).
3. **Right module and right altitude** (layer, import direction).
4. **Pattern-sound** (§8 — six shapes, triangles, n-ary, no prohibited moves).
5. **Named per the namespace and naming policy** (§5–6).
6. **Reasoner-consistent under OWL 2 DL.**
7. **SHACL and CQ regression green.**
8. **Impact-classed for versioning** (§12).
9. **Documented** — `skos:definition`, `dct:source`, changelog entry.

### 11.3 Open questions and gaps

- Every open SME question is emitted with `skos:editorialNote` + the open-question build flag, carried in the conformance report, and assigned an owner. It is never silently resolved either way.
- Known gaps (concepts with no source anywhere) are **modelled so the gap is visible** rather than silently absent, and tracked in a gap register with IDs referenced from the terms (`gapId` annotation).
- Terms grounded only in external references (not yet SME-validated) carry a `skos:editorialNote` stating so, with the date.
- Build state is **queryable**: an annotation vocabulary (readiness, source availability, build wave, mapping status, validation status, workbook reference, extraction-target and open-question flags) rides on every term. Annotation properties never participate in reasoning.

---

## 12 · Versioning and change management

| Rule | Requirement |
|---|---|
| **V1** | Two identities per module: a permanent ontology IRI + a per-release `owl:versionIRI`. |
| **V2** | Version by **consumer impact** — breaking → MAJOR, additive → MINOR, editorial → PATCH. |
| **V3** | Permanent term IRIs. Never a version number in a term or namespace IRI. |
| **V4** | Deprecate, don't delete: `owl:deprecated true` + `dct:isReplacedBy`; remove only in a later major release after a stated window. |
| **V5** | Stamp every release: `owl:versionInfo`, `owl:priorVersion`, `owl:backwardCompatibleWith`/`incompatibleWith`, `dct:created`, `dct:modified`. |
| **V6** | Pin imports to a specific `versionIRI` in anything released; float only in development. |
| **V7** | Capture every change once, in one authoritative place; generate the rest. |

**Classify every change:**

| Change | Level |
|---|---|
| Add a class, property or subclass; loosen a constraint; deprecate (keeping) a term | minor |
| Labels, definitions, typo fixes | patch |
| **Tighten a constraint; add disjointness or cardinality** | **major** — an addition can still break |
| Remove or rename a term; move a namespace | major |
| **Redefine a term's meaning keeping its IRI** | **major — and the most dangerous change of all. Prefer deprecate + mint new.** |

The one question before any edit: *could this invalidate someone's data, or change an inference they rely on?* Yes → MAJOR, with a deprecation path.

**Changelog, three tiers** — keep one authoritative, generate the rest: (1) *raw* — a git tag per release matching the `versionIRI` plus an **axiom-level diff** (e.g. `robot diff`; git line diffs misread moved axioms); (2) *curated* — `CHANGELOG.md` per module, Keep-a-Changelog categories, entries tagged by term and level; (3) *queryable* — per-term `skos:changeNote`/`dct:modified`/`owl:deprecated`/`dct:isReplacedBy`, plus (for a regulated, multi-team programme) a PROV-O version chain and reified change-record individuals.

**Release workflow:** Detect (axiom diff) → Classify → Bump → Stamp → Record → Validate (syntax → DL consistency → SHACL → CQ regression) → Publish (archive at the `versionIRI`; serve latest at the permanent IRI) → Announce.

---

## 13 · Provenance strategy

**Provenance is not optional in a regulated domain.** Every fact in the graph must be able to answer: *where did you come from, and by what process?* PROV-O is the backbone, at four levels:

| Level | Mechanism | When to use |
|---|---|---|
| Dataset | DCAT + PROV | Catalogue-level lineage for the served graph |
| **Named graph** | One graph per source or extraction run; PROV attached to the graph IRI | **The default.** Per-source, per-run lineage for free on every triple inside |
| Statement | RDF 1.2 triple terms | **Only** for entity-resolution link confidence and a single contested extracted value |
| Resource | `prov:wasDerivedFrom` / `dct:source` | Simple per-entity origin |

Mandatory practices:

1. **Separate the provenance graphs.** Provenance can dwarf the facts it describes; partition it into its own named graphs so it stays queryable without bloating everyday queries.
2. **Mark what the reasoner inferred.** Run inference as a `prov:Activity`, land its output in its own named graph, attribute it. A consumer must always be able to separate *stated by a source of record* from *extracted from prose* from *derived by a reasoner*.
3. **Provenance is emitted as a byproduct of running pipelines.** Hand-authored provenance is never complete and never trusted.
4. **Extraction provenance is first-class.** Every fact lifted from unstructured text is an `ExtractedFact` (`prov:Entity`) produced by an `Extraction` (`prov:Activity`) with a **pinned model version as `prov:hadPlan`**, an operator, a timestamp, a confidence score, and a **document anchor** (`prov:wasDerivedFrom` the exact document, page, offset). Nothing is promoted from extracted fact to a first-class decision term without passing its SHACL shape and a stated, recorded confidence threshold. Extracted facts never overwrite source-of-record facts — they are additive and separately attributed.
5. **Process provenance follows plan-vs-execution** (§8.2): executions and evaluations are `prov:Activity`; decisions and traces are `prov:Entity` with `prov:wasAttributedTo` (accountability) and `prov:wasDerivedFrom` (evidential basis); human accountability is expressed with `prov:qualifiedAssociation` + `prov:hadRole` where the role matters.

---

## 14 · Lineage and source-mapping strategy

### 14.1 Mapping principles (M1 … M7)

| Rule | Requirement |
|---|---|
| **M1** | The ontology is the target. Every mapping emits ontology terms, never a copy of the source structure. |
| **M2** | Declarative, not bespoke: R2RML/RML over hand-written transform code. |
| **M3** | Stable IRIs are the join: canonical IRIs from source keys with fixed templates (§5). |
| **M4** | One mapping module per source, versioned and released on its own clock. |
| **M5** | Reference data becomes vocabulary: lookup/code tables map to SKOS concepts; source codes resolve via `skos:notation`. Normalise datatypes, units and currencies at the mapping. |
| **M6** | Materialize vs. virtualize per source: virtualize queryable databases; materialize APIs, files and extraction output. |
| **M7** | **Capture the lineage: source column → mapping rule → ontology term.** |

### 14.2 Map over views, never over tangled tables

Legacy schemas are rarely mappable cleanly. Do not contort the mapping — put a **curated SQL view** between the schema and the mapping and let the view do the untangling. The mapping stays a clean statement of meaning; join logic lives where SQL belongs. As sources migrate onto curated layers, the mapping changes; **the ontology contract does not**.

### 14.3 The extraction pipeline is not a mapping

Concepts that exist only in unstructured text (file notes, attached documents) have a **pipeline**, not a mapping, and its trace *is* the graph's provenance (§13). Every emitted triple lands in a named graph per extraction run with PROV attached to the graph IRI.

### 14.4 Identity — the governed exception to virtual-first

The same party appears in multiple systems and in free text. Resolution rules: deterministic keys first (policy number, tax ID, MDM golden record); probabilistic matching for people with tunable thresholds; **never bare `owl:sameAs`** (P-14) — emit a reified identity link carrying source key, canonical IRI, method, confidence and timestamp so merges are auditable and reversible; **materialize the crosswalk** (expensive, non-deterministic, human-reviewed); steward the ambiguous band through a queue, capturing decisions as data.

### 14.5 Traceability

Mappings are engineered artifacts: version-controlled, tested against competency questions over sample data, CI-gated (mapping syntax → run over a sample → SHACL conformance on the output → CQ regression), lineage-tracked, and clearly owned. Every ontology term derived from a source carries `dct:source` citing the workbook tab/row or system table; a traceability matrix connects source element → mapping rule → ontology term → competency question. This is the audit answer to *"where does this number on the dashboard come from?"* — end to end.

---

## 15 · Privacy, security and AI governance

### 15.1 Classify before you expose

**You cannot protect what you have not labelled.** Tag every predicate that carries personal data at declaration time with DPV (`dpv:hasPersonalDataCategory`): identifying data on parties; **health data as special category** (diagnoses, injuries, treatments, disability ratings); financial and employment data (wage-loss valuations); location data (addresses, incident narratives — quasi-identifier risk); **free text is assumed to contain everything** (`dpv:Identifying` on note text, statement text, summaries); network/fraud link data is the highest sensitivity in the model. Note DPV's status honestly: a W3C Community Group report, not a Recommendation — use it and state the status.

### 15.2 Graph-specific hazards and mitigations

| Hazard | Mitigation |
|---|---|
| Aggregation/mosaic re-identification | Query auditing; minimum-count thresholds; cell suppression on small-population analytics |
| Inference leakage | Treat inferred triples as **at least as sensitive as their inputs**; decide deliberately whether reasoning runs before or after authorisation |
| Re-identification via quasi-identifiers | Generalise (exact date → month; address → county); k-anonymity thresholds; test before publishing |
| The super-user pitfall | **Propagate the end-user identity** to each source; never a shared privileged service account |
| Erasure | Minimise what is materialised about people; keep provenance so every copy is findable; prefer pseudonymisation so "forgetting" can mean destroying one crosswalk key; decide tombstone-vs-hard-delete deliberately |

**Access control:** named graphs are the default boundary (one per source and sensitivity tier); model policy **as data** with ODRL so it is queryable, testable and auditable alongside the graph it governs; deny by default, least privilege, periodic grant review; log every access immutably (principal, query, purpose, result).

### 15.3 AI governance — regulatory expectations as data

The NAIC AI Model Bulletin expects a documented AIS programme covering claim administration, with accountability and documentation producible on examination. The ontology carries this as **first-class classes, not annotations**:

| Expectation | Ontology answer |
|---|---|
| Which AI systems act on claims, and what they predict | AI model + AI output + prediction type, versioned |
| Reproducibility of historical decisions | Model version/vintage on every output |
| Human accountability per decision | Decision attribution + qualified association with role |
| Override rate and reasons | Human override as a `prov:Activity` with reason and rationale |
| Factors driving a score | Reified scoring/fraud factors |
| Audit trail for no-human-touch decisions | STP audit log as a first-class class |
| Monitoring, drift, retraining evidence | Ground-truth labels linked to predictions |
| Audit findings and remediation | Audit record → finding → remediation chain |

The **decision trace** is the integrative pattern: for every decision at every gate — the evidence consulted (with disposition: used / not used / sometimes), what was referenced and recorded, the stated rationale (extracted from the file note with method, confidence and anchor), the AI recommendation, the human override, and the audit outcome.

---

## 16 · Quality assurance and the CI pipeline

Every commit runs, in order — a failure at any step blocks the merge:

1. **Syntax** — all Turtle parses.
2. **Namespace & naming lint** — NS-1…NS-10, prefix registry conformance, naming conventions, mandatory metadata present (labels, definitions, `isDefinedBy`, `dct:source`, signatures).
3. **Closed-world predicate lint** — every predicate used is declared somewhere in the import closure (catches typo-minted phantom terms, AP-12).
4. **Import DAG check** — acyclicity; no undeclared or sideways imports.
5. **OWL 2 DL profile check + reasoner consistency** over the merged closure.
6. **SHACL over the reasoned graph** — shapes green against the sample A-Box.
7. **CQ regression** — every competency question returns the expected answers over the samples; validation CQs (where an **empty result is the passing state**) return empty.
8. **Mapping gates** — mapping syntax; execution over sample source data; SHACL conformance of the output; CQ regression over mapped data.
9. **Conformance report** — generated per release: pipeline results, coverage (terms per module, alignment counts, PII-tagged predicate count), open questions carried forward, deviations from the specification.

**Anti-pattern review.** Reviewers walk changed axioms against the twenty-anti-pattern checklist (subclass-for-attribute, value-as-class, role-as-subclass, OWL-as-validator, vacuous restrictions, missing disjointness, God ontology, import cycles, no CQs, premature abstraction, and the rest of §8).

---

## 17 · Definition of done

A module (or release) is **done** when:

- [ ] Every term traces to a source cell (`dct:source`) **and** a competency question.
- [ ] Reuse checked: no term duplicates the W3C / OMG / FIBO / ACORD / FHIR baseline; alignments recorded (`skos:*Match`, `skos:altLabel` for AIM terms).
- [ ] All names, IRIs, prefixes and files conform to §5–6; the prefix registry is unchanged or formally extended.
- [ ] All code lists are SKOS schemes with stewards; no class-per-code anywhere.
- [ ] All roles use the triangle; all n-ary facts are reified with global IRIs; plan and execution are separate; money is a MoneyAmount; status is time-indexed.
- [ ] No prohibited move (P-1…P-18) and no anti-pattern (AP-1…AP-20) present.
- [ ] Constraints live in SHACL; meaning lives in OWL; the reasoner is consistent; shapes and CQ regressions are green **over the reasoned graph**.
- [ ] Every PII-bearing predicate carries a DPV category; access policies exist as ODRL data; named-graph partitioning is defined.
- [ ] Provenance: named graphs per source/run; extraction facts carry activity, plan (model version), confidence and anchor; inferred triples are separately attributed.
- [ ] Lineage: mappings declarative, view-backed, versioned, tested; IRI templates stable; identity links reified, never `owl:sameAs`.
- [ ] Versioned per §12: versionIRI stamped, imports pinned, changelog written, changes impact-classified, deprecations (not deletions) in place.
- [ ] Open questions and gaps are flagged, owned, and listed in the conformance report — none silently resolved.
- [ ] All nine review gates (§11.2) passed.

---

## 18 · Reference registers

### 18.1 Normative prefix registry (extract)

One prefix, one namespace, everywhere. W3C/standards prefixes at canonical IRIs (`rdf`, `rdfs`, `owl`, `xsd`, `sh`, `skos`, `skosxl`, `prov`, `p-plan`, `time`, `org`, `dcat`, `odrl`, `rr`, `rml`, `dct`, `vann`, `dpv`, `schema`, `qudt`). Foundation (`core`, `agr`, `proc`) and insurance-domain (`policy`, `claim`, `coverage`, `biz`) prefixes are import-and-subclass only. Claims-layer module prefixes (`evd`, `adj`, `dtr`, `itk`, `cvp`, `asg`, `inv`, `lia`, `med`, `itm`, `val`, `fin`, `stl`, `rcv`, `ltg`, `fra`, `stp`, `cmp`, `adjmeta`) are authored under this standard. Vocabulary prefixes (e.g. `adjstage`, `gate`, `doctype`, `cvpos`, `outcome`, `crole`) resolve under `/vocabulary/`; shared insurance schemes (`peril`, `lob`, `col`) are read-only. Instance data resolves under `res:` (`/resource/`). The full registry lives with the build specification and is the single source of truth.

### 18.2 Standards referenced

W3C: RDF 1.1/1.2, RDFS 1.1, OWL 2, SHACL, SPARQL 1.1, SKOS/SKOS-XL, PROV-O, OWL-Time, ORG, DCAT, ODRL 2.2, JSON-LD 1.1, R2RML; community: RML, P-Plan, VANN, DPV v2. OMG/EDM Council: FIBO, Commons, LCC, DTV, DMN, SBVR, BPMN, CMMN. ACORD: Information Model (AIM), Business Glossary, Capability Model, Process Model, code sets. HL7: FHIR (Claim/ClaimResponse, Condition, Procedure, EOB), adjudication terminology. Clinical codes: ICD-10-CM, CPT/HCPCS, X12 CARC/RARC. Regulatory: NAIC Model #900, NAIC AI Model Bulletin (2023), ISO ClaimSearch, state DOI reporting.

---

*This standard is itself versioned. Propose changes through the change-review board; classify their impact per §12; and record every accepted change in this document's changelog.*