Actions Reference
Operations for managing content in a register: adding, changing, invalidating, superseding, and more.
Actions as Risk Controls
Every action in FERIN serves a risk management purpose. Actions are not just operations—they are controlled responses to information risks:
| Action | Risk It Addresses |
|---|---|
| Add | Risk of missing information needed by users |
| Invalidate | Risk of incorrect or erroneous information being used |
| Supersede | Risk of using outdated information when newer exists |
| Retire | Risk of using obsolete information |
| Unpublish | Risk of exposing information that should not be public |
| Deprecate | Risk of continued use of content that will be removed |
The availability and use of these actions should be documented in your Register Specification as part of your risk management approach.
Required Actions
All FERIN-compliant registers must support these core actions:
Add Concept
Create a new concept in the register
When to Use
When introducing a new abstract idea or category that doesn't exist in the register.
Required Information
- Concept identifier
- Initial definition
- Proposer and justification
Effect
- Creates concept with status "valid"
- Creates initial concept version
- Records change object
Add Concept Version
Create a new version of an existing concept
When to Use
When a concept's definition needs to change significantly.
Required Information
- Reference to existing concept
- New definition
- Justification for version
Effect
- Creates new concept version
- Previous version remains accessible
- May mark previous as superseded
Invalidate
Mark content as no longer valid for use
When to Use
When content is erroneous, withdrawn, or should no longer be used.
Required Information
- Reference to item to invalidate
- Reason for invalidation
- Effective date
Effect
- Sets valid status to false
- Content remains accessible for history
- Users should stop using this content
Unpublish
Remove content from public visibility
When to Use
When content should no longer be visible to users but remains in the register.
Required Information
- Reference to item to unpublish
- Reason for unpublishing
Effect
- Sets published status to false
- Content hidden from normal queries
- Still accessible with explicit reference
Supersede
Replace content with a newer version
When to Use
When new content replaces old content, and references should migrate.
Required Information
- Reference to superseded item
- Reference to superseding item
- Justification for supersession
Effect
- Creates supersession relation
- Old item marked as superseded
- Users can follow chain to current
Changes
Modify content attributes
When to Use
When updating content without creating a new version (non-substantive changes).
Required Information
- Reference to item to modify
- Attributes to change
- New values
Effect
- Updates specified attributes
- Records change in history
- Identifier unchanged
Optional Actions
Additional actions that registers may support:
Redaction
Hide or remove sensitive content while preserving structure.
Implementation note: Soft delete (hide) vs hard delete (remove) vs access control.
Deletion
Permanently remove content from the register.
Caution: Breaks references; use sparingly.
Migration
Move content between registers or register structures.
Use case: Consolidation, splitting, or schema migration.
Domains
Define or modify domain constraints on content.
Use case: Constrained value sets, enumerated types.
Composition
Manage relationships between composite and component items.
Use case: Assemblies, bundles, hierarchical content.
Inheritance
Define inheritance relationships between items.
Use case: Type hierarchies, property inheritance.
Action Decision Matrix
Which action should you use?
| Situation | Action | Notes |
|---|---|---|
| Adding entirely new concept | Add Concept | Creates concept and initial version |
| Refining definition significantly | Add Concept Version | Preserves history |
| Fixing typo in description | Changes | Non-substantive, no new version needed |
| Content has errors | Invalidate | Mark as unusable |
| Replacing with better version | Supersede | Links old to new |
| Content no longer appropriate | Unpublish | Hide from view |
| Content contains sensitive data | Redaction | Remove specific data |
Emergency Changes
Sometimes changes need to happen fast (security vulnerabilities, critical errors).
Expedited Process
- Identify urgency: Document why normal process can't be followed
- Emergency approval: Get expedited approval from authorized role
- Apply change: Execute the action
- Retroactive review: Submit for normal review after the fact
- Document: Record the emergency nature in change metadata
Rollback Considerations
FERIN doesn't explicitly define rollback. Here's practical guidance:
Approaches
| Approach | How It Works | Pros/Cons |
|---|---|---|
| Supersede chain | Supersede with previous version | Preserves history; may confuse users |
| Invalidate + re-add | Invalidate wrong content, add correct | Clear; loses direct link to original |
| True rollback | Revert to previous state | Simple; may hide that error occurred |
Recommendation
For most cases, use supersede to create a new version that restores previous content. This preserves history and shows what happened.