Principles
FERIN is guided by six core principles that ensure registers remain useful, trustworthy, and maintainable over time.
These principles are not just abstract ideals—they have concrete implications for how you design and operate your register.
Persistent Identification
What the Standard Says
Identifiers shall be unique, persistent, and consistently assigned.
The Interpretation
"Persistent" means more than "doesn't change"—it means the identifier remains resolvable and meaningful indefinitely. This requires:
- Organizational commitment: The identifier scheme must survive organizational changes
- Technical infrastructure: Resolution mechanisms must remain operational
- Semantic stability: What the identifier refers to must remain comprehensible
Practical Guidance
- Choose identifier schemes with proven persistence (e.g., DOI, URN)
- Document the identifier policy in your register specification
- Never reuse identifiers, even after content is deleted
- Ensure identifiers are independent of any single technology vendor
See Identifier Design for detailed guidance.
Evolution Support
What the Standard Says
Content and requirements can change over time, and the register must support this evolution.
The Interpretation
Evolution is inevitable—but how do you handle it when existing content becomes non-conformant with new requirements?
Practical Guidance
| Scenario | Approach |
|---|---|
| New optional fields added | Existing content remains valid; new fields are optional |
| New validation rules added | Apply to new content; grandfather existing content with clear marking |
| Breaking changes to structure | Version the specification; allow migration path |
| Deprecated fields removed | Provide notice period; create migration tooling |
Change History Retention
What the Standard Says
History of changes and associated metadata shall be retained.
The Interpretation
"Retained" raises several practical questions:
- How long? The standard doesn't specify retention periods
- What metadata? Minimum is date, actor, action; but more is better
- What about unmanaged content? Where's the boundary?
Practical Guidance
Minimum change metadata:
- Timestamp of change
- Actor (who made the change)
- Action type (add, modify, invalidate, etc.)
- Justification or rationale
- Before and after values
Unmanaged content boundary: Content becomes "managed" when it is:
- Subject to governance approval
- Exposed to external users
- Referenced by other systems
Integrity Protection
What the Standard Says
Content integrity shall be governed through defined processes.
The Interpretation
Integrity protection means:
- Changes only happen through approved processes
- Appropriate role separation exists
- Audit trails are maintained
- Unauthorized modifications are prevented
Role Separation Guidance
The appropriate level of role separation depends on your register's risk level—not the size of your organization.
| Risk Level | Role Separation |
|---|---|
| Low Risk | Single person may hold multiple roles; document clearly |
| Medium Risk | Separate proposers and approvers; defined change process |
| High Risk | Full separation; independent Control Body; formal appeal process |
See Risk Management for detailed guidance on assessing your register's risk level.
Compliance with Commitments
What the Standard Says
Registers shall meet their stated commitments for access, persistence, and transparency.
The Interpretation
Commitments are promises you make to users. The standard defines three categories:
- Access commitments: What can users access?
- Persistence commitments: What is preserved?
- Transparency commitments: What is visible?
Choosing Commitment Levels
| Use Case | Recommended Level |
|---|---|
| Public reference data | High access, high persistence, high transparency |
| Internal code lists | Moderate access, high persistence, moderate transparency |
| Sensitive reference data | Limited access, high persistence, limited transparency |
See Commitments for detailed specifications.
Technological Neutrality
What the Standard Says
The framework shall not be tied to specific technologies or implementation approaches.
The Interpretation
This means FERIN can be implemented using:
- Any database technology (relational, document, graph)
- Any API style (REST, GraphQL, gRPC)
- Any hosting model (cloud, on-premise, hybrid)
Database Mapping Guidance
| FERIN Concept | Relational DB | Document DB | Graph DB |
|---|---|---|---|
| Concept | Table with versions FK | Document with embedded versions | Node with version edges |
| Register Item | Table with status columns | Document with status fields | Node with status properties |
| Relations | Junction tables | Reference arrays | Native edges |
| History | Audit tables or temporal tables | Embedded history arrays | Version nodes with edges |
Principles in Practice
These principles often trade off against each other. For example:
- Evolution vs. Persistence: How do you evolve content while keeping identifiers persistent?
- Transparency vs. Efficiency: How much history is enough vs. too much overhead?
- Integrity vs. Flexibility: How strict should governance be without blocking necessary changes?
The key is to document your decisions in your register specification and apply them consistently.