Why Do I Need a Register?
Understanding when a FERIN register is the right solution - and when simpler alternatives suffice. A register is not just storage; it is governed, versioned, persistent reference data with commitments.
What Makes a Register Different
A FERIN register provides a unique combination of capabilities that no other data management pattern offers together. Understanding these differences helps you choose the right tool for your needs.
Persistence
"This identifier will always resolve"
Evolution
"Content can change, history retained"
Governance
"Changes happen through defined process"
Commitments
"We state our promises explicitly"
Trust
"I can rely on this for my work"
Comparison with Alternatives
| Pattern | Persistence | Versioning | Governance | History | Status | Commitments |
|---|---|---|---|---|---|---|
| File (CSV, JSON, XML) | No | No | No | No | No | No |
| Database | Yes | Custom | No | Custom | No | No |
| Dataset | No | No | No | No | No | No |
| Git Repository | Yes | Yes | Limited | Yes | No | No |
| Data Catalog | Yes | No | Limited | No | No | No |
| API | No | No | No | No | No | No |
| FERIN Register | Yes | Yes | Yes | Yes | Yes | Yes |
Detailed Comparisons
File (CSV, JSON, XML)
Static data storage with no built-in governance or versioning.
- Missing: No versioning, no governance, no change history, no identifier stability
- Use when: Data is truly static, single consumer, no audit requirements
- Don't use when: Others depend on the data, changes occur, history matters
Database (SQL, NoSQL)
Mutable storage with optional versioning through custom implementation.
- Missing: No governance framework, no defined roles, no status model, no commitments
- Use when: Application data storage, transactional systems, simple CRUD
- Don't use when: Publishing reference data for external consumers, regulatory compliance
Git Repository
Version control designed for code, not reference data.
- Missing: No status model, no governance roles, no persistence commitments, poor support for large binary data
- Use when: Small code-like reference files, developer-focused data, internal use
- Don't use when: Non-technical stakeholders, API access needed, status tracking required
API (REST, GraphQL)
Delivery mechanism, not a managed data store.
- Missing: No storage, no versioning, no governance, no history, no commitments
- Use when: Exposing existing data, application integration
- Don't use when: You need the data store, not just the delivery layer
Decision Framework
Use this framework to determine whether a FERIN register is appropriate for your use case.
You Need a Register If...
- Others (people or systems) depend on your reference data
- You need to say "X meant Y at time T" for any past point
- Identifiers must remain stable even as meanings evolve
- Regulatory compliance requires audit trails
- You are publishing normative content (standards, regulations)
- Data schemas need to evolve independently of data
- You need to track lineage across splits and merges
- Cross-organizational data sharing with governance requirements
- You need to make explicit promises about access and persistence
You May Not Need a Register If...
- Data is truly static and will never change
- Only you consume the data
- No historical queries are ever needed
- Simple audit timestamps in a database suffice
- Governance overhead outweighs benefits
- Data volume is small and changes are rare
The Trust Test
Ask yourself: "Would a consumer trust this data enough to build their system on it?"
- If trust requires persistence guarantees → You need a register
- If trust requires knowing what changed and when → You need a register
- If trust requires knowing who approved changes → You need a register
- If trust is based on "I maintain this, trust me" → A simpler solution may suffice
Common Use Cases
Standards and Code Lists
Country codes, currency codes, unit of measure, industry classifications
Typically High RiskRegulatory Registries
Compliance codes, regulatory frameworks, legal references
High RiskOrganizational Taxonomies
Department structures, product categories, skill classifications
Medium RiskIdentifier Systems
DOI, ORCID, ISBN, custom identifier registries
High RiskScientific Reference Data
Measurement units, chemical compounds, species classifications
Medium-High RiskInternal Reference Lists
Project codes, internal vocabularies, team configurations
Low-Medium Risk