Skip to content

Chapter 11: Vertical Packs at Enterprise Scale

New in v1.2.0. Healthcare, finance, legal, insurance, energy, and government vertical packs extend the core FCC framework with industry-specific personas, scenarios, gates, and compliance frameworks. This chapter explores how to run a vertical at scale — the data layout decisions, the compliance mapping, the archetypes that emerge, and the cross-vertical collaboration surface.

Learning Objectives

By the end of this chapter you will be able to:

  • Distinguish schema v1 (legacy riscear_role) from schema v2 (nested R.I.S.C.E.A.R.) and explain why the retrofit was necessary.
  • List FCC's six built-in vertical packs and describe the archetypal lens each one operates through.
  • Map any vertical persona to an EU AI Act risk category using the vertical_risk_profiles.yaml override layer.
  • Decide when to fork a built-in pack versus when to author a new one from scratch, based on sub-vertical specificity and compliance framework needs.
  • Trace cross-vertical collaboration through the cross-reference matrix and identify which core personas serve as plumbing for vertical packs.

From three to six packs

v1.0.0 shipped three "starter" packs (healthcare, finance, legal) with five thin personas each. Every persona shared a boilerplate archetype ("Vertical Specialist") and an identical style string ("Domain-specific"). The merge path fabricated the same defaults for all 15 personas, which meant the generated model cards were near-identical — a classifier could not distinguish a Clinical Trial Researcher from a Regulatory Affairs Liaison because both looked the same after merge.

v1.2.0 did two things to fix this:

  1. Schema v2 extension — every vertical persona YAML now supports a full nested riscear block with all ten R.I.S.C.E.A.R. components, plus risk_category, dimension_profile, and display_name_i18n as optional fields. The legacy riscear_role flat string still works.
  2. Retrofit of the existing 15 personas — healthcare, finance, and legal were rewritten on the new schema, with distinct archetypes (Regulatory Shepherd, Prudential Risk Quant, Financial Crime Investigator, Evidence Architect, etc.), citation-backed constraints, and full skills and responsibility lists.

With the retrofit done, v1.2.0 added three net-new packs (insurance, energy, government) and expanded healthcare and finance with 6 additional medical and financial personas respectively. The catalog grew from 15 → 45 vertical personas across 6 packs.

Pack-by-pack at a glance

Pack Personas Compliance frameworks Archetypal lens
healthcare 11 HIPAA, FHIR R5, ICD-11, IEC 62304, EU MDR, DICOM Clinical safety + privacy
finance 11 SOX, Basel III, MiFID II, IFRS 9, SR 11-7, SFDR Prudential + market risk
legal 5 GDPR, CCPA, eDiscovery Evidence + regulation
insurance 6 ACORD, IFRS 17, Solvency II, NAIC Actuarial + claims
energy 6 IEC 61970 CIM, NERC CIP, FERC Order 2222 Grid ops + transition
government 6 DCAT-US 3.0, NIEM 6.0, FedRAMP, NIST 800-53 Civic tech + privacy

Each of the three net-new packs (insurance, energy, government) ships with a research note at src/fcc/data/verticals/research/<domain>.research.md citing at least three authoritative standards sources with retrieval dates. These notes are not tests or fixtures — they are the audit trail explaining why each persona exists and which standard it anchors to.

Picking the right risk category

EU AI Act classification in v1.2.0 is driven by src/fcc/data/compliance/vertical_risk_profiles.yaml, which encodes (persona_id, domain) → risk_category as an explicit mapping anchored in Annex III clauses. The classifier consults this file before falling back to generic keyword heuristics.

A typical high-risk entry looks like this:

- persona_id: GMM
  domain: energy
  risk_category: high
  rationale: >-
    Grid model management directly governs critical energy infrastructure —
    failures have physical-safety and continuity implications.
  annex_reference: "III.2 (critical infrastructure management)"

There are 45 entries — one per vertical persona — and roughly half are HIGH-risk. The reason is regulatory: underwriting, grid management, fraud detection, NIEM-based cross-agency data sharing, medical device software, and HIPAA compliance are all called out in Annex III as high-risk use cases. The remaining 23 personas are LIMITED-risk because they produce reports or recommendations for human decision-makers rather than taking autonomous action.

When building your own packs, anchor every HIGH entry in a specific clause. If you can't find one, ask whether the persona really belongs in the HIGH bucket.

Archetypes that emerged from retrofit

A side effect of rewriting the 15 legacy personas was realizing how few actual "archetypes" exist in the vertical world. After retrofit, the archetypes clustered into five families:

  • Shepherds — personas who guide data or artifacts through a regulated pathway (HCO/HIPAA, ACA/ACORD, FRP/FedRAMP, NCP/NERC CIP).
  • Quants — modelers, actuaries, risk engineers (FRA, ACT, IRR, LCR, CCR).
  • Investigators — fraud/incident responders (CFD, AML, PSE).
  • Architects — infrastructure or schema designers (FIS, NIE, GMM, DIA).
  • Storytellers — personas producing synthetic outputs for stakeholders (CDA, TRX, PHM, ODS, CSR, ESG).

