Asset Exposure Ontology (aeo:): Design Sketch

Version 0.2, draft for review. A sketch of the asset exposure ontology for a reference build of LATTICE’s applied insurance domain (lattice/ontology/applied/insurance). It describes what an insured owns, uses or depends on, where it is, what it is worth, how it is built and protected, what it is exposed to, what has happened to it, and what cover its owners require. It maps every construct onto LATTICE, and it is the main consumer of the reference peril vocabulary outside the contract. The whitepaper covers the structural questions the two share.

Citations of design-spec and of codes AP, DP, D and I refer to Open CBAA’s design specification and LATTICE integration specification. Where this sketch and the applied insurance reference epic or its ADRs (A-98 to A-102) differ, they take precedence.

1. Purpose and Position

2. Principles

3. Namespaces, Layout and Versions

ontology/applied/
    capacity/           cross-domain: finite resources and their allocation
    classification/     cross-domain: territory, asset class and industry contracts (§7)
    insurance/
        common/         insurance scheme contracts, liability role types, loss event (§7)
        peril/          the reference peril vocabulary (peril vocabulary §4)
        exposure/       this module
            spec/exposure.ttl           owl:versionIRI …/insurance/exposure/0.1.0
            vocab/exposure-vocab.ttl    owl:versionIRI …/insurance/exposure-vocab/0.1.0
            shapes/structural.ttl, constraints.ttl, profiles/*.ttl, .version
            examples/
        submission/     placement packages over exposure (§1)
        claims/         claims, loss cause chains, claimant roles
        contract/       coverage, layers, term parameters (term parameters §9), deferred

The applied insurance directory today holds one module whose shapes and vocab sit in shared shapes/ and vocab/ directories. Under LATTICE’s versioning policy (ADR-A86 and its addendum) a shapes directory is versioned by its .version file, so two modules sharing one directory would bump each other. Each sub-folder above is therefore a module with its own spec, vocab, shapes and .version. A module sits at the lowest level of sharing that covers its users: cross-domain modules beside the domains, insurance-only shared content in insurance/common/. Scheme structural capabilities are part of Vocabulary, not an applied module (ADR-A100). Dependencies run one way: classification/ on the substrate only, insurance/common/ on it and the substrate, peril/ on common/, exposure/ on common/ and peril/, submission/ on exposure/, claims/ on exposure/ and contract/.

4. Dependencies

flowchart BT
    fnd[Foundation] --- voc[Vocabulary] --- qnt[Quantification]
    pty[Party] --- ins[Instrument] --- elg[Eligibility]
    common["insurance/common<br/>shared scheme contracts"] --> voc
    aeo["insurance/exposure (aeo:)"] --> fnd & voc & qnt & pty & ins & elg & common
    ctr["insurance/contract (ctr:)"] --> common
    ctr -. "references exposure units, never imported by aeo" .-> aeo
    cbaa["Open CBAA rsk:, agr:"] -. "exposure units as cases (§11)" .-> aeo
    peril["peril editions (Open CBAA reference or market)"] -. "bound by scheme contract, not imported" .-> common

aeo: imports the LATTICE layers it uses by exact version IRI, each explicitly (layers import only Foundation). It never imports the contract module: links from contracts to exposure are the contract module’s properties. Peril, territory and asset class editions are bound, not imported (DP8).

5. Core Model

flowchart LR
    ES["aeo:ExposureSet<br/>fnd:Version"] -->|aeo:hasLocation| L["aeo:Location"]
    ES -->|aeo:hasAsset| A["aeo:Asset"]
    A -->|aeo:locatedAt| L
    A -->|aeo:partOf| A
    I["aeo:Interest"] -->|aeo:interestIn| A
    I -->|aeo:interestHolder| RO["pty:RoleOccupancy"]
    V["aeo:Valuation"] -->|aeo:valueOf| A
    V -->|aeo:amount| Q["qnt:Quantity"]
    AS["aeo:Assessment"] -->|aeo:assesses| A
    AS -->|aeo:assesses| L
    AS -->|aeo:hasAttribute| AV["aeo:AttributeValue"]
    L -->|aeo:zoneDesignation| Z["aeo:ZoneDesignation"]
    D["aeo:Dependency"] -->|aeo:dependent| L
    D -->|aeo:provider| L
    PM["aeo:PerilMetric<br/>fnd:DerivedArtefact"] -->|aeo:perilScope| P["peril concept"]
    PM -->|aeo:metricSubject| ES
    LR["aeo:LossRecord"] -->|aeo:lossAt| L
    R["aeo:CoverageRequirement"] -->|aeo:requirementScope| E["elg:AdmissionProfile"]
    R -->|aeo:arisesFrom| OB["ins:Obligation"]
    EU["aeo:ExposureUnit"] -->|aeo:unitLocation| L

5.1 Parties, roles and control

The insured is a pty:Actor. AEO adds aeo:LegalEntity ⊑ pty:Actor for organisations with identifiers (aeo:identifier to an aeo:Identifier node carrying scheme and value, since LEIs, registration and tax numbers are several schemes) and uses pty:Actor directly for persons.

Roles in the insured’s programme are pty:Role individuals in aeo-voc: (named insured, first named insured, additional insured, loss payee, mortgagee, lessor, bailor), filled by pty:RoleOccupancys. An occupancy is time-scoped and evidenced by Party, which is what an additional-insured or mortgagee clause needs. Parties who might claim against the insured are not named here. They are described as populations (§5.15).

Control between legal entities is aeo:ControlRelation ⊑ fnd:TemporallyScoped ⊓ fnd:Evidenced, with exactly one aeo:controller and one aeo:controlled, a aeo:controlKind (subsidiary, affiliate, joint venture, branch, franchise) and an optional aeo:controlShare (a qnt:Quantity on the proportion space). Reified because ownership has a share and a period. A transitive shortcut (aeo:withinGroupOf) is generated as a derived artefact for consolidated queries, never asserted, and a shape rejects cycles.

5.2 Exposure set

aeo:ExposureSet ⊑ fnd:Version ⊓ fnd:Governable ⊓ fnd:TemporallyScoped ⊓ fnd:Evidenced
               ⊓ =1 fnd:hasIdentity.aeo:ExposureIdentity
               ⊓ =1 aeo:reportingUnit.qnt:Unit

A versioned snapshot of one insured’s schedule. The identity follows the schedule across renewals, each version is a schedule at an as-of date (its temporal scope starts there), and its governance state is the record’s (Draft while being assembled, Active when submitted, Superseded by the next). Members are linked by aeo:hasLocation, aeo:hasAsset, aeo:hasInterest, aeo:hasValuation, aeo:hasAssessment, aeo:hasDependency, aeo:hasPerilMetric, aeo:hasLossRecord, aeo:hasRequirement and aeo:hasExistingCover, all inverse functional, so a member node belongs to one version. Unchanged locations and assets are shared across versions by identity (§5.3), not by node.

Persistence: each exposure set version is an aggregate boundary (dal:AggregateBoundaryProfile, one named graph per version), written by compare-and-set, as Open CBAA does for agreement versions.

5.3 Location

aeo:Location ⊑ fnd:Version ⊓ =1 fnd:hasIdentity.aeo:LocationIdentity

A place where exposure sits: a site, a building footprint, a pipeline segment, a port. A version per change of address or geometry, one identity across schedules, so a location’s loss history and zone designations follow it.

5.4 Zones and pools

A hazard zone is not a territory and not a peril. A flood zone from a national map, a seismic design category, a wind-borne debris region or a wildfire interface class is a designation of a location under a published zoning scheme:

aeo:ZoneDesignation ⊑ fnd:Evidenced ⊓ fnd:TemporallyScoped
    ⊓ =1 aeo:zone.skos:Concept ⊓ =1 aeo:designationSource.skos:Concept

aeo:zone is bound per jurisdiction by a scheme contract with territory-scoped bindings (one flood zone scheme per national programme). The designation’s temporal scope is the map’s effective period, so a map revision does not rewrite history. A designation computed from coordinates is a derived artefact of a spatial join, with its derivation run.

aeo:PoolParticipation records that a location’s exposure to a peril is ceded to, or insured by, a pool or residual mechanism, with the pool concept (the peril vocabulary’s pool scheme), the peril scope and the temporal scope. The CBAA SoUA “applicable pool schemes” row reads it.

5.5 Asset and interest

aeo:Asset ⊑ fnd:Version ⊓ =1 fnd:hasIdentity.aeo:AssetIdentity ⊓ =1 aeo:assetClass.skos:Concept
          ⊓ ≤1 aeo:locatedAt.aeo:Location

Anything of value exposed to loss: a building, contents, stock, machinery, a vessel, a fleet, a crop, a data estate, an income stream (business income is an asset of the income kind, so it can have a location, dependencies and values like anything else). aeo:partOf (asymmetric, irreflexive) composes assets: critical equipment in a building, a building in a campus. aeo:locatedAt is functional for fixed assets. Mobile assets have aeo:Presence nodes (location, temporal scope, share of time or value) instead, which a shape enforces by asset class.

aeo:assetClass is bound to the insurance asset class scheme, crosswalked to the CBAA insurable interest hierarchy (Energy, Events and Intangibles, Fixed Property, Insured Persons, Movable Property, Occupations or Industries, Transport, with sub-groups and additional grain). The CBAA hierarchy classifies what a policy insures (an insurable interest) and the asset class classifies what exists, so the mapping is skos:broadMatch and skos:closeMatch, not identity.

An interest is a party’s stake in an asset:

aeo:Interest ⊑ fnd:TemporallyScoped ⊓ fnd:Evidenced
    ⊓ =1 aeo:interestHolder.pty:RoleOccupancy ⊓ =1 aeo:interestIn.aeo:Asset
    ⊓ =1 aeo:interestKind.skos:Concept

Kinds: owner, lessee, lessor, secured lender, bailee or custodian, beneficiary. aeo:extent is a qnt:Quantity (an allocated principal for a lender, a share for a co-owner). Interests carry what US lender covenants turn on (§10) and what “property of others in care, custody or control” and “tenants’ improvements” mean, without new asset classes.

5.6 Valuation

aeo:Valuation ⊑ fnd:Evidenced ⊓ fnd:TemporallyScoped
    ⊓ =1 aeo:valueOf.(aeo:Asset ⊔ aeo:Location) ⊓ =1 aeo:valueType.skos:Concept
    ⊓ =1 aeo:valuationBasis.skos:Concept
    ⊓ ((=1 aeo:amount.qnt:Quantity) ⊔ (=1 aeo:rate.qnt:Quantity ⊓ =1 aeo:horizon.qnt:Quantity))

Currency is never normalised in place. A value in another currency than the reporting unit is converted by a qnt:Conversion under a qnt:ConversionContext (the as-of date), and the converted figure is a derived artefact. A shape checks that any aggregation the set publishes (total TIV) is a derived artefact whose read set covers every contributing valuation.

5.7 Hazard attributes

Construction, occupancy, protection and external exposure (COPE) and every peril-specific secondary modifier are attribute values:

aeo:AttributeValue ⊑ =1 aeo:attributeType.skos:Concept
    ⊓ =1 (aeo:conceptValue ⊔ aeo:quantityValue ⊔ aeo:literalValue)

aeo:attributeType is a concept in the attribute type scheme (construction class, year built, year of major renovation, storeys, roof geometry, roof covering, opening protection, first-floor height, basement, soft storey, sprinkler type and coverage, detection, fire brigade response, distance to coast, defensible space, and so on), each with its COPE category as a classification and, for quantity-valued types, the qnt:ValueSpace its values are on. Concept-valued types name the scheme contract their values are drawn under (construction class schemes differ by market).

The peril vocabulary’s prl:relevantAttribute links perils to attribute types. A completeness shape reads it: for every peril in an exposure set’s requirement or metric scope, each asset of a relevant class should have the relevant attributes, and each missing one is a warning that a data request can be generated from.

5.8 Assessments and profiles

Attribute values are not attached to assets one by one. They come in assessments:

aeo:Assessment ⊑ fnd:Evidenced ⊓ fnd:TemporallyScoped
    ⊓ ≥1 aeo:assesses.(aeo:Asset ⊔ aeo:Location ⊔ pty:Actor ⊔ aeo:ExposureSet)
    ⊓ =1 aeo:assessmentKind.skos:Concept ⊓ ≥1 aeo:hasAttribute.aeo:AttributeValue

An assessment is one source’s account of one subject at one time: a survey report, a schedule row, a questionnaire answer set, an engineering inspection, a geocoder run. Profile families that carrier questions ask about (construction and protection, cyber posture, business continuity, environmental, fleet, compliance, operations and workforce, supply chain) are assessment kinds, not classes. Each kind has a shapes file in shapes/profiles/ stating which attribute types it requires and allows. A new question family is a new kind, attribute types and a shape, with no T-Box change (A3). A kind is promoted to a class only when its instances need properties an attribute value cannot carry, which none of the families above do.

Conflicting assessments of one attribute are kept, each with its evidence. Which one a consumer uses is a resolution policy (latest, highest precision, surveyed over declared), applied by the consumer and recorded as a derived artefact, never by overwriting.

5.9 Dependencies

Business interruption and contingent business interruption turn on how locations depend on each other and on third parties, which a flat supplier count cannot express:

aeo:Dependency ⊑ fnd:TemporallyScoped ⊓ fnd:Evidenced
    ⊓ =1 aeo:dependent.(aeo:Location ⊔ aeo:Asset)
    ⊓ =1 aeo:provider.(aeo:Location ⊔ aeo:Asset ⊔ pty:Actor)
    ⊓ =1 aeo:dependencyKind.skos:Concept

Kinds: supply of goods, utility, IT service, logistics, customer. Optional: aeo:shareAtRisk (proportion of the dependent’s output lost without the provider), aeo:recoveryLeadTime (duration to restore or replace, a qnt:Quantity), aeo:substitutability (concept: none, partial, full) and aeo:singleSource. Critical equipment is an asset with aeo:partOf its building and a replacement lead time on its assessment. Bottlenecks and maximum foreseeable interruption are derived from the graph, as derived artefacts, and are what a 24-month or 18-month indemnity period requirement is tested against.

5.10 Peril metrics

A modelled or scored measure of exposure to perils:

aeo:PerilMetric ⊑ fnd:DerivedArtefact ⊓ fnd:Evidenced
    ⊓ ≥1 aeo:perilScope.skos:Concept ⊓ =1 aeo:metricSubject.(aeo:ExposureSet ⊔ aeo:Location ⊔ aeo:Asset)
    ⊓ =1 aeo:metricKind.skos:Concept ⊓ =1 aeo:perspective.skos:Concept ⊓ =1 aeo:metricValue.qnt:Value

Hazard scores are metrics too (kind hazard score, value an ordinal or a quantity on a declared score space), so a vendor’s 1 to 10 and another’s A to F never share a space by accident.

5.11 Exposure units

Eligibility, authority checks and gap analysis evaluate a case with single-valued paths (ADR-A90 option B, Open CBAA D24). A location has many perils, many values and many assets, so it is a poor case. The exposure unit is the case:

aeo:ExposureUnit ⊑ fnd:DerivedArtefact
    ⊓ =1 aeo:unitLocation.aeo:Location ⊓ =1 aeo:unitAssetClass.skos:Concept
    ⊓ =1 aeo:unitPeril.skos:Concept ⊓ ≤1 aeo:unitValue.qnt:Quantity

One unit per location, asset class and peril in scope, with the value exposed. Units are generated (a derived artefact, reproducible from the exposure set and the peril edition), so the graph never asserts them by hand. Generation is lazy: a check may compute the units it needs from the source graph on the fly (route R1, term parameters §5), and only a deployment that profiles a need materialises them. The peril is read in the operative scheme of the contract being checked, and peril-dependent checks require only the capabilities that scheme’s profile has (MORK bridge §3, §6). They are what “flood cover for every property in a special flood hazard area with TIV over a threshold” is evaluated against, and what a percentage-of-TIV deductible reads its base from. Open CBAA’s rsk:Risk is the bound counterpart: one location, one deemed peril set, one sum insured (§11).

5.12 Loss history

aeo:LossRecord ⊑ fnd:Evidenced ⊓ =1 aeo:lossDate ⊓ ≤1 aeo:lossAt.aeo:Location

The chain is recorded because London and US causation rules read different elements of it (whitepaper §3.8). Each link is a node, so that a check across cause and characteristics reads values that belong together:

aeo:LossCause ⊑ fnd:Evidenced
    ⊓ =1 aeo:peril.skos:Concept ⊓ =1 aeo:causePosition.skos:Concept
    ⊓ ≤1 aeo:agency.skos:Concept

An Eligibility profile whose subject class is aeo:LossCause then evaluates one link at a time (peril vocabulary §6.8). Where the source records no agency or mechanism, an effective value is filled from the cause concept’s prl:typicalAgency or prl:typicalMechanism as a fnd:DerivedArtefact, so a reviewer can see it was defaulted. A drafter’s code that carries no typical values leaves the link without one, and a check reading it is Undetermined.

5.13 Coverage requirements

Requirements arrive from different sources with different force:

aeo:CoverageRequirement ⊑ fnd:Version ⊓ fnd:Evidenced
    ⊓ =1 aeo:requirementSource.skos:Concept
    ⊓ ≥1 aeo:requiredMeasure.aeo:MeasureConstraint

The ontology stops there. Whether a programme meets a requirement is gap analysis, computed by the contract side from these operands, and each gap is a derived artefact that cites the requirement and the coverage it compared.

5.14 Existing cover and financial metrics

aeo:ExistingCover records cover the insured already has or must have: an expiring programme, a national flood scheme policy that sits primary, a pool participation. It carries a reference to the contract (an IRI, the contract module owns the term), a peril scope, and its relation to the programme being placed (underlying, alongside, replaced).

aeo:FinancialMetric ⊑ fnd:Evidenced ⊓ fnd:TemporallyScoped carries revenue, gross profit, equity, payroll and headcount, each a qnt:Quantity with its period, and whether audited. Liability lines add market capitalisation, fees, turnover by territory and records held (§5.15).

5.15 Liability exposure

Liability, D&O and E&O cover respond to claims by parties who are mostly unknown when the contract is bound. Exposure to them is described by who could claim, how they relate to the insured and how many there are, never by named claimants:

aeo:CounterpartyPopulation ⊑ fnd:Evidenced ⊓ fnd:TemporallyScoped
    ⊓ =1 aeo:populationOf.pty:Actor
    ⊓ =1 aeo:populationKind.skos:Concept
    ⊓ =1 aeo:relationshipDepth.skos:Concept
    ⊓ ≤1 aeo:populationSize.qnt:Quantity

Securities listings are attribute values on the legal entity (exchange, listing kind, since), because securities claims turn on them and they differ in nothing else. Control relations (§5.1) say who is an insured when a group is covered, and dependencies (§5.9) with kind customer or supply give the intermediaries through which fourth parties reach the insured. Together they are the relationship graph from which a claim’s direction is derived when its roles are filled (term parameters §7). The contract names populations in its scopes, the claim fills the roles.

6. Property Characteristics and Axioms

Disjointness: exposure set, location, asset, interest, valuation, assessment, attribute value, dependency, peril metric, exposure unit, loss record, loss cause, requirement, existing cover, counterparty population and control relation are pairwise disjoint, and disjoint with pty:Actor.

Chains are not declared in the T-Box. The shortcuts consumers want (an insured exposed in a territory, an asset’s territory, a party’s consolidated exposure) are computed from the source graph on demand, or, where a deployment opts in, generated by Surface as derived relations, which keeps the ontology in OWL 2 RL-friendly territory for runtime materialisation and puts every shortcut under provenance.

7. Vocabularies and Scheme Contracts

icm: is insurance/common/ and cls: is the cross-domain classification/ module (§3). Prefixes are fixed by ADR-A98. One set of scheme contracts, on voc:SchemeContract, serves every insurance module and Open CBAA’s bindings, replacing the private governance vocabulary and duplicate schemes of the legacy contract module, which is dropped.

Value spaces declared in aeo-voc:: proportion, count, area, length (distance to coast and water, elevation, first-floor height), money per period (derived), and the intensity spaces the peril vocabulary declares, reused rather than redeclared.

8. Shapes

9. Mapping to LATTICE

10. Market Profiles: London and US

The core does not change between markets. A profile is a set of scheme bindings (scoped by market and legal regime) and a set of shapes that make market-required data mandatory.

For a CBAA binding authority, both profiles can apply at once: a London binder writing US risks binds the US profile’s schemes under a binding scoped to the London market and the US regime (peril vocabulary §9.1).

11. Integration with Open CBAA

12. Worked Example

Two fragments, one per profile. Names are fictional.

# London profile: a fabrication site with critical equipment and a supply dependency.
ex:site-a a aeo:Location ;
    fnd:hasIdentity ex:site-a-id ;
    aeo:territory ex:GB-England ;
    aeo:geoPrecision aeo-voc:Rooftop .
ex:fab-a a aeo:Asset ; fnd:hasIdentity ex:fab-a-id ;
    aeo:assetClass ex:SemiconductorFab ; aeo:locatedAt ex:site-a .
ex:litho-a a aeo:Asset ; fnd:hasIdentity ex:litho-a-id ;
    aeo:assetClass ex:ProcessMachinery ; aeo:partOf ex:fab-a .
ex:litho-a-survey a aeo:Assessment ;
    aeo:assesses ex:litho-a ; aeo:assessmentKind aeo-voc:EquipmentInspection ;
    aeo:hasAttribute [ aeo:attributeType aeo-voc:ReplacementLeadTime ;
                       aeo:quantityValue [ a qnt:Quantity ; qnt:onSpace aeo-voc:DurationSpace ;
                                           qnt:numericValue 24.0 ; qnt:inUnit aeo-voc:Month ] ] .
ex:bi-a a aeo:Valuation ;
    aeo:valueOf ex:income-a ; aeo:valueType aeo-voc:GrossProfit ; aeo:valuationBasis aeo-voc:Declared ;
    aeo:rate [ a qnt:Quantity ; qnt:onSpace aeo-voc:MoneyPerMonth ; qnt:numericValue 12000000.0 ; qnt:inUnit ex:GBPPerMonth ] ;
    aeo:horizon [ a qnt:Quantity ; qnt:numericValue 12.0 ; qnt:inUnit aeo-voc:Month ] .
ex:dep-a-b a aeo:Dependency ;
    aeo:dependent ex:site-b ; aeo:provider ex:site-a ; aeo:dependencyKind aeo-voc:SupplyOfGoods ;
    aeo:singleSource true ;
    aeo:shareAtRisk [ a qnt:Quantity ; qnt:onSpace aeo-voc:Proportion ; qnt:numericValue 0.6 ] .

# US profile: a coastal hotel in a flood zone with a secured lender.
ex:hotel-c a aeo:Location ; fnd:hasIdentity ex:hotel-c-id ;
    aeo:territory ex:US-FL ;
    aeo:zoneDesignation [ a aeo:ZoneDesignation ; aeo:zone ex:FloodZoneVE ;
                          aeo:designationSource ex:NationalFloodMap ;
                          fnd:hasTemporalScope [ fnd:validFrom "2024-06-01T00:00:00Z"^^xsd:dateTime ] ] ;
    aeo:poolParticipation [ a aeo:PoolParticipation ; aeo:pool ex:StateWindPool ; aeo:perilScope prl:N.MET.NS ] .
ex:lender-interest a aeo:Interest ;
    aeo:interestHolder ex:lender-as-mortgagee ; aeo:interestIn ex:hotel-c-building ;
    aeo:interestKind aeo-voc:SecuredLender ;
    aeo:extent [ a qnt:Quantity ; qnt:numericValue 95000000.0 ; qnt:inUnit ex:USD ] .
ex:covenant-flood a aeo:CoverageRequirement ;
    aeo:requirementSource aeo-voc:LenderCovenant ;
    aeo:arisesFrom ex:covenant-obligation ;           # ins:Obligation, obligor insured, obligee lender
    aeo:requirementScope ex:sfha-flood-units ;        # elg:AdmissionProfile: zone in SFHA, peril in AllFlood
    aeo:requiredMeasure [ a aeo:MeasureConstraint ; aeo:measure aeo-voc:Limit ; aeo:bound ex:at-least-principal ] .

13. Recommendations

For LATTICE’s applied insurance domain:

For LATTICE’s substrate, each subject to the clean-room procedure (a domain-neutral premise and two non-insurance examples first):

The whitepaper’s §7 lists these with costs, together with the peril vocabulary’s needs.