Two failure modes bracket every enterprise rollout of a shared tool. One flat configuration for the whole company — and the Excess Casualty division fights the Property division over the same settings, with copy-paste everywhere and no clean way to differ. Or a free-for-all — every project its own island, the same broker glossary maintained nine times, nine ways, drifting apart. Neither survives a multi-division specialty carrier. What’s needed is a layered model: a shared foundation that local teams can extend and override, with control over who changes what.

InsightXtract is built around exactly that. Configuration, reference data, and access are scoped across three levels, and the platform resolves them by specificity.

Three scopes, most-specific-wins

OrganizationDefine once, everywhere. Company-wide glossaries, lookups, document classes, and defaults — the shared foundation.
Business UnitDivisional override. A line of business tunes or replaces what it needs — its own coverage terms, its own class variants.
ProjectLocal specifics. A particular book or client program adds or overrides at the finest grain.

When the engine needs a glossary, a class, or a setting, it resolves Project → Business Unit → Organization, taking the most specific definition that exists. So the US-state lookup is defined once at the org and inherited everywhere; the Excess Casualty BU overrides the coverage-type glossary just for itself; a single client program pins one field’s behavior — all without copying anything.

flowchart TB P[Project] -->|not found?| BU[Business Unit] BU -->|not found?| O[Organization] O -->|not found?| D[platform defaults] P -. most specific wins .-> USE[(resolved config)]

Role-based access: who can do what

Layering config is half of governance; the other half is controlling who changes it and who sees results. Roles separate the people who build agents from those who run and review them, and from the systems that call the API.

RoleCan
Platform AdminManage org-wide config, reference data, users, and scopes.
Business-Unit AdminOwn their division’s classes, glossaries, and projects.
Underwriter / ClaimsRun extractions and consume results in their scope.
ReviewerReview and correct flagged extractions — no config rights.
Service / APIA scoped machine identity for programmatic calls.

Reference datasets and configuration changes are gated to the roles that own them, so a reviewer can fix a field without being able to rewrite a glossary, and a division admin can’t alter another division’s setup.

InsightXtract users and roles — role-based access scoped across organization, business unit, and project
Users and roles — access scoped so the right people change the right things.

Versioning: change with a paper trail

Governance also means change management. Glossaries and document classes are versioned: you clone the current version, edit the draft, and publish when it’s ready — the previous version stays linked as the parent. So a change to how a class extracts, or to a glossary’s terms, is deliberate, reviewable, and reversible — not a silent edit that quietly changes yesterday’s results.

Define once, override locally, change with control

That’s the whole governance thesis in a line. The org sets the standard, business units and projects adapt it where they must, roles decide who can touch it, and versioning records every change. It’s what lets a carrier onboard division after division onto one platform without either a config monolith or nine drifting copies.

Why governance-first matters

  • Consistency without rigidity. A shared foundation keeps divisions aligned; local overrides let them differ where the business genuinely differs.
  • No copy-paste sprawl. Reference data defined once and inherited means one place to maintain it — not nine copies drifting apart.
  • Separation of duties. Building, running, and reviewing are distinct roles — the basis of a defensible, auditable operation.
  • Controlled change. Draft-and-publish versioning makes every change to extraction behavior intentional and reversible.