RC Rick Collettesecurity · AI · music · people
Pattern

Framework/Profile Specialization

pattern-framework-profile-specialization · canon/patterns/framework-profile-specialization/unit.md

Framework/Profile Specialization

A framework defines the invariant governance spine; a profile specializes that spine for one domain. Profiles can define concrete actors, actions, evidence rules, approval tiers, audit requirements, and recovery paths, but they must preserve the framework's required domains and guarantees.

Problem

Governance frameworks fail when they are either too vague to govern or too specific to reuse. If the first implementation becomes the framework, every future domain has to choose between a bad fit and a governance rewrite.

Context

Use this pattern when a governance model, reference architecture, platform, or canon needs to apply across multiple domains while still supporting domain-specific action catalogs, evidence, policy, risk, approval, compliance, and recovery.

Forces

  • The framework needs invariant guarantees every domain inherits.
  • Each domain has real differences in actors, actions, evidence, and risk.
  • Copying the framework into each domain creates vocabulary drift.
  • Collapsing the first profile into the framework blocks future profiles.
  • Making the framework too vague lets profiles remove the governance that matters.
  • Conformance needs a stable spine to test.

Solution

Separate framework from profile. The framework owns the mandatory domains, lifecycle shape, terminology, records, and guarantees. A profile specializes those requirements for a domain by defining concrete actors, actions, evidence rules, risk tiers, approval modes, audit requirements, recovery options, and compliance constraints.

Profiles may specialize the framework; they may not erase it. If a profile removes identity, delegation, policy, evidence, approval, audit, observability, or recovery, it is no longer a profile of the framework. It is a fork.

Consequences

New domains inherit the hard governance decisions without pretending every domain is identical. The framework remains stable enough to cite and test; profiles remain concrete enough to build.

Failure Modes

  • The first profile becomes the framework by accident.
  • Profiles reuse framework words while omitting mandatory domains.
  • Each domain invents its own identity, evidence, approval, audit, and recovery vocabulary.
  • The framework specifies domain policy details that belong in profiles.
  • A profile changes inherited guarantees without recording the fork.

Proof Points

framework: identity, delegation, policy, evidence, approval, audit, observability, and recovery.

framework for controlled AI-assisted security operations.

  • EDDA — the general delegated-action governance
  • AISDR — the EDDA security profile, specializing the

Full source pattern: framework-profile-specialization.md.

Incoming References

Case Study 1
Reference Architecture 1