Scopeknown boundary
Known scope.
DORA initial-notification profile, with required template-field bindings and optional contextual derivations.
Field identity / external schemas / missingness checks
The field name is not the authority. The source binding is.
ActProof field IDs are stable identifiers inside an ActProof profile. They are not claimed to be universal names for the whole market.
A bank, GRC vendor, auditor or agent may use different names for the same regulatory concept. ActProof remains useful because external names can be mapped against source atoms, template locators, required status, data type, evidence expectations and derivation notes.
Field IDscanonical within ActProof
Universal claimfalse
Mapping basissource atoms, not names alone
Live 1.8.1completeness + source-atom coverage
01 / Why names differ
Different systems will call the same concept different things.
DORA templates, internal banking systems, incident-management platforms, audit workpapers and GRC products will not share one universal field vocabulary. That is normal. ActProof should not try to impose one.
ActProof provides a source-bound reference point. Other schemas map to it.
| Same concept may appear as | Example name | What ActProof provides instead |
|---|---|---|
| ActProof profile-local ID | classification_criteria_triggered | Stable profile-local identifier with source atoms and derivation metadata. |
| Bank internal system | major_incident_criteria | Candidate mapping by meaning, source basis and required status. |
| GRC vendor schema | impact_classification_factors | Alignment against template locator, data type and evidence burden. |
| Internal form label | DORA Initial Q7 | Mapping can still be valid if source atoms and semantics match. |
02 / Mapping method
Map by evidence-bearing meaning, not by string similarity.
String similarity is only a weak starting point. A reliable mapping needs to compare the source-bound properties of a field.
Map by
- source atom overlap and CELEX/ELI references
- template locator or glossary locator
- field meaning and reporting role
- required or optional status
- data type and cardinality
- evidence expectation and interpretive load
- disclosure tier and review status
Do not map by
- field name alone
- AI paraphrase alone
- vendor label alone
- position in a form alone
- assumption that an unmapped field is irrelevant
External schema field: major_incident_criteria Candidate ActProof field: classification_criteria_triggered Recommended mapping checks: source_atom_overlap required template_locator_overlap required where available data_type_match string_list expected interpretive_load high / review required evidence_expectation classification_committee_record
Current status
Manual mapping guidance is live. Automated schema comparison is a future utility.
Use the current field streams, source JSON and mapping guidance to align schemas manually. A formal compare-schema utility should follow in a later package release.
03 / Missingness
ActProof does not prove the profile is exhaustive.
A field missing from ActProof is not proof that the field is legally irrelevant. It may mean the field is outside the profile scope, optional, national-channel specific, institution-specific, not yet modelled, or genuinely missed.
The profile should therefore remain challengeable.
Challengemissing field
Missing-field challenge.
Users should be able to propose a missing field with source reference, template locator and reason.
Coveragesource atoms
Source-atom coverage.
ActProof Events 1.8.1 shows which recorded source atoms are represented by fields, unused, required-bound or contextual-only. Current result: 25/26 atoms used; 1 unused atom is exposed as a review signal.
04 / Live 1.8.1 and next utility
The trust layer is live; schema comparison remains next.
ActProof Events 1.8.1 now ships profile completeness, source-atom coverage, and field-ID non-universality guidance. The real-world bridge after that is candidate schema comparison for human review, not authoritative automated matching.
| Future capability | Why it matters | Likely release lane |
|---|---|---|
profile-completeness | States known scope, known non-scope, challenge types and field-ID policy. | Live in 1.8.1 |
source-atom-coverage | Shows which recorded source atoms are used by fields, unused, required-bound or contextual-only. | Live in 1.8.1 |
compare-schema | Candidate mapping of external field names to ActProof field IDs for human review. | Planned for 1.9.0 |
external_schema_mapping.v1 | Stores candidate mappings, matched-by signals and review state. | Planned for 1.9.0 |
challenge_record.v1 | Lets reviewers raise missing-field, wrong-source or weak-derivation challenges. | 1.9.0 |
Future example: actproof-events compare-schema \ op:eu.dora.ict_incident_notification_initial.v1 \ vendor-dora-schema.json Output: matched_fields: 18 missing_required_fields: 2 ambiguous_mappings: 3 unsupported_external_fields: 5 review_required: true
Why not claim it now?
Because the site now distinguishes what shipped in 1.8.1 from what remains planned.
Profile completeness and source-atom coverage are live. Automated schema comparison should be shipped only when it exists in the package and can be tested as candidate mapping for review.
05 / Boundary
ActProof is a reference point, not a field-name authority.
ActProof should never claim that its field IDs are universal. It should claim that they are stable, source-bound, profile-local identifiers that external systems can map to, challenge and review.
ActProof can support
- profile-local canonical field identifiers
- external schema alignment
- mapping by source atoms and template locators
- missing-field challenge workflows
- future schema comparison utilities
ActProof cannot claim
- universal market field names
- that every valid external field must use ActProof names
- that an unmapped field is irrelevant
- that the profile is exhaustive, final or regulator-approved
- that string similarity is enough to establish equivalence
Use ActProof field IDs as reference anchors, not as imposed names.
The source binding is what makes alignment possible across different internal schemas, vendor products, audit workpapers and agent calls.