Framework Overview
FERIN is built on three pillars: Data, Governance, and Compliance. Understanding how these work together is key to effective implementation.
The Three Pillars
Data
How information is structured, stored, and accessed. Includes the concept plane, content plane, identifiers, and status model.
- Concepts and concept versions
- Register items and their attributes
- Relations between items
- Status tracking
Governance
Who can do what, and through what processes. Includes roles, responsibilities, and the actions that manage content.
- Role definitions and assignment
- Approval workflows
- Change management processes
- Dispute resolution
Compliance
What commitments are made and how conformance is verified. Includes register specification and conformance claims.
- Access commitments
- Persistence commitments
- Transparency commitments
- Conformance verification
Administrative vs Managed Information
FERIN distinguishes between two categories of information:
Administrative Information
Metadata about the register itself—its configuration, governance structure, and operational parameters.
Examples:
- Register title and description
- Owner and manager identities
- Register specification
- Conformance claims
- Operational status
Managed Information
The actual content of the register—concepts, register items, and their attributes.
Examples:
- Concept definitions
- Register item data
- Relations between items
- Change history
- Status information
The Boundary Question
The standard provides an abstract distinction, but in practice, where's the line?
| Information Type | Category | Rationale |
|---|---|---|
| Register title | Administrative | Describes the register, not its content |
| Item schema definition | Administrative | Defines structure, not content |
| Individual item values | Managed | Actual register content |
| Item change history | Managed | History of managed content |
| Approval workflow config | Administrative | Governance configuration |
Register Specification
Every register must have a register specification—a document that defines:
Scope and Purpose
What the register contains and why it exists
Identifier Scheme
How items are identified uniquely
Content Requirements
What attributes items must/can have
Governance Model
Roles, responsibilities, and processes
Commitments
Access, persistence, and transparency levels
Conformance Claims
Which FERIN capabilities are implemented
How Detailed Should It Be?
The standard requires a register specification but doesn't specify depth. Here's practical guidance:
| Register Type | Recommended Depth |
|---|---|
| Simple content register | Basic—scope, identifiers, minimal governance |
| Governed register | Moderate—full governance model, commitments |
| CCR (full conformance) | Comprehensive—all sections detailed |
See Register Specification for a complete template and samples.
Architecture Diagram
The FERIN framework architecture shows how concepts, content, and governance interact:
┌─────────────────────────────────────────────────────────────────┐
│ REGISTER │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ CONCEPT PLANE │ │ CONTENT PLANE │ │
│ │ │ │ │ │
│ │ ┌────────────┐ │ │ ┌────────────┐ │ │
│ │ │ Concept │◄─┼─────────┼──│ Register │ │ │
│ │ │ │ │ realizes│ │ Item │ │ │
│ │ └─────┬──────┘ │ │ └────────────┘ │ │
│ │ │ │ │ │ │
│ │ ┌─────▼──────┐ │ │ ┌────────────┐ │ │
│ │ │ Concept │ │ │ │ Status │ │ │
│ │ │ Version │ │ │ │ (valid, │ │ │
│ │ │ │ │ │ │published...)│ │ │
│ │ └────────────┘ │ │ └────────────┘ │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
├─────────────────────────────────────────────────────────────────┤
│ GOVERNANCE │
│ │
│ Owner ──► Manager ──► Control Body ──► Proposers ──► Users │
│ │
│ [Propose] ──► [Review] ──► [Approve/Reject] ──► [Publish] │
│ │
├─────────────────────────────────────────────────────────────────┤
│ COMMITMENTS │
│ │
│ Access ◄──► Persistence ◄──► Transparency │
│ │
└─────────────────────────────────────────────────────────────────┘