Modeling Engineering Performance Guarantee Insurance as an Ontology

Introduction: A Construction Performance Guarantee Insurance Scenario

A school hires a construction company for a 2 million RMB renovation, requiring a 100k performance guarantee via insurance. The construction company (policyholder) purchases performance guarantee insurance from an insurer, with the school as the insured. This scenario sets up the business context for ontology modeling.

Parties and Financial Amounts

The insurance involves three roles: policyholder (construction company), insured (school), insurer (insurance company). Three distinct monetary amounts exist:

Construction contract amount: 2 million RMB — the agreed project price.

Applied insurance amount: 100k RMB — the coverage limit requested.

Insurance premium: to be determined — the cost of purchasing the policy.

The insurance amount and premium are not interchangeable; claims depend on policy terms, loss assessment, deductibles, and other clauses. The policy also includes subrogation rights: after paying the insured, the insurer may recover from the policyholder.

Underwriting Process and Documentation

The process moves from inquiry to formal application, underwriting (risk assessment), possible supplementary materials, acceptance of terms, premium payment, policy issuance, and submission of proof to the school. Each stage produces distinct artifacts:

Inquiry → requirements record

Application submission → insurance application

Underwriting decision → underwriting conclusion with conditions

Payment → payment and receipt records

Issuance → actual policy document with number

Effective date → contract effective conditions, policy period, endorsements

A policy may have a future effective date; payment alone does not confirm all liability conditions. Mid‑term adjustments (e.g., period changes) require endorsements, not merely editing the original application. Claims follow a separate process with different evidence requirements.

History of Ontology in Computer Science

Ontology originated in philosophy (study of being). In computing it was adopted to enable knowledge sharing across systems.

1991 – Neches et al. proposed reusable knowledge components and shared reasoning services ( Enabling Technology for Knowledge Sharing ).

1993 – Tom Gruber defined ontology as "an explicit specification of a conceptualization" (Gruber 1993).

1998 – Studer, Benjamins, and Fensel emphasized "formal, explicit, shared" conceptualization.

1999 – RDF became a W3C recommendation for resource description.

2004 – OWL became a recommendation, adding richer ontology constructs.

2009 – OWL 2 further refined the language.

2017 – SHACL recommendation for validating RDF graphs (constraints on properties, value ranges).

Enterprise platforms (e.g., Palantir) extend ontologies with actions, permissions, and transactions, but these extensions are not part of the core definition.

An ontology is an explicit specification of a conceptualization.

What Is an Ontology?

Applying the four pillars to the insurance example:

Conceptualization – choose relevant entities: organization, project, construction contract, insurance application, insurance contract, policy. Exclude claims investigation for now.

Explicit – each term precisely defined: application records requested coverage; underwriting conclusion records insurer's judgment; policy is evidence of the contract, which also includes terms, application, endorsements.

Shared – definitions agreed upon by handlers, underwriters, and systems; scope is local, not global.

Formalized – expressed in a language with defined semantics (classes, properties, axioms) so machines can derive checkable conclusions. Example: defining "PerformanceGuaranteeInsuranceContract subclassOf GuaranteeInsuranceContract" lets a reasoner classify a specific contract accordingly.

Core ontology components:

Classes/Concepts – meaning of a type of thing (e.g., Organization, InsuranceApplication, InsuranceContract).

Data Properties – value characteristics (e.g., appliedInsuranceAmount, currency).

Object Properties – relationships between things (e.g., applicationBasedOnConstructionContract).

Axioms – logical assertions (e.g., PerformanceGuaranteeInsuranceContract ⊑ GuaranteeInsuranceContract).

Instance Facts – concrete data (e.g., this application submitted by ExampleConstructionCo).

Ontology holds domain definitions; instance data uses them. They can coexist but layers must be distinguished. An ontology is more than a glossary or database schema — it captures roles, relationships, and logical consequences. RDF/OWL are optional serialization tools; the design work (meaning, identity, relations, logic) remains human responsibility. OWL uses open‑world assumption: absence of a payment record does not logically prove non‑payment; business processes must enforce evidence checks separately.

Building an Ontology for the Insurance Business

Scope: from application to policy issuance, retaining links to the construction contract. Organizations (school, contractor, insurer) are created first. Roles (contractor/employer in construction contract; policyholder/insured/insurer in insurance) are context‑dependent, not permanent labels. Construction contract and insurance contract are separate entities with different parties, content, and lifecycles.

The model separates insurance application from insurance contract. An application exists first; when underwriting and contract formation conditions are met, the actual insurance contract is linked. The policy document is a separate evidence object linked to the contract, preventing confusion between "application created" and "insurance completed".

Key attributes per object:

ConstructionContract – identifier, contractAmount (2M RMB), currency — describes the project transaction.

InsuranceApplication – identifier, appliedInsuranceAmount (100k RMB), proposedPeriod — records the requested coverage.

UnderwritingConclusion – conclusion, applicableApplicationVersion, conditions, issuedTime — captures insurer's judgment tied to a specific application version.

InsuranceContract – identifier, agreedInsuranceAmount, insurancePeriod, effectiveConditions — describes the agreed insurance terms.

PolicyDocument – policyNumber, issueTime, evidenceVersion — records the issued document and its linked contract.

PaymentRecord – amount, paymentTime, receiptVerificationResult — distinguishes initiated payment from verified receipt.

Endorsement – identifier, changeContent, effectiveTime — records formal changes to an active policy.

All amounts use RMB yuan; applied amount, agreed amount, and endorsed amounts each have their own basis. Claim‑related limits require separate modeling. The model is a teaching example; real products may need multiple contracts, co‑insurance, etc.

Instances populate the conceptual model: School and Contractor as Organization instances; TeachingBuildingRenovation as Project; ApplicationA as InsuranceApplication instance. Queries can be federated: the model defines business meaning, while data mappings specify source services and unit conversions. Missing, stale, or conflicting sources still require handling.

Testing the Model with an Amount Change

After submitting ApplicationA (100k), the contractor revises the required amount to 120k. Overwriting the amount would lose traceability: which version did the underwriter review? Are prior conditions still valid? Must new documents be generated?

The model preserves both application versions (v1: 100k, v2: 120k) and links the existing underwriting conclusion explicitly to v1. The conclusion remains as historical evidence; applicability to v2 is a business‑rule decision, not an automatic inference.

If a policy is already issued, changes follow endorsement procedures — recording change content, effective time, and linked contract. An application amendment and a contract endorsement are distinct facts.

The model supports validation: e.g., applied amount must have currency; underwriting conclusion must reference a known application version; policy number must come from the issuing system. Such checks can be implemented via SHACL or application code; ontology reasoning alone does not replace all validation and workflow logic.

When a business status reads "completed", the model lets you trace exactly which object and evidence are referenced: application submitted? underwriting passed? payment verified? policy issued? For "is today within the liability period?" the model directs you to contract conditions, period, and valid endorsements. Each question has its own evidential basis; amounts, roles, and documents each have clear ownership.

Conclusion

Starting from a concrete insurance case, the article walks through the business mechanics, traces the intellectual lineage of ontology, defines its core constituents, and demonstrates a practical ontology design with version‑aware instance modeling. The result is a shared, explicit, formalized representation that enables precise querying and validation — turning a business process into an understandable, machine‑processable model.