Enter the email address associated with your access grant.
No access? Request here →
A canonical foundation that makes carrier data trusted, machine-readable, governed, and discoverable so that every AI workflow built on top of it works safely and can be explained. This is the primer for what we are building, why each piece belongs where it does, and how clients overlay their own reality without rebuilding from scratch.
The single argument this entire architecture rests on. Every design decision below traces back to this.
Policy admin says "Named Insured." Submission intake says "Insured Name." Claims says "Claimant." Same concept, three systems, zero linkage. AI cannot reason across boundaries it cannot see.
Each use case — eligibility, FNOL triage, BA check — hand-codes its own entity lookups, confidence logic, and lineage tracking. There is no reuse. There is no governance. There is no carrier portability.
One insurance ontology. One document intelligence pipeline. One knowledge governance layer. Use cases call the platform. They do not rebuild it. New use cases take weeks, not months.
This is the most critical architectural principle. Conflating the two is the single most common failure mode in enterprise AI platform builds.
AI-ready data is trusted, machine-readable data with the context and governance required for AI to work safely and effectively. These four dimensions define the gap between data that exists and data AI can use. Every platform capability maps to one of these dimensions.
Data is siloed. Attribute definitions are inconsistent across product lines. No enterprise MDM sync.
A shared insurance ontology defining key entities and relationships. Knowledge graph physicalizes connections. Semantic interoperability across all domains.
Manual processes and unstructured data — emails, PDFs, endorsements — slow decision-making. AI cannot consume what it cannot parse.
Document Intelligence makes unstructured content searchable and extractable. Semantic layer provides machine-ready context for AI access and consumption.
Limited ability to trace how data was enriched or used in automated decisions. No audit trail connecting AI output to data source.
Every enrichment step, every AI recommendation carries full provenance. Lineage from source through transformation to analytical output. Audit-ready by design.
No unified catalog. Teams do not know what data exists across the enterprise, where it lives, or how to access it for AI workloads.
Catalog of catalogs provides enterprise-wide data discovery. Federated query across all source systems. Data becomes findable and consumable for AI workflows.
The two reference ontologies — Commercial Lines Submission and Claims — are the canonical foundation every client starts from. They are not built from scratch. They are overlaid. This distinction is what makes onboarding weeks, not months.
The complete intake-to-issuance entity model. Covers the full commercial lines lifecycle — submission, quote, binder, policy — plus every LOB exposure, location, hazard, coverage, rating, and regulatory entity a carrier needs.
Claims domain entities serialized as machine-readable ontology, anchored to an established industry upper ontology. ElevateNow's canonical base is carrier-neutral. Each carrier extends it in their own namespace without modifying the shared foundation.
Binding Authority is a use case within the commercial lines domain. Its rule types — geographic restrictions, hazard score gates, rating rules, coverage gates, class appetite — each correspond to entity groups that already exist in the commercial lines starter kit. The table below is not a separate layer. It is a concrete example of a use case drawing directly from what the ontology already provides.
| BA Rule Type (Use Case) | Draws From Starter Kit Entity | Commercial Lines Entity Group | How the Knowledge Graph Connects It |
|---|---|---|---|
| Geographic Restriction | State Requirement + Wildfire / Flood Hazard | Regulatory + Hazard | Governs geographic eligibility by state and hazard exposure level |
| Hazard Score Gate | Crime Hazard / Wildfire Hazard / Flood Hazard | Hazard Assessment | Applies score thresholds to hazard severity classifications |
| Rating Rule | Minimum Premium / Rating Factor | Rating + Premium | Governs minimum premium floors and rating factor requirements |
| Coverage Gate | Building Construction + Wind Hazard + Endorsement Form | Location + Hazard + Coverage | Controls multi-variable coverage eligibility requirements |
| Class Appetite | Industry Classification + Line of Business | SIC / NAICS + LOB | Classifies by industry code and governs which lines of business are eligible |
Each pillar has a distinct owner, a distinct concern, and a defined interface to the others. They do not bleed into each other.
The queryable knowledge graph. Domain-agnostic. It resolves entity context on request without knowing whether it is serving a BA check or a UW submission.
Two modes, one pipeline. Makes unstructured content consumable. Domain-agnostic by design.
Bulletins, appetite guides, authority matrices extracted into governed rules through the Knowledge Studio curation lifecycle and into active knowledge in the Semantic Layer
FNOL documents, loss runs, submission packages, ACORD forms extracted into structured data scoped to individual cases and kept separate from the governed rule base
Governance and authoring layer. Infrastructure product. Not a business user tool. Maintains the knowledge that use cases query.
Knowledge Studio is the bridge between the static starter kit and the live, queryable knowledge graph. It has a precise role at each step of the carrier journey.
Insurance ontology imported into Knowledge Studio. 291 entities loaded into the registry. Structural relationships derived. Source system field mappings registered.
Carrier system field names, enumerations, and carrier-specific extensions added via Knowledge Studio. Carrier layer stacks above the canonical foundation without modifying it.
Bulletins, appetite guides, authority matrices flow through the DocIntel pipeline. Extracted rules are anchored to canonical entities. Curation lifecycle: draft, steward review, sanction, active.
Knowledge Studio serializes the live entity graph and active rules as industry-standard JSON-LD. Validated and deployed to the carrier's analytics environment in approximately 5 minutes.
BA check, UW eligibility, FNOL triage all call the same platform resolution layer. It traverses the live entity graph and active rules. No use case rebuilds entity logic independently.
These are architectural commitments, not preferences. Holding these boundaries is what keeps the platform flexible as use cases grow and carriers change.
The intelligence platform answers the same question for any workflow that calls it: what do we know about this risk, in this geography, for these lines of business? It works identically whether the caller is a BA check, a UW submission, or a future use case we have not built yet. Domain logic belongs in the use case, not in the shared foundation.
NEVER: Platform logic tailored to a specific use case OK: Use case applies its own decision logic on top of platform contextWhen a BA check needs to know about hazard exposure, geographic restrictions, or class eligibility, it draws from the same governed knowledge base every other workflow uses. There is no separate copy maintained for BA, a separate copy for UW, a separate copy for Claims. One source. Every decision traceable to it.
NEVER: Duplicate knowledge into use-case-specific stores OK: All use cases query the same governed knowledge layerCarriers extend the starter kit by adding their system field names, enumerations, and carrier-specific rules on top. They do not edit the base. This is what makes the platform portable across carriers: when a rule changes at the foundation level, every carrier configuration that builds on it benefits automatically.
NEVER: Edit base ontology entities for a carrier-specific need OK: Carrier adds their configuration layer on top; foundation stays intact and sharedUnderwriters, claims directors, and BA stewards do their daily work in the business workbench. The knowledge engineering layer — where rules are authored, reviewed, and sanctioned — operates behind that interface. Business users never interact with the governance infrastructure directly. This separation is what keeps the audit trail clean and reliable.
NEVER: Expose the governance layer as a business user workflow toolBinding authority bulletins, appetite guides, and authority matrices define how decisions are made. They are institutional, durable, governed. Individual submissions, FNOL reports, and claim documents describe a specific case. They are transactional, ephemeral, case-scoped. Keeping them separate ensures governed rules remain clean and every decision remains auditable.
NEVER: Mix institutional rule content with case-specific document data OK: Each stream has its own pipeline, storage, and lifecycleAI is valuable when a new BA bulletin arrives: it accelerates extraction and proposes structured rule entries for steward review. But when a BA check runs at decision time, every gate is evaluated against rules that have been reviewed, approved, and sanctioned by a human steward. This distinction is what makes decisions explainable and defensible to regulators and auditors.
NEVER: Generate a runtime authority or eligibility verdict without a traceable, governed rule OK: AI assists authoring; humans sanction; governed lookup executes at decision timeEach component maps to a platform layer. The approach is additive and technology-agnostic at the carrier layer. We deliver standards-based artifacts that feed into whatever analytics and AI infrastructure the carrier operates.
| Component | Layer | What It Does | Integration Path |
|---|---|---|---|
| Operational Knowledge Store Knowledge graph database |
Semantic Layer | Houses the entity registry, relationship graph, governed rules, and reference data. The queryable foundation every use case draws from. Schema evolves incrementally as the ontology grows. | Current. No change required. Adaptable to carrier's preferred database infrastructure. |
| OWL Ontology Library Python-native, open source |
Semantic Layer | Serializes the entity registry as industry-standard JSON-LD for delivery to carrier analytics environments. Enables logical reasoning over the knowledge graph for derived decision gates without LLM dependency at runtime. | Added to platform dependencies. Powers standards-compliant export and ontology validation. |
| Ontology Authoring Tool Open source, desktop and web |
Knowledge Studio | GUI used by knowledge engineers during carrier onboarding to review and extend the entity model. Supports direct import from Excel entity registries, accelerating initial setup for carriers with existing data dictionaries. | Knowledge engineering workflow only. Not a runtime dependency. |
| OWL Standards Layer Industry-standard ontology interface |
Knowledge Studio | The JSON-LD we produce is compatible with industry-standard OWL tooling. Carriers that already have ontology infrastructure in their analytics environment can consume ElevateNow output without changes to their existing pipelines. | Compatibility layer. No carrier tooling changes required. |
| Knowledge Studio Backend Python · REST API |
Knowledge Studio | All curation lifecycle management, entity registry, document intelligence pipeline, and standards-compliant export. The production governance backend that powers the entire knowledge layer. | Current. Continuous improvement as platform matures. |
| Carrier Analytics Platform Snowflake, Databricks, or equivalent |
Carrier System | AI and analytics consumption layer receiving the JSON-LD knowledge manifests from ElevateNow. Carriers query semantic views rather than raw tables, accelerating AI and BI workload development on governed data. | ElevateNow delivers standards-based JSON-LD. Carrier's own CI/CD handles deployment. No ElevateNow code lives in the carrier's analytics environment. |
| Workflow Orchestration Use case workflow engine |
Use Case Layer | Orchestrates use case workflows — BA bulletin ingestion, submission intake, FNOL processing. Calls platform services as discrete, auditable workflow steps. Each use case defines its own workflow independently. | Current. New use cases add their own workflows. Platform layer does not change. |
Each domain requires specific structured and unstructured data to be AI-ready before automation is achievable. The platform — built once — serves all four domains simultaneously. A carrier that implements Binding Authority gets Underwriting, Claims, and Risk for the marginal cost of the domain extension.
Bulletin Ingestion, Rule Extraction, Authority Assignment, Submission Check, Audit Trail
Account Creation, Data Enrichment, Technical Rating, UW Review, Policy Issuance
FNOL Intake, Assignment, Evaluation, Litigation, Continuous Feedback
Exposure Aggregation, Clash & Accumulation, Compliance, Scenario Testing, Emerging Risk Signals
Three milestones. Each delivers tangible business capability. Organized by the four dimensions of AI-ready data.
Four deliverables that establish the governed foundation and activate the binding authority use case. Every item is additive. Nothing in your current environment is disrupted.
We ingest your binding authority bulletins, appetite guides, and authority matrices through the document intelligence pipeline. Every rule is extracted, linked to its source bulletin, reviewed by a human steward, and entered into the governed knowledge base. From day one, every BA decision is traceable to the specific document that authorized it.
✓ Every BA decision is explainable, auditable, and defensible
We deliver the full commercial lines ontology and overlay your carrier's specific rules, geographic parameters, class eligibility logic, and rating requirements on top. Your rules extend the foundation — they do not overwrite it. When the foundation improves, your configuration benefits automatically. No proprietary lock-in.
✓ Your BA rules are portable assets, not embedded code
When a BA bulletin changes a geographic restriction or a hazard threshold, the update enters the governed rule base once. The BA check, the UW eligibility pipeline, and every future workflow calling the platform inherit the update automatically. No manual synchronization across systems. No drift between teams.
✓ Rule changes propagate automatically — one update, consistent everywhere
The governed knowledge foundation we build with you is serialized in industry-standard formats and delivered to feed your existing analytics infrastructure — whether Snowflake, Databricks, or your carrier's current AI and BI platform. You retain the asset. No proprietary format. No ongoing dependency on ElevateNow for data access.
✓ Standards-based output consumable by any downstream AI or analytics stack