FAQ
Frequently asked questions about FERIN and its implementation.
How do I decide if a change is substantive?
Ask: "Would existing references to this content become confusing or misleading after this change?" If yes, it's substantive and needs a new version. If the change is just clarification or correction that doesn't change the meaning, it's non-substantive.
See the decision framework →Can one person hold all roles in a small organization?
It depends on your register's risk level. For low-risk informative registers, combining roles is acceptable with proper documentation. For high-risk authoritative registers, role separation (especially between Manager and Control Body) is important for governance integrity.
See Risk Management for guidance →What happens when requirements change and existing content is non-conformant?
Don't make existing content invalid overnight. Options include: grandfathering existing content with clear marking, providing a migration period, or creating new requirements that apply only to new content.
See the Evolution Support principle →How do I migrate from a spreadsheet or database?
Plan carefully: map fields to FERIN attributes, clean data before migration, decide whether to preserve existing identifiers or assign new ones, and determine whether bulk import should bypass normal governance.
See the Upgrade Guide →What's the minimum viable register?
A Content Register with: unique identifiers, basic content storage, valid/invalid status, and a simple register specification. Add governance and concepts as your needs grow.
See Register Types →How do I handle emergency changes?
Define an expedited process: get emergency approval from an authorized role, apply the change, then submit for retroactive review. Document the emergency nature in change metadata. Don't skip documentation even for emergencies.
See the Actions Reference →Can I rollback a change?
FERIN doesn't define explicit rollback. Recommended approach: create a new version that restores previous content using the supersede action. This preserves history and shows what happened.
See Actions Reference →How do I reference concepts in other registers?
Use the external concept's object identifier. Document the dependency in your register. Consider subscribing to notifications from the external register to track changes.
See Identifier Design →What identifier scheme should I use?
It depends on your use case. UUIDs are simple and universal. URLs are convenient if you have web infrastructure. DOIs are best for academic/published content. URNs for long-term standards-based references.
See identifier scheme comparison →Do I need the concept plane?
Only if: definitions evolve over time, you need to track meaning separately from data, or you're building a terminology/taxonomy register. For simple code lists, the content plane alone may suffice.
See Core Concepts →How do I test conformance?
Map your implementation to the capabilities claimed. Verify each required action is supported, status model is correct, and commitments are met. Document evidence for each capability.
See Register Types and conformance →What's the difference between invalidation and deletion?
Invalidation marks content as no longer valid but preserves it for history. Deletion removes content entirely. Use invalidation in almost all cases; deletion breaks references.
See Statuses Reference →How detailed should my register specification be?
Match to register type: Content registers need basic scope and identifiers. Governed registers need full governance documentation. CCR needs comprehensive commitments. Don't under-document governance or commitments.
See Register Specification template →Still Have Questions?
If your question isn't answered here:
- Browse the Glossary for term definitions
- Check Anti-patterns for common mistakes
- Visit enosema.org for community resources