Conformance Guide
How to verify and demonstrate FERIN compliance using the ISO 19135:2026 abstract test suite.
Understanding Conformance
FERIN conformance is capability-based, not hierarchical. You claim conformance to specific register types based on which capabilities you implement. This guide helps you verify those claims.
Conformance vs Capability
- Capabilities are features your register provides
- Conformance is a formal claim that you implement all required capabilities for a specific register type
- Testing verifies that claimed capabilities work correctly
Abstract Test Suite Structure
ISO 19135:2026 Annex A defines an abstract test suite organized by register type. Each test case maps to specific requirements in the standard.
Test Suite Organization
| Test Category | Register Types | Focus |
|---|---|---|
| Content Management | All types | Item lifecycle, status, versioning |
| Identifier Management | All types | Uniqueness, persistence, resolution |
| Concept Modeling | CR, GCR, CCR | Concepts, versions, relations |
| Governance | GCR, GCR, CCR | Roles, proposals, decisions, appeals |
| Commitments | CCR | Access, persistence, transparency |
Self-Assessment Checklists
Use these checklists to evaluate your implementation before formal conformance testing.
Content Register
Required for all register types
Item Management
- ☐ Can create new register items with unique identifiers
- ☐ Can retrieve items by identifier
- ☐ Can update item content
- ☐ Can invalidate items (mark as no longer valid)
- ☐ Can supersede items (replace with new version)
Status Management
- ☐ Tracks valid/invalid status
- ☐ Tracks published/unpublished status
- ☐ Status changes are recorded with timestamps
- ☐ Status history is preserved
Identifier Requirements
- ☐ Object identifiers are unique within the register
- ☐ Object identifiers are never reused
- ☐ Functional identifiers are unique (if used)
- ☐ Identifier scheme is documented
Concept Register
Additional requirements for concept modeling
Concept Management
- ☐ Can define concepts with definitions
- ☐ Can create concept versions
- ☐ Can link register items to concepts
- ☐ Concept lifecycle is independent of item lifecycle
Concept Relations
- ☐ Can define concept specializations (is-a)
- ☐ Can define concept compositions (has-part)
- ☐ Can define custom relations
- ☐ Relations are versioned appropriately
Advanced Concepts
- ☐ Supports concept domains (value sets)
- ☐ Supports codeset incorporation
- ☐ Domain constraints are enforced
Governed Register
Additional requirements for formal governance
Role Management
- ☐ Register Owner is designated
- ☐ Register Manager is designated
- ☐ Control Body is established (or alternative)
- ☐ Role assignments are documented
Proposal Process
- ☐ Proposals can be submitted
- ☐ Proposals include required information
- ☐ Proposal status is tracked
- ☐ Decision rationale is recorded
Audit and Appeals
- ☐ All changes create audit records
- ☐ Audit records include who, what, when
- ☐ Appeal process is defined
- ☐ Appeals are tracked to resolution
Complete Concept Register (CCR)
Full commitments implementation
Access Commitments
- ☐ Metadata is publicly accessible
- ☐ Content is accessible (as documented)
- ☐ Historical versions are accessible
- ☐ Access methods are documented
Persistence Commitments
- ☐ Identifier persistence is guaranteed
- ☐ Content persistence policy is documented
- ☐ Succession plan exists (if required)
- ☐ Long-term preservation is addressed
Transparency Commitments
- ☐ Governance is visible
- ☐ Decision processes are documented
- ☐ Change provenance is maintained
- ☐ Register specification is published
Test Case Mapping
Each capability maps to specific test cases. Here's how to structure your conformance evidence.
Evidence Types
Documentation
- Register specification
- Identifier scheme documentation
- Governance procedures
- Commitment statements
Demonstration
- Live API or UI walkthrough
- Sample transactions
- Workflow demonstrations
- Query results
Artifacts
- Sample register items
- Proposal records
- Audit logs (redacted if needed)
- Decision records
Test Case Example
Test: Item Invalidation
| Requirement | Register must support invalidation of valid items |
|---|---|
| Preconditions | A valid item exists in the register |
| Test Steps |
|
| Expected Result | Item status is invalid, history preserved, timestamp recorded |
| Evidence Required | Before/after item states, audit record |
Common Conformance Pitfalls
These issues frequently cause conformance failures:
Identifier Reuse
Problem: Reusing identifiers after deletion.
Fix: Identifiers must never be reassigned, even after invalidation or retirement.
Incomplete Audit Trails
Problem: Missing who/when/why for changes.
Fix: Every status change must include actor, timestamp, and reason.
Status Model Mismatch
Problem: Using non-standard status values.
Fix: Map internal statuses to FERIN valid/invalid, published/unpublished.
Missing Commitment Evidence
Problem: Claiming commitments without documentation.
Fix: Publish explicit commitment statements and policies.
Governance Bypass
Problem: Emergency changes skip governance.
Fix: Even expedited changes must follow documented procedures.
Versioning Inconsistency
Problem: Concept versions don't align with item versions.
Fix: Document how concept and content versioning relate.
Conformance Claim Format
When claiming conformance, use this format:
This register claims conformance to ISO 19135:2026:
Register Type(s): [Content Register] [Concept Register]
[Governed Content Register] [Governed Concept Register]
[Complete Concept Register]
Capabilities Implemented:
- [List specific capabilities beyond minimum]
Commitments Declared:
- Access: [None/Low/Medium/High]
- Persistence: [None/Low/Medium/High]
- Transparency: [None/Low/Medium/High]
Conformance Date: [YYYY-MM-DD]
Register Specification: [URL to specification]