A sixth family — safety engineers — exists only in healthcare (MDS, CIE, PSE) because only healthcare has physical-device regulation with a software component. The pattern to watch for: when you add a persona whose archetype doesn't fit any existing family, that's a signal you're adding genuine domain novelty rather than reshading an existing persona.

Cross-vertical collaboration

The cross-reference matrix at src/fcc/data/personas/cross_reference.yaml started life with 150 entries covering the core → core handoffs from the 5-phase FCC cycle. In v1.2.0 the vertical cross-reference generator (scripts/generate_vertical_cross_references.py) walks every vertical persona's role_collaborators list and emits a handoff entry per collaborator. The matrix grew from 150 to 371 entries.

Most of those new edges are intra-vertical (an insurance underwriter hands off to an actuary, not a fraud investigator in a different pack). But the generator also picks up edges where a vertical persona collaborates with a core persona — for example, every vertical pack's data-heavy personas handoff to DE (Data Engineer) and BC (Blueprint Crafter) from the core catalog. That makes the cross-reference graph a hybrid structure: verticals sit on top of the core team and borrow its plumbing personas.

When to build your own pack

The built-in packs cover the dominant industries but there are reasons to fork:

  • Sub-vertical specificity — the built-in healthcare pack is generic; if you're doing genomics, oncology, or cardiology specifically, you'll want a pack with personas for your sub-domain.
  • Private compliance frameworks — if your org has an internal compliance program (e.g., a model risk management framework layered on SR 11-7), bake it into your own pack instead of bending an existing one.
  • Proprietary vocabulary — any organization with its own naming for roles, data sources, and artifacts benefits from a pack that speaks its language.

See Chapter 25 of the FCC Guidebook for a step-by-step authoring walkthrough.

Production considerations

Bundle vs plugin. The built-in packs ship as YAML files inside the wheel. Custom packs should ship as Python packages with a [fcc.plugins.verticals] entry point so adopters can pip install them independently of the core framework. This is the recommended pattern in v1.3.0 and beyond.

Versioning. Pack versions are independent of the FCC core version. v1.2.0 ships with healthcare and finance at v2.1.0 (expanded), legal at v2.0.0 (retrofitted), and the three new packs at v2.0.0. Bumping a pack version is how you signal breaking changes in persona IDs or compliance frameworks to downstream adopters.

Loading order. VerticalRegistry.merge_into(core_registry) returns a new registry; it does not mutate the argument. If you need deterministic ordering (e.g., for model-card generation where output filename order matters), iterate reg.all_packs() and merge in a fixed order.

Dimension profiles. The schema v2 dimension_profile field is optional and reserved for downstream packs that want to attach a persona dimension profile per vertical persona. Built-in v1.2.0 packs leave this field unset — it'll be populated in v1.3.0 along with the new external project scaffolds.

Early planning for v1.2.0 considered including SNOMED CT as a healthcare vocabulary source. It was dropped in favor of ICD-11 + LOINC + FHIR R5 + RxNorm because SNOMED CT has a per-country licensing model that would require every downstream adopter to verify they have a valid IHTSDO affiliate license. The open alternatives cover ~90% of concept space with a cleaner legal posture. If you need SNOMED CT, add it in your own pack via a post-install hook rather than pulling it into the core distribution.

Key Takeaways

  • v1.2.0 grew the vertical catalog from 15 personas across 3 packs to 45 personas across 6 packs, all running on schema v2 with full nested R.I.S.C.E.A.R. specs and distinct archetypes.
  • Half of the 45 vertical personas are HIGH-risk under the EU AI Act, anchored in specific Annex III clauses via vertical_risk_profiles.yaml.
  • Five archetype families emerged from the retrofit (Shepherds, Quants, Investigators, Architects, Storytellers) plus a sixth (Safety Engineers) unique to healthcare.
  • The cross-reference matrix grew from 154 to 371 entries — most new edges are intra-vertical, but vertical personas also hand off to core plumbing personas like DE, BC, GCA, and DGS.
  • Build your own pack when you need sub-vertical specificity, private compliance frameworks, or proprietary vocabulary; ship it as a [fcc.plugins.verticals] entry-point Python package, not a fork.

Cross-References

See also

  • Chapter 8 — Scaling to Enterprise (the precursor discussion of domain adaptation)
  • Chapter 10 — Ecosystem Case Studies
  • FCC Guidebook Chapter 25 — Industry Verticals (authoring walkthrough)
  • v1.2.0 release notes in CHANGELOG.md