How the platform gets functionally rich
The ontology auto-discovers itself. Expertise Packs teach it what your business actually does.
An Expertise Pack is reusable domain knowledge — vocabulary, metrics, data mappings, questions, monitors, and action playbooks — that plugs into your Governed Ontology Layer. Combine packs across functions and the platform starts answering questions no single system could.
The naming system
Expertise Pack
The reusable package — a domain's vocabulary, metrics, mappings, questions, monitors, and playbooks.
Intelligence
What the customer sees — a named offering built from one or more packs. “Revenue Intelligence.”
Playbook
One specific workflow inside a pack — the steps, inputs, and approvals for a single action.
Executive View
A leader's perspective across the same underlying packs — the CRO and CFO ask different questions of the same renewal.
| Customer offering | Underlying expertise |
|---|---|
| Revenue Intelligence | Revenue Expertise Pack, extended with Customer Service and Contracts where relevant. |
| Service Intelligence | Field Service and Customer Support Expertise Packs. |
| Procurement Intelligence | Supplier, Spend, and Contract Expertise Packs. |
“Expertise Pack” is the term because a pack can be activated, configured, validated, and extended. That’s the product. The blueprint underneath it is an internal design term.
What a pack contains
Eight parts, working together.
Every Expertise Pack has the same anatomy, whether it’s built for revenue, field service, or claims. That consistency is what lets packs combine without producing conflicting answers.
01
Vocabulary and relationships
Definitions of the things that matter and how they connect — a customer, an asset, a warranty, a service case.
02
Metrics and rules
Explicit meanings for at risk, overdue, qualified, available, and profitable — configured to how your company actually defines them.
03
Data mappings
Starter mappings to your systems, documents, and external providers — including identity matching and which source wins when two disagree.
04
Question library
The useful questions for this function, with the evidence, calculations, filters, and explanation pattern each one needs to answer well.
05
Live monitors
Triggers, refresh cadence, baselines, thresholds, responsible owners, and escalation paths — so a change surfaces to the right person, not a dashboard no one opens.
06
Action playbooks
The supported next steps — required inputs, who can execute, where approval sits, and how the result gets verified.
07
Expert knowledge
Procedures, domain taxonomies, operating practices, and licensed reference material, where the function needs it.
08
Validation suite
Reference questions and scenarios that test answers, calculations, mappings, and actions against expected results — before a pack goes live, and every time it changes.
Meaning and time matter
The ontology has to describe relationships and time, not just nouns.
These distinctions decide whether an answer is reliable enough to act on. Shared definitions also keep different packs from producing inconsistent views of the same business.
“Is an account the legal customer, the billing entity, or the parent company?”
Get this wrong and a renewal shows up under the wrong owner, or a risk brief misses half the relationship.
“Is revenue booked, recognized, invoiced, or collected?”
Four different numbers, four different moments. A forecast built on the wrong one is confidently wrong.
“Which contract version applied when the event occurred?”
Terms change. An obligation has to be checked against the version that was live at the time, not the current one.
“Does resolved mean the ticket was closed, or the customer confirmed the fix?”
One is a queue metric. The other is a retention signal. Conflating them hides the churn risk you're trying to catch.
How packs connect
One supplier contract. Four functions. One shared identity.
A supplier contract touches Procurement, Legal, Finance, and Security. The same supplier identity should link the spend, the obligations, the invoices, the risk reviews, and the business services that depend on that supplier.
Each function then asks its own question against that shared record — Procurement sees the renewal window, Legal sees the obligation dates, Finance sees the spend variance, Security sees the exposure. One ontology. Four executive views.
See it applied to a real cross-functional problem.
The Solutions page walks through a renewal at risk — spanning Revenue, Service, and Contracts — end to end.