Industry packs
An industry pack is a declarative bundle that stands a vertical up in one deployment. Instead of hand-building a star schema, modelling an ontology, wiring agent skills, writing authorization rules and assembling dashboards for each customer, a pack ships that starter content as data and a deployment engine registers it into the governed catalog. Everything a pack deploys inherits the cell's identity, classification and audit model by construction, the pack does not carry its own parallel security plane.
What a pack bundles
A pack is a single declarative object (carrying a schema version, so a newer cell can deploy an older pack) assembling seven layers, with compliance woven through every one of them rather than bolted on at the end.
- A dimensional model, the layer most often overlooked and usually the reason a vertical takes months. Facts, dimensions, bridges, metrics, business processes, calendar overlays and transform specifications, with a glossary and per-table regulatory mappings carried in the same specification. Detailed below.
- An ontology, the object types and link types that model the vertical's world as a graph rather than as a schema.
- Agent skills, the vertical's domain actions, registered into the skill catalog so an agent can reach for a known method instead of improvising one.
- Agent and workflow templates, agents pre-wired with their skills, data access policy and escalation protocol, plus orchestration templates with human approval gates and the reactive signals that fire them.
- Authorization and compliance policies, the access rules and compliance profiles that govern the pack's content, fitted to the platform's deny-closed governance.
- Reference data and dashboards, the vertical's standard code sets and its starter views.
- Connector requirements, a declaration of the external sources the pack expects. Registering a requirement is not the same as opening an ingest path.
The dimensional model
The dimensional layer is a complete star-schema specification, not a suggested ERD. A pack declares:
| Element | What it carries |
|---|---|
| Dimensions | Across six dimension kinds: conformed, role-playing, degenerate, junk, outrigger and mini |
| Facts | With a declared grain, validated rather than assumed, and per-fact aggregation rules |
| Bridges | For the many-to-many relationships a star schema otherwise fudges |
| Metrics | Reusable measure definitions, including compliance-tagged measures |
| Business processes | The vertical's processes the facts are organized around |
| Calendar overlays | Fiscal, regulatory and industry calendars over the shared date dimension |
| Transform specifications | How source data lands in the model |
| Glossary terms | Term and definition pairs, registered into the business glossary |
| Compliance mappings | Explicit table-to-regulation pairs, with a gap analysis you can read back |
Eight conformed dimensions are shared across every industry, so two packs deployed side by side agree on what a date, a customer or a location is rather than each inventing its own: date, time, geography, organization, product, customer 360, channel and currency. A conformed dimension that differs from the registered definition is rejected, which is what makes cross-industry analysis possible at all.
Around the specification sit the engines that make it operable: slowly changing dimensions in types 1, 2 and 3 (overwrite in place, add history rows, or keep previous-value columns) with heuristic detection from column naming; a grain manager that validates a fact is at the grain it claims; a hierarchy engine for drill paths including ragged and parent-child hierarchies; an aggregate navigator that routes a query to the most appropriate aggregate level; and materialization and incremental refresh.
A pack is also wrapped as a data product with a descriptor carrying its version, domain, input ports (the source connector types), output ports (the dimensional model's tables) and a discovery port, so a vertical is versionable, certifiable and discoverable like any other data product.
Reference data
An industry pack specification carries a model status, and the default is draft. Describe what a pack contains, not proven time-to-value: nothing here is graded or deployed, so "immediate time-to-value" and "zero assembly" are not claims to make. The component list carries the weight on its own.
Packs ship the code sets a vertical cannot function without. Cross-industry bundles cover classification, location, currency and calendar standards for everyone, generated rather than hand-maintained. Per-industry bundles carry the sets specific to a vertical, with finance, healthcare, insurance and legal bundles shipping today.
Compliance coverage, and its gaps
A pack's compliance mappings are not just metadata to be admired. You can ask a pack what it actually covers, and the answer names the gaps rather than reporting a percentage.
The analysis registers the pack's declared table-to-regulation pairs, then runs them against the tables the pack genuinely ships, its dimensions and facts. Per regulation it reports:
- Met controls, where a mapped control names a table the pack provides.
- Gaps, where a mapped control names a table the pack does not ship.
That second category is the useful one and the reason the analysis is worth running. A mapping that points at a table nobody deployed looks like coverage in a spreadsheet and is an empty control in an audit. Here it surfaces as a gap attached to the regulation it fails.
The read is a pure inspection of the pack specification: no database is touched and nothing is written, so it is safe to run while evaluating a pack rather than only after deploying one.
How a pack deploys
The deployment engine takes the bundle and registers each part into the catalog in turn. It is idempotent, re-deploying the same pack does not duplicate its content, and it deploys with best-effort rollback, so a partial failure can be undone rather than leaving half a vertical behind. Deployed objects are origin-tagged to the pack that produced them, so a pack can later be identified and withdrawn.
Figure: a pack (cyan, the declarative bundle) is registered by the deployment engine into the governed catalog. The dimensional model, ontology, agent skills, policies, workflows and dashboards all land as reachable catalog content (green). Connector requirements (amber, dashed) are registered as declarations, which is not the same as an open ingest path.
Table equivalent
| Bundle part | Deploys to | Reachable? | Note |
|---|---|---|---|
| Dimensional model | The catalog's dimensional layer | Yes | Facts, dimensions, bridges, metrics, calendars, glossary, compliance mappings |
| Ontology (object + link types) | Ontology managers, origin-tagged | Yes | Idempotent; withdrawable by origin tag |
| Agent skills | The skill catalog | Yes | The vertical's domain actions |
| Agent templates | The agent fabric | Yes | Pre-wired with skills, data-access policy and escalation |
| Reference data | The catalog | Yes | Cross-industry plus per-industry code sets |
| Authorization + compliance policies | The governance plane | Yes | Fitted to deny-closed governance |
| Workflow templates + reactive signals | The workflow store | Yes | Templates compiled to a graph, with human approval gates |
| Dashboards | The catalog's dashboard set | Yes | Starter views |
| Declared connector requirements | Registered as requirements | Registered, not ingesting | A connector may report healthy with no ingest path |
The pack catalog
Two deployable families and one read-only tier. They must not be conflated.
| Family | Members | Status | Where |
|---|---|---|---|
| Public Sector solution packs | Law Enforcement, Corrections, Intelligence Community, Fusion, Campus, Emergency Management (6) | Deployable: engine wired, activatable via the Public Sector marketplace tab | Public Sector packs |
| Commercial industry solutions | Healthcare, insurance, finance, manufacturing, retail, energy, logistics, telecom, agriculture, government, education, media, real estate, oil & gas, cyber insurance, legal (16) | Deployable: solution deployer wired, dispatched by name | This page |
| Read-only starter kits | A vertical's suggested ontology and extraction/fusion defaults for an observer | Suggestion tier: enforces nothing, deploys nothing | This page (the fusion-stream variant ships healthcare only) |
The two deployable families share the same shape, a declarative bundle the engine registers into the catalog. The read-only starter kits are a different, lighter thing: they suggest a vertical's ontology to an observer as a starting point and enforce nothing. Presenting a read-only starter kit as a deployed, enforcing vertical would overstate what it is.
Across the deployment matrix
A pack is data plus a local deployment step, so it deploys on a single cell with no coordinator to reach, holding in the sovereign, air-gapped corner by construction. Because a deployed pack becomes ordinary governed catalog content, it replicates and scopes the same way any other catalog content does across a multi-cell estate. What does not travel with a pack is a working data feed: the pack declares its connectors, but the ingest path is a separate concern the pack cannot assert on its own.
Related topics
- Public Sector packs, the six-pack Public Sector family and its compliance framing.
- Industrial & sensor support, the sensor modalities a vertical can ingest, and what is reachable among them.
- Catalog & lineage the catalog a pack's content lands in.
- Governance (deny-closed), the plane a pack's authorization and compliance policies fit into.