Commitments
What a register promises to provide: access, persistence, and transparency. These commitments define the trustworthiness of a register.
Commitments Scale with Risk
The commitments a register makes to its users are not fixed—they depend on the register's risk profile. A low-risk personal register may offer minimal commitments, while a high-risk authoritative registry must provide extensive guarantees.
Low Risk Registers
Minimal commitments: best effort availability, no formal guarantees, limited history
Medium Risk Registers
Moderate commitments: documented availability, peer review, notification periods
High Risk Registers
Extensive commitments: SLAs, formal validation, stakeholder review, binding timelines
When defining your commitments, consider who relies on your data and what happens if those commitments are not met. Document your commitments in your Register Specification as a contract with your users.
Commitment Categories
FERIN defines three categories of commitments:
Access
What users can retrieve from the register
Persistence
What is preserved over time
Transparency
What is visible to users
Access Commitments
| Commitment | Description | Levels |
|---|---|---|
| Metadata Access | Can users access item metadata (identifiers, dates, status)? | Low: Internal only Medium: Registered users High: Public |
| Content Access | Can users access the actual content of items? | Low: Summary only Medium: Full content with restrictions High: Full content publicly |
| Historic Access | Can users access previous versions and change history? | Low: Current only Medium: Limited history High: Full history |
Persistence Commitments
| Commitment | Description | Levels |
|---|---|---|
| Identifier Persistence | Will identifiers remain resolvable? | Low: Best effort Medium: Guaranteed for defined period High: Indefinite guarantee with succession plan |
| Content Persistence | Will content be preserved? | Low: Current version only Medium: Versions preserved High: Full audit trail |
| Historic Persistence | Will change history be preserved? | Low: Minimal metadata Medium: Change summaries High: Complete change records |
Transparency Commitments
| Commitment | Description | Levels |
|---|---|---|
| Metadata Transparency | Is governance metadata visible? | Low: Basic info Medium: Roles and dates High: Full provenance |
| Content Transparency | Is the content's source and derivation visible? | Low: Content only Medium: Source indicated High: Full derivation chain |
| Historic Transparency | Is the change process visible? | Low: Final results only Medium: Change summaries High: Full change records with rationale |
Choosing Commitment Levels
Decision Matrix
| Use Case | Access | Persistence | Transparency |
|---|---|---|---|
| Internal code list | Medium | Low | Low |
| Partner-shared reference data | Medium | Medium | Medium |
| Public API reference | High | Medium | Low |
| Regulatory compliance | Medium | High | High |
| National/international standard | High | High | High |
Append-Only Registers
High persistence commitment often implies an append-only model:
Append-Only Views
Time ──────────────────────────────────────────►
┌─────────┐
│ v1 │ Initial version
│ valid │
└────┬────┘
│
▼
┌─────────┐
┌──────────────│ v2 │◄──────┐
│ │ valid │ │
│ └─────────┘ │
│ │
│ supersedes supersedes
│ │
▼ │
┌─────────┐ ┌─────────┐
│ v1 │ │ v3 │ Current
│superseded │ valid │
└─────────┘ └─────────┘
All versions remain accessible; current view shows only valid items.
Implementation
- Never delete: Mark as invalid/superseded instead
- Immutable versions: Once created, versions don't change
- Views: Provide views that filter to current, valid content
- Audit: Every change creates an audit record
Compliance Verification
How to verify that commitments are being met:
Verification Checklist
- ☐ Access levels documented and enforced
- ☐ Persistence policies documented
- ☐ Retention periods defined and monitored
- ☐ Succession plan exists (for high persistence)
- ☐ Change history accessible per commitment level
- ☐ Regular audits of commitment compliance