Pergamum Pulse Semantic Mapping and Crosswalk Specification
Version 0.1 — Normative Mapping and Crosswalk Contract
This specification defines the canonical semantic mapping and crosswalk model for Pergamum Pulse.
A Mapping Object expresses a governed relationship between two identified knowledge objects, concepts, values, requirements, Controls, evidence classes, schemas, code-list members, units, device properties, methodologies or projections.
A Crosswalk is a governed set of Mapping Objects created for a declared purpose, scope and version context.
The governing principles are:
A mapping SHALL express a governed semantic relationship, not merely textual similarity.
A Crosswalk SHALL preserve the identity, authority, version, applicability and evidence of every source and target object.
Equivalent wording SHALL NOT be interpreted as equivalent meaning without analysis of scope, authority, conditions, exceptions, lifecycle and evidence.
Mapping direction matters. A source that maps to a target does not imply the same relationship in reverse.
Every mapping SHALL preserve the rationale and evidence supporting the relationship.
A Mapping Object SHALL NOT increase the authority of either source or target.
An approved mapping SHALL NOT automatically become active Registry, schema, computation, validation, workflow or Runtime state.
Unmapped, incompatible, ambiguous and conflicting concepts SHALL remain explicit.
Automated similarity and AI recommendations SHALL remain candidates until governed review and approval.
1. Scope
This specification applies to every first-class Mapping Object identified by PP-MAP- and every governed Crosswalk created from Mapping Objects.
It applies to mappings between:
- Pergamum Pulse knowledge objects;
- external concepts and ZAYAZ governed objects;
- external frameworks;
- legal requirements and ZAYAZ Requirements;
- Requirements and Controls;
- Controls and Evidence Requirements;
- certification criteria and tests;
- dataset fields and schema properties;
- code-list values and Registry values;
- taxonomies and classifications;
- units and value domains;
- device models and Origin profiles;
- protocols and canonical signal types;
- methodologies and computation models;
- assertions and relationships;
- tenant-specific and global canonical concepts.
This specification does not itself approve a Core change, create legal or certification equivalence, grant rights, create Runtime authority, activate projections or establish framework interchangeability.
2. Normative Language
The terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY and MAY NOT are normative.
Where this specification conflicts with PP-KDMF, the framework prevails.
A domain Profile MAY tighten this specification but SHALL NOT weaken identity, evidence, authority separation, rights, applicability, confidence disclosure, versioning, temporal validity, tenant isolation, provenance or activation boundaries.
3. Mapping Architecture
Source Knowledge Object
↓
Source Assertions and Evidence
↓
Mapping Candidate
↓
Mapping Analysis
↓
Mapping Review and Decision
↓
Approved Mapping Object
↓
Crosswalk Set
↓
Impact Analysis
↓
Change Candidate
↓
Projection
↓
Separate Activation
A Mapping Object SHALL remain distinct from a Knowledge Assertion, semantic relationship candidate, Crosswalk Set, Mapping Rule, Change Candidate, Change Decision, Projection Manifest and active Runtime state.
4. Canonical Mapping Objects
| Object | Prefix | Purpose |
|---|---|---|
| Mapping Object | PP-MAP- | Represents one governed source-to-target mapping |
| Crosswalk Set | PP-CWS- | Groups Mapping Objects for a declared purpose |
| Mapping Rule | PP-MR- | Defines deterministic or reviewable mapping logic |
| Mapping Evidence | PP-ME- | Preserves evidence supporting a mapping |
| Mapping Review | PP-MRV- | Records expert review |
| Mapping Conflict | PP-MCF- | Records competing or contradictory mappings |
| Mapping Decision | PP-MD- | Records approval, rejection or conditional treatment |
| Mapping Receipt | PP-MRC- | Machine-verifiable validation result |
| Mapping Migration | PP-MMG- | Records migration between Crosswalk versions |
5. Canonical Mapping Object
mapping_object:
mapping_id: PP-MAP-000001
semantic_id: pp.mapping.iso42001.control-objective.ai-risk-management
mapping_version: 1.0.0
mapping_type: implements
source:
object_id: PP-KE-000101
object_version: 1.0.0
object_role: source_requirement
target:
object_id: PP-KE-000202
object_version: 2.0.0
object_role: zayaz_control_objective
direction:
class: directed
cardinality:
class: many_to_one
rationale:
summary: "The target Control Objective operationalises the source requirement."
evidence:
mapping_evidence_ids:
- PP-ME-000001
authority: {}
rights: {}
applicability: {}
confidence: {}
coverage: {}
temporal: {}
review: {}
status: {}
provenance: {}
Every machine-actionable Mapping Object SHALL include identity, version, type, source, target, direction, cardinality, rationale, evidence, authority, rights, applicability, confidence, coverage, temporal validity, review, status and provenance.
6. Mapping Identity and Versioning
Every Mapping Object SHALL possess an immutable PP-MAP- identifier.
Reusable mappings SHOULD possess a semantic identifier.
A Mapping Identifier SHALL NOT be reused for a materially different relationship.
Two Mapping Objects SHALL NOT be treated as identical solely because they use the same source and target. Identity also considers mapping type, direction, conditions, applicability, authority, version, evidence, validity and purpose.
Every Mapping Object SHALL have an independent version line.
version_line:
mapping_id: PP-MAP-000001
mapping_version: 2.0.0
predecessor: PP-MAP-000001@1.0.0
successor: null
Approved Mapping Object versions SHALL be immutable.
7. Source and Target Contract
A source or target reference SHALL identify:
- object identifier;
- object version;
- object type;
- semantic identifier where available;
- authority;
- validity;
- scope;
- mapping role.
Sources and targets MAY include Knowledge Entities, Knowledge Assertions, Requirements, Controls, Evidence Requirements, Registry values, schema properties, dataset fields, code-list members, units, formulas, methods, device properties, certification criteria and tests.
A Mapping Object SHALL pin source and target versions unless the Mapping Rule explicitly permits version ranges.
An unresolved source or target SHALL use an explicit provisional identity and SHALL block final approval.
8. Direction and Cardinality
Direction classes include:
- directed;
- inverse-directed;
- bidirectional;
- symmetric;
- derived inverse;
- non-reversible.
A bidirectional mapping SHALL require evidence that meaning, scope and constraints are preserved in both directions.
A derived inverse MAY be generated only where an inverse type exists, class constraints permit it, no scope is lost, authority does not escalate and provenance is preserved.
Cardinality classes include:
- one-to-one;
- one-to-many;
- many-to-one;
- many-to-many;
- one-to-zero-or-one;
- conditional;
- unconstrained;
- unresolved.
A source concept MAY map to a composite target only where all required members are identified.
Where only part of a composite target is covered, the mapping SHALL be classified as partial.
9. Mapping Type Registry
Every mapping type SHALL be Registry-governed.
The Registry SHALL preserve:
- Mapping Type Identifier;
- canonical name;
- definition;
- allowed source classes;
- allowed target classes;
- direction rules;
- inverse type;
- symmetry;
- transitivity;
- cardinality constraints;
- evidence requirements;
- authority constraints;
- review requirements;
- lossiness;
- reversibility;
- lifecycle;
- provenance.
Core mapping types MAY include:
- exact equivalent;
- semantic equivalent;
- broader than;
- narrower than;
- partial overlap;
- conditional equivalent;
- implements;
- operationalises;
- satisfies;
- evidences;
- supports;
- derived from;
- transforms to;
- aggregates to;
- decomposes to;
- classifies as;
- aliases;
- version successor;
- compatible with;
- incompatible with;
- conflicts with;
- no mapping;
- unresolved.
10. Equivalence Classes
10.1. Exact Equivalent
exact_equivalent SHALL require:
- materially identical meaning;
- materially identical scope;
- compatible authority;
- compatible normative force;
- compatible conditions;
- compatible exceptions;
- compatible lifecycle;
- compatible value domain;
- no material information loss.
10.2. Semantic Equivalent
semantic_equivalent MAY tolerate representational differences but SHALL preserve intended meaning for the declared purpose.
10.3. Conditional Equivalent
conditional_equivalent SHALL identify all conditions under which equivalence holds.
10.4. Broader and Narrower
broader_than and narrower_than SHALL identify direction and the additional or excluded semantic scope.
10.5. Partial Overlap
partial_overlap SHALL identify:
- overlapping portion;
- non-overlapping source portion;
- non-overlapping target portion;
- substitution risk.
10.6. Incompatible
incompatible_with SHALL identify the incompatibility basis.
10.7. No Mapping
no_mapping SHALL be represented where a reviewed source concept has no valid target.
10.8. Unresolved
unresolved SHALL be used where available evidence is insufficient.
11. Equivalence Analysis
Equivalence analysis SHALL evaluate:
- definition;
- subject;
- predicate;
- object;
- normative force;
- authority;
- scope;
- applicability;
- conditions;
- exceptions;
- thresholds;
- units;
- formulas;
- evidence expectations;
- lifecycle;
- version;
- temporal validity;
- intended use.
Equivalence SHALL NOT be based solely on textual similarity, shared labels, acronyms, marketing claims, badges, framework participation, common industry usage, embedding distance or model confidence.
12. Mapping Rationale and Evidence
Every Mapping Object SHALL preserve a rationale identifying:
- semantic basis;
- structural basis;
- applicability basis;
- authority comparison;
- normative-force comparison;
- evidence comparison;
- conditions;
- exceptions;
- limitations;
- rejected alternatives;
- reviewer judgement.
Every material mapping SHALL possess Mapping Evidence.
mapping_evidence:
evidence_id: PP-ME-000001
source_assertions:
- PP-KA-000101
target_assertions:
- PP-KA-000202
source_fragments:
- PP-SF-000031
target_fragments:
- PP-SF-000044
analysis_method: expert_semantic_comparison
provenance: {}
Evidence sufficiency SHALL be assessed separately from mapping confidence.
Each supporting source SHALL preserve independent rights, authority, version and provenance.
Withdrawal or invalidation of evidence SHALL trigger mapping impact analysis.
13. Mapping Authority
Every mapping SHALL preserve authority dimensions separately.
authority:
source_authority:
class: standards_body
target_authority:
class: zayaz_governed_object
mapping_authority:
class: expert_reviewed
zayaz_governance_authority:
class: governed_reference
runtime_authority:
class: none
A mapping SHALL NOT:
- raise the legal authority of the target;
- transfer certification status;
- convert guidance into a legal obligation;
- convert a manufacturer claim into field evidence;
- create Core authority;
- create Runtime authority.
The Mapping Authority SHALL identify who or what is authorised to approve the relationship.
14. Rights
Every Mapping Object SHALL reference the Rights Records governing:
- source knowledge;
- target knowledge;
- Mapping Evidence;
- reproduced definitions;
- quotations;
- generated Crosswalk output;
- public publication;
- machine processing.
A mapping MAY be publishable even where source text cannot be reproduced, provided the rights basis permits the mapping representation and required attribution is preserved.
A public Crosswalk SHALL NOT expose restricted source text, definitions, tables or diagrams without permission.
Rights revocation SHALL trigger impact analysis over Mapping Objects, Crosswalk Sets, indexes, projections and Publications.
15. Applicability
Every Mapping Object SHALL define applicability.
applicability:
state: conditionally_applicable
jurisdictions:
- eu
sectors:
- manufacturing
organisation_roles:
- ai-provider
frameworks:
- PP-KE-framework-001
modules:
- pergamum-pulse
components:
- semantic-mapping-registry
tenant_scope:
mode: global
white_label_scope:
mode: global
valid_from: 2026-01-01
valid_to: null
Applicability dimensions MAY include jurisdiction, sector, organisation type, legal role, framework version, product, device model, firmware, methodology version, dataset version, Module, Component, Extension, tenant, white-label operator, Runtime profile and time.
A mapping valid for one purpose SHALL NOT be reused for another purpose without review.
16. Conditions, Exceptions and Qualifiers
Every condition, exception or qualifier affecting mapping validity SHALL be explicit.
conditions:
- type: firmware_minimum
value: "3.0"
exceptions:
- type: jurisdiction
value: jurisdiction.example
qualifiers:
- type: reporting_boundary
value: operational_control
Conditions SHALL be machine-readable where feasible.
A condition or exception SHALL remain part of mapping identity and equivalence analysis.
17. Confidence and Uncertainty
Confidence SHALL be multidimensional.
confidence:
source: high
target: high
semantic: medium
applicability: high
rights: verified
review: high
overall: medium
Dimensions SHOULD include source confidence, target confidence, semantic confidence, applicability confidence, rights confidence, transformation confidence and review confidence.
Confidence SHALL NOT replace evidence, authority or review.
Uncertainty MAY include semantic, scope, applicability, value, temporal, authority, rights and transformation uncertainty.
An overall confidence value SHALL not conceal weaker dimensions.
18. Coverage and Completeness
Every mapping SHOULD identify coverage.
coverage:
source_coverage_percent: 80
target_coverage_percent: 65
covered_dimensions:
- objective
- required_action
uncovered_source_dimensions:
- reporting_frequency
uncovered_target_dimensions:
- implementation_detail
Coverage SHALL distinguish:
- source coverage;
- target coverage;
- semantic coverage;
- structural coverage;
- evidence coverage;
- condition coverage;
- exception coverage.
Coverage SHALL NOT be interpreted as equivalence.
A Crosswalk SHALL identify whether it is:
- complete for declared scope;
- substantially complete;
- partial;
- materially incomplete;
- unknown.
19. Lossiness and Reversibility
Every transformation mapping SHALL identify information loss.
Lossiness classes MAY include:
- lossless;
- lossless for declared purpose;
- minimally lossy;
- materially lossy;
- non-reversible;
- unknown.
A lossy mapping SHALL identify:
- information removed;
- information aggregated;
- precision reduced;
- semantics generalised;
- conditions discarded;
- reversibility limitations.
20. Temporal Validity
Mappings SHALL preserve valid time and transaction time.
temporal:
valid_from: 2026-01-01T00:00:00Z
valid_to: null
recorded_at: 2026-01-03T09:00:00Z
superseded_at: null
A mapping MAY remain historically valid after source or target supersession.
Current mappings SHALL NOT be applied retroactively without a governed historical interpretation rule.
21. Mapping Status Model
Status dimensions SHALL remain separate.
status:
proposal_status: reviewed
decision_status: approved
conflict_status: none
publication_status: internal_only
projection_status: not_projected
activation_status: not_applicable
Decision states MAY include proposed, under review, approved, approved with conditions, rejected, deferred, disputed, superseded, withdrawn and historical.
Projection and activation states SHALL not be collapsed into mapping approval.
22. Crosswalk Set
A Crosswalk Set groups Mapping Objects for a declared purpose.
crosswalk_set:
crosswalk_id: PP-CWS-000001
semantic_id: pp.crosswalk.iso42001.zayaz.aims-controls
crosswalk_version: 1.0.0
purpose: control_alignment
source_system:
id: PP-KE-framework-iso42001
version: "2023"
target_system:
id: zayaz.control-registry
version: 4.0.0
mappings:
- PP-MAP-000001
completeness:
state: substantially_complete
authority: {}
rights: {}
applicability: {}
review: {}
provenance: {}
Every Crosswalk Set SHALL identify:
- Crosswalk identity;
- version;
- purpose;
- source system;
- target system;
- included mappings;
- excluded scope;
- completeness;
- authority;
- rights;
- applicability;
- review;
- temporal validity;
- provenance.
A Crosswalk Set SHALL NOT merge the identity, authority, rights or lifecycle of its member mappings.
23. Crosswalk Purpose
Crosswalk purpose MAY include:
- semantic comparison;
- regulatory impact analysis;
- control alignment;
- evidence alignment;
- reporting alignment;
- framework harmonisation;
- taxonomy conversion;
- dataset ingestion;
- schema migration;
- device integration;
- methodology implementation;
- certification assessment;
- Publication comparison;
- historical reconstruction.
A mapping approved for one purpose SHALL NOT be presumed suitable for another.
24. Mapping Rule
A Mapping Rule defines deterministic, semi-deterministic or reviewable mapping logic.
mapping_rule:
rule_id: PP-MR-000001
rule_version: 1.0.0
rule_type: controlled_value_lookup
source_class: dataset_field
target_class: registry_value
conditions: []
transformation: {}
review_requirement: exception_only
provenance: {}
24.1. Rule Types
Rule types MAY include:
- exact identifier lookup;
- controlled synonym lookup;
- code-list lookup;
- taxonomy parent-child rule;
- unit conversion;
- value transformation;
- schema-field transformation;
- conditional mapping;
- expert decision table;
- graph pattern;
- inference rule;
- AI-assisted candidate generation.
24.2. Rule Determinism
A Rule SHALL identify whether it is:
- deterministic;
- deterministic with controlled exceptions;
- probabilistic;
- AI-assisted;
- human judgement.
24.3. Rule Versioning
A material Rule change SHALL trigger affected-mapping analysis.
24.4. Rule Non-Authority
Execution of a Rule SHALL NOT create authority beyond its approved scope.
25. Value Mapping
Value mappings SHALL preserve source and target value domains.
value_map:
source_value:
code: "A"
label: Active
target_value:
value_id: lifecycle.active
mapping_type: exact_equivalent
A value mapping SHALL identify:
- source value;
- target value;
- datatype;
- code-list version;
- conditions;
- unknown-value treatment;
- invalid-value treatment;
- provenance.
Unmapped values SHALL not silently default.
26. Unit Mapping and Conversion
Unit mappings SHALL use governed Unit Registry identifiers.
unit_conversion:
source_unit: unit.kilogram
target_unit: unit.tonne
formula: "source / 1000"
conversion_rule_version: 1.0.0
rounding: decimal_places_6
A conversion SHALL preserve:
- source value;
- source unit;
- target value;
- target unit;
- formula;
- constants;
- precision;
- rounding;
- uncertainty;
- provenance.
Dimensionally incompatible units SHALL not be mapped.
Unit conversion SHALL not imply semantic equivalence of the measured properties.
27. Taxonomy and Code-List Crosswalks
Taxonomy mappings MAY include:
- exact class equivalence;
- broader class;
- narrower class;
- parent-child;
- split class;
- merged class;
- deprecated class;
- no equivalent class.
A taxonomy Crosswalk SHALL preserve:
- taxonomy identity;
- taxonomy version;
- code identity;
- labels;
- definitions;
- hierarchy;
- status;
- validity;
- mapping rationale;
- provenance.
A code match SHALL NOT be inferred from labels alone.
28. Framework and Regulatory Crosswalks
Framework and regulatory Crosswalks SHALL compare:
- legal or normative requirement;
- obligated subject;
- required action;
- intended outcome;
- conditions;
- exceptions;
- scope;
- applicability;
- evidence;
- assessment;
- lifecycle;
- authority;
- version.
Example:
External Requirement
↓
ZAYAZ Requirement Candidate
↓
Control Objective
↓
Evidence Requirement
↓
Assessment Method
↓
Certification or Reporting Impact
28.1. Legal Non-Equivalence
A mapping to a ZAYAZ Control SHALL NOT be represented as legal compliance unless the approved mapping scope and evidence support that claim.
28.2. Framework Non-Substitution
A Crosswalk SHALL NOT imply that certification or conformance to one framework automatically satisfies another.
28.3. Normative Force
Differences between SHALL, SHOULD, MAY, guidance, recommendation and descriptive content SHALL be explicit.
29. Requirement-to-Control Mapping
A Requirement-to-Control mapping SHALL identify:
- source Requirement;
- Control Objective;
- control activities where relevant;
- responsible Roles;
- evidence expectations;
- frequency;
- applicability;
- residual gaps;
- authority;
- review.
One Control MAY support several Requirements.
One Requirement MAY require several Controls.
Cardinality and coverage SHALL remain explicit.
30. Control-to-Evidence Mapping
A Control-to-Evidence mapping SHALL identify:
- Control;
- Evidence Requirement;
- evidence class;
- evidence producer;
- evidence period;
- quality criteria;
- verification method;
- retention;
- applicability;
- limitations.
A mapping to an Evidence class SHALL NOT prove that a particular Evidence object is sufficient.
31. Certification and Assurance Mapping
Certification mappings SHALL distinguish:
- scheme;
- criterion;
- test;
- evidence;
- Certification Body;
- Accreditation Body;
- scope;
- validity;
- decision rule;
- mark use;
- authority.
A Mapping Object SHALL NOT create certification status.
A certification Crosswalk SHALL disclose uncovered criteria and incompatible assessment methods.
32. Dataset-to-Schema Mapping
A dataset-to-schema mapping SHALL identify:
- dataset;
- dataset version;
- source field;
- source datatype;
- source unit;
- target schema;
- target property;
- target datatype;
- target unit;
- null handling;
- validation;
- transformation;
- quality;
- rights;
- provenance.
dataset_schema_mapping:
source:
dataset_id: PP-KE-dataset-001
version: "2026-01"
field: emissions_value
target:
schema_id: zayaz.emissions.schema
version: 3.0.0
property: emissions.value
transformation:
type: unit_conversion
Missing, invalid and out-of-range values SHALL have explicit treatment.
33. Schema-to-Schema Mapping
Schema mappings SHALL preserve:
- property paths;
- datatypes;
- required status;
- cardinality;
- defaults;
- constraints;
- enums;
- units;
- null semantics;
- validation rules;
- lossiness;
- provenance.
A default value SHALL NOT be introduced without an explicit Mapping Rule and authority.
34. Device and Origin Crosswalks
Device and Origin mappings MAY connect:
- manufacturer;
- product family;
- model;
- variant;
- firmware;
- capability;
- protocol;
- signal type;
- unit;
- measurement property;
- connector;
- parser;
- Origin Registry property;
- Runtime profile candidate.
Example:
Manufacturer Property
↓
Knowledge Assertion
↓
Origin Property Mapping
↓
Connector Configuration Candidate
↓
Runtime Profile Candidate
A manufacturer specification mapping SHALL NOT prove installation, calibration, configuration, operation or observation quality for a tenant device instance.
Firmware-specific mappings SHALL preserve firmware applicability.
35. Methodology-to-Computation Mapping
Methodology mappings MAY connect:
- method;
- formula;
- variable;
- unit;
- factor;
- boundary;
- allocation rule;
- scenario;
- uncertainty;
- validation rule;
- Computation Hub model candidate.
A methodology mapping SHALL preserve:
- source formula;
- normalised formula;
- variable definitions;
- assumptions;
- unit dimensions;
- method version;
- applicability;
- evidence;
- review.
A Mapping Object SHALL NOT activate Computation Hub logic.
36. Publication and Reporting Crosswalks
Publication mappings MAY connect:
- disclosure requirement;
- report section;
- metric;
- narrative requirement;
- evidence;
- assurance state;
- public claim;
- verification reference.
A Publication Crosswalk SHALL preserve rights, authority, evidence and current source status.
It SHALL NOT permit public claims that exceed source support.
37. Automated and AI-Assisted Mapping
Automation MAY:
- detect candidate source and target objects;
- calculate lexical or embedding similarity;
- compare definitions;
- propose mapping types;
- identify scope differences;
- identify unit differences;
- identify code-list candidates;
- identify conflicts;
- estimate confidence;
- draft rationale;
- generate review queues.
Automation SHALL NOT independently:
- approve exact equivalence;
- establish legal equivalence;
- establish certification equivalence;
- create authority;
- waive rights;
- resolve expert disputes;
- activate projected changes;
- conceal unmapped concepts.
37.1. Automated Candidate Record
Every automated candidate SHALL identify:
- Candidate identity;
- algorithm or model;
- model version;
- prompt or rule version;
- input objects;
- retrieved evidence;
- similarity features;
- proposed type;
- proposed confidence;
- time;
- human review state;
- provenance.
37.2. Similarity Non-Authority
Similarity scores SHALL be treated as discovery signals, not proof.
37.3. Model Drift
A model or prompt change that materially changes mapping proposals SHALL trigger drift analysis.
38. Mapping Review
Every material mapping SHALL receive risk-appropriate review.
Review classes MAY include:
- semantic review;
- legal review;
- regulatory review;
- methodology review;
- technical review;
- data review;
- device review;
- certification review;
- rights review;
- tenant-isolation review;
- Runtime review.
A Mapping Review SHALL identify:
- reviewed Mapping Object;
- reviewer;
- competence;
- purpose;
- evidence;
- findings;
- decision recommendation;
- limitations;
- review time;
- expiration;
- provenance.
High-impact mappings SHOULD separate proposal, semantic review, legal or technical review, approval, projection and activation.
39. Mapping Decision
A Mapping Decision SHALL identify:
- Decision identity;
- Mapping Object;
- decision;
- authority;
- conditions;
- permitted purpose;
- prohibited purpose;
- effective time;
- expiration;
- review date;
- signatures where required;
- provenance.
Decision states MAY include:
- approved;
- approved with conditions;
- rejected;
- deferred;
- returned for revision;
- disputed;
- escalated;
- expired;
- revoked;
- superseded.
An approved mapping for internal analysis SHALL NOT imply approval for Publication or Runtime use.
40. Mapping Conflicts
Conflicting mappings SHALL be first-class governed objects.
mapping_conflict:
conflict_id: PP-MCF-000001
mapping_ids:
- PP-MAP-000101
- PP-MAP-000102
conflict_type: incompatible_equivalence
status: under_review
Conflict types MAY include:
- competing targets;
- competing source interpretations;
- incompatible equivalence;
- cardinality conflict;
- version conflict;
- jurisdictional divergence;
- scope conflict;
- authority conflict;
- rights conflict;
- transformation conflict;
- temporal conflict.
The system SHALL NOT silently select the mapping with the highest confidence score.
Resolution outcomes MAY include:
- one mapping confirmed;
- both valid for different scopes;
- both valid for different purposes;
- both valid for different times;
- both retained as accepted divergence;
- source error;
- target error;
- unresolved;
- escalated.
Blocking conflicts SHALL propagate to dependent Crosswalks, Change Candidates, projections and Publications.
41. No-Mapping and Gap Objects
A reviewed absence of mapping SHALL be represented explicitly.
A gap record SHOULD identify:
- source object;
- searched target system;
- review scope;
- search method;
- reason no mapping exists;
- impact;
- remediation;
- review date;
- provenance.
No-mapping states MAY include:
- no equivalent target;
- target not yet modelled;
- source out of scope;
- source deprecated;
- insufficient evidence;
- rights-restricted analysis;
- unresolved.
Unmapped objects SHALL not silently disappear from completeness metrics.
42. Supersession, Correction and Withdrawal
A mapping supersession SHALL identify predecessor, successor, reason, effective time, compatibility, affected Crosswalks, affected Change Candidates and provenance.
A correction SHALL preserve the erroneous version and corrected successor.
A withdrawal SHALL identify whether the mapping was:
- valid until withdrawal;
- invalid from inception;
- superseded;
- source-withdrawn;
- target-withdrawn;
- rights-restricted;
- historically retained;
- deletion-required.
Source or target withdrawal SHALL trigger impact analysis for dependent mappings.
43. Semantic Graph Integration
Approved mappings MAY participate in the Pergamum Pulse semantic graph.
Graph integration SHALL preserve:
- Mapping Identifier;
- mapping type;
- source;
- target;
- direction;
- cardinality;
- authority;
- rights;
- applicability;
- confidence;
- coverage;
- temporal validity;
- conflict state;
- review;
- provenance.
Mappings MAY be represented as:
- reified mapping nodes;
- typed edges with attached Mapping Identifiers;
- Crosswalk membership edges;
- transformation objects.
The representation SHALL preserve all governed metadata.
43.1. Traversal
Graph traversal SHALL enforce:
- mapping purpose;
- tenant scope;
- white-label scope;
- rights;
- authority;
- temporal validity;
- confidence threshold;
- conflict policy;
- depth;
- path provenance.
43.2. Transitivity
Mappings SHALL be non-transitive by default.
A composed mapping MAY be generated only where:
- all mapping types permit composition;
- intermediate semantics are preserved;
- conditions remain satisfiable;
- authority does not escalate;
- rights permit use;
- lossiness is disclosed;
- provenance is complete.
43.3. Path Explanation
Every material composed result SHOULD expose the full mapping path.
44. Crosswalk Composition
Two Crosswalk Sets MAY be composed for an approved purpose.
Composition SHALL identify:
- source Crosswalks;
- intermediate system;
- composition rules;
- excluded mappings;
- conflicts;
- accumulated lossiness;
- confidence treatment;
- rights;
- reviewer;
- provenance.
Crosswalk composition SHALL NOT silently convert partial mappings into exact equivalence.
45. Change Detection and Drift
Change detection SHALL monitor:
- source versions;
- target versions;
- predicate definitions;
- mapping types;
- Mapping Rules;
- Rights Records;
- applicability;
- authority;
- evidence;
- Crosswalk membership.
Drift classes MAY include:
- source drift;
- target drift;
- semantic drift;
- rule drift;
- confidence drift;
- applicability drift;
- authority drift;
- rights drift;
- coverage drift.
Material drift SHALL trigger review and dependent-object impact analysis.
46. Impact Analysis
Mapping impact analysis SHALL consider:
- Knowledge Assertions;
- Knowledge Entities;
- Crosswalk Sets;
- Requirements;
- Controls;
- Evidence Requirements;
- tests;
- schemas;
- Registry entries;
- Computation models;
- workflows;
- connectors;
- device profiles;
- Reports;
- Publications;
- certifications;
- tenants;
- white-label deployments;
- Runtime profiles.
Impact severity MAY include:
- informational;
- low;
- moderate;
- high;
- critical;
- constitutional.
47. Change Candidate Generation
An approved or conditionally approved mapping MAY generate a PP-CC- Change Candidate.
candidate_generation:
mapping_id: PP-MAP-000001
target:
object_type: control_registry
object_id: CTRL-000042
proposed_operation: update
Candidate generation SHOULD require:
- approved Mapping Decision;
- complete evidence;
- resolved rights;
- applicable scope;
- sufficient confidence;
- declared coverage;
- no blocking conflict;
- impact analysis.
Generation SHALL NOT approve the Candidate.
Every Candidate SHALL preserve complete mapping lineage.
48. Projection and Activation Boundary
The controlled path is:
Mapping Object
↓
Crosswalk Set
↓
Change Candidate
↓
Change Decision
↓
Projection Manifest
↓
HECATE Validation
↓
Separate Activation
An approved mapping alone SHALL NOT:
- modify a Registry;
- change a schema;
- activate a computation;
- change a validation rule;
- change a workflow;
- change certification criteria;
- publish a claim;
- change Runtime state.
49. Tenant and White-Label Isolation
Every mapping SHALL preserve knowledge scope.
Tenant-scoped mappings SHALL identify:
- tenant;
- source objects;
- target objects;
- rights;
- confidentiality;
- permitted Components;
- promotion eligibility;
- retention;
- deletion.
White-label mappings SHALL preserve operator scope.
Promotion to global canonical knowledge SHALL require rights approval, confidentiality review, semantic review, conflict review, applicability review, approval and provenance.
Isolation SHALL apply across Mapping Registries, Crosswalks, indexes, vector stores, graph traversal, prompts, exports, logs and projections.
50. Security and Confidentiality
Mappings MAY reveal confidential relationships, strategy, compliance gaps, product capabilities, supplier dependencies or tenant architecture.
Security classification SHALL control:
- access;
- retrieval;
- display;
- graph traversal;
- embedding;
- export;
- AI processing;
- Publication;
- retention;
- deletion.
The existence of a mapping MAY itself be sensitive.
Least privilege SHALL apply to reviewers, Agents and Components.
51. Mapping Quality
Mapping quality MAY be measured across:
- source identity completeness;
- target identity completeness;
- evidence sufficiency;
- semantic clarity;
- applicability completeness;
- authority completeness;
- rights completeness;
- confidence calibration;
- coverage;
- review quality;
- conflict state;
- freshness;
- provenance completeness.
Quality metrics SHALL NOT create authority or equivalence.
51.1. Staleness
A mapping MAY become stale where:
- source version changes;
- target version changes;
- Mapping Rule changes;
- predicate definition changes;
- rights change;
- applicability changes;
- new conflicting evidence appears;
- review expires;
- Crosswalk purpose changes.
51.2. Quality Finding
A Finding SHALL identify:
- Mapping Object or Crosswalk;
- criterion;
- expected state;
- observed state;
- severity;
- downstream impact;
- remediation;
- provenance.
52. Mapping Assurance and Audit
Assurance MAY evaluate:
- mapping identity;
- evidence sufficiency;
- equivalence classification;
- direction;
- cardinality;
- authority;
- rights;
- applicability;
- confidence;
- coverage;
- review;
- conflict handling;
- graph composition;
- projection lineage;
- historical reconstruction.
A Mapping Audit SHALL identify:
- audit identity;
- scope;
- criteria;
- auditor;
- independence;
- sample;
- evidence;
- Findings;
- conclusion;
- remediation;
- provenance.
Audit Findings MAY include:
- unsupported equivalence;
- missing evidence;
- incorrect direction;
- incorrect cardinality;
- excessive generalisation;
- undisclosed partial coverage;
- stale source version;
- stale target version;
- invalid composition;
- rights leakage;
- tenant leakage;
- incomplete provenance.
53. AI Agent Boundaries
AI Agents MAY:
- identify candidate mappings;
- compare definitions;
- propose mapping types;
- estimate coverage;
- identify conditions and exceptions;
- propose value maps;
- identify conflicts;
- identify unmapped concepts;
- draft rationales;
- support impact analysis;
- create review queues.
AI Agents SHALL NOT independently:
- approve exact equivalence;
- establish legal equivalence;
- establish certification equivalence;
- create authority;
- grant rights;
- suppress gaps;
- resolve expert disputes;
- approve Change Candidates;
- activate projections;
- publish restricted Crosswalks.
Every Agent-generated candidate SHALL preserve Agent identity, Agent Profile, model, model version, prompt profile, tools, retrieved evidence, time, candidate output, human review state and provenance.
54. HECATE Validation
HECATE SHALL validate objective structure including:
- Mapping Identifier;
- prefix;
- Mapping Object version;
- Mapping Type Registry reference;
- source object;
- source version;
- target object;
- target version;
- direction;
- cardinality;
- evidence references;
- rationale structure;
- authority dimensions;
- rights references;
- applicability;
- confidence;
- coverage;
- temporal validity;
- review;
- conflict state;
- Crosswalk membership;
- tenant scope;
- Module lineage;
- Component lineage;
- provenance.
HECATE MAY validate deterministic Mapping Rules and unit compatibility.
HECATE SHALL NOT:
- invent semantic equivalence;
- invent evidence;
- grant authority;
- grant rights;
- determine disputed legal meaning;
- establish certification equivalence;
- approve mappings solely from similarity;
- resolve expert conflicts autonomously;
- activate projected changes.
55. Module and Component Lineage
Every material mapping path SHALL identify:
- accountable Module;
- Semantic Mapping Registry Component;
- Knowledge Assertion Registry Component;
- Knowledge Entity Registry Component;
- source-ingestion Component;
- transformation Component;
- graph Component;
- Change Intelligence Component;
- Projection Component;
- affected Modules;
- affected Components;
- Runtime-consuming Components;
- Publication-consuming Components;
- tenant and white-label context.
No orphan Component lineage is permitted.
56. Provenance
Mapping provenance SHALL connect:
- Source Objects;
- Source Captures;
- Rights Records;
- Knowledge Documents;
- Source Fragments;
- Knowledge Assertions;
- Knowledge Entities;
- source and target versions;
- Mapping Evidence;
- Mapping Rule;
- automated candidate process;
- AI model and prompt profile;
- human reviewer;
- Mapping Decision;
- Mapping Conflict;
- Crosswalk Set;
- Change Candidate;
- Change Decision;
- Projection Manifest;
- Publication;
- Module lineage;
- Component lineage;
- tenant lineage;
- white-label lineage;
- valid time;
- transaction time.
provenance:
provenance_graph_id: PP-PROV-000001
source_assertions:
- PP-KA-000101
target_assertions:
- PP-KA-000202
mapping_evidence:
- PP-ME-000001
mapping_review:
- PP-MRV-000001
created_at: 2026-08-04T19:00:00Z
Materially incomplete provenance SHALL block automation eligibility, authoritative projection, unqualified Publication and definitive historical claims.
57. Historical Reconstruction
Historical reconstruction SHALL answer:
- which Mapping Object version existed;
- which source and target versions were used;
- which Mapping Type definition applied;
- which Mapping Rule version applied;
- which evidence supported the mapping;
- which rights applied;
- which applicability applied;
- which confidence and coverage were recorded;
- which reviewer approved it;
- whether conflict or gaps existed;
- which Crosswalk Sets included it;
- which Change Candidates were generated;
- which projections used it;
- which Publications relied on it;
- which Runtime state, if any, was separately activated.
57.1. Exact Replay
Exact Replay SHALL reconstruct the mapping using historical object, assertion, Mapping Type, Rule, rights and schema versions.
57.2. Semantic Replay
Semantic Replay MAY evaluate a historical source-target pair under a later approved mapping profile.
Exact Replay and Semantic Replay SHALL remain distinct.
57.3. Non-Retroactivity
Current source definitions, target definitions, Mapping Rules, authority, rights or entity resolutions SHALL NOT be silently applied to historical mappings.
58. Conformance Levels
58.1. Level 1 — Identifiable
The mapping has:
- stable identifier;
- version;
- source;
- target;
- mapping type;
- direction;
- basic provenance.
58.2. Level 2 — Evidence-Governed
It additionally has:
- Mapping Evidence;
- rationale;
- authority;
- rights;
- applicability;
- confidence;
- coverage;
- temporal validity;
- review.
58.3. Level 3 — Crosswalk-Integrated
It additionally has:
- valid Crosswalk membership;
- Registry-governed Mapping Type;
- valid cardinality;
- conflict treatment;
- gap treatment;
- Module lineage;
- Component lineage;
- tenant isolation.
58.4. Level 4 — Automation-Eligible
It additionally has:
- complete provenance;
- approved Mapping Decision;
- resolved rights;
- sufficient evidence;
- no blocking conflict;
- declared lossiness;
- HECATE validation;
- approved Change Decision where projection is intended;
- explicit activation boundary.
Automation eligibility SHALL NOT mean automatic activation.
59. Conformance Fixtures
Implementations SHOULD provide fixtures for:
- exact-equivalent mapping;
- semantic-equivalent mapping;
- conditional-equivalent mapping;
- broader-than mapping;
- narrower-than mapping;
- partial-overlap mapping;
- incompatible mapping;
- no-mapping result;
- unresolved mapping;
- directed mapping;
- valid bidirectional mapping;
- invalid bidirectional mapping;
- non-reversible mapping;
- one-to-one mapping;
- one-to-many mapping;
- many-to-one mapping;
- composite target mapping;
- partial composite mapping;
- mapping without identifier;
- mapping with invalid prefix;
- mapping without source version;
- mapping without target version;
- mapping with unresolved source;
- mapping without evidence;
- mapping with withdrawn evidence;
- mapping with separate authority dimensions;
- mapping incorrectly escalating legal authority;
- mapping with restricted source rights;
- public Crosswalk exposing prohibited text;
- jurisdiction-specific mapping;
- purpose-specific mapping;
- firmware-specific mapping;
- mapping with conditions and exceptions;
- multidimensional confidence;
- partial coverage;
- materially lossy mapping;
- bitemporal mapping;
- retroactively recorded mapping;
- Crosswalk Set with incomplete scope;
- deterministic Mapping Rule;
- AI-assisted mapping candidate;
- AI candidate incorrectly approved without review;
- exact value mapping;
- unmapped value;
- valid unit conversion;
- dimensionally incompatible unit mapping;
- taxonomy split mapping;
- taxonomy merged-class mapping;
- regulatory Requirement-to-Control mapping;
- framework mapping incorrectly claiming compliance;
- Control-to-Evidence mapping;
- certification mapping with bounded scope;
- dataset-to-schema mapping;
- schema mapping introducing unauthorised default;
- device-model mapping incorrectly applied to instance;
- methodology-to-computation mapping;
- Publication Crosswalk;
- competing mapping conflict;
- accepted jurisdictional divergence;
- stale mapping;
- valid mapping composition;
- invalid transitive composition;
- Change Candidate generated from approved mapping;
- Candidate generated from unresolved mapping;
- projected mapping without activation authority;
- tenant-scoped mapping;
- prohibited cross-tenant traversal;
- complete provenance;
- materially incomplete provenance;
- Exact Replay;
- Semantic Replay;
- complete Mapping Audit.
60. Migration and Compatibility
Specification revisions SHALL identify:
- source specification version;
- target specification version;
- changed Mapping Object fields;
- changed Mapping Types;
- changed cardinality rules;
- changed equivalence criteria;
- changed Mapping Rules;
- changed confidence or coverage models;
- migration rules;
- compatibility;
- affected mappings;
- affected Crosswalks;
- affected Change Candidates;
- affected projections;
- validation;
- provenance.
Migration SHALL NOT:
- reuse Mapping Identifiers;
- overwrite historical versions;
- infer missing evidence;
- infer authority;
- infer rights;
- infer applicability;
- convert unresolved to equivalent;
- merge conflicts silently;
- conceal gaps;
- widen mapping scope;
- activate projected output.
A source, target or Registry migration SHALL preserve original mapping references and historical graph state.
61. Security Requirements
Mapping and Crosswalk stores SHALL enforce:
- authentication;
- authorisation;
- least privilege;
- tenant isolation;
- white-label isolation;
- rights-aware retrieval;
- purpose-aware retrieval;
- encryption;
- access logging;
- tamper evidence;
- backup;
- recovery;
- incident response.
Restricted Mapping Evidence SHALL not be exposed merely because the Mapping Object itself is accessible.
62. Conformance Requirements
An implementation conforms to this specification where it:
- assigns every first-class mapping a stable
PP-MAP-identifier; - prevents Mapping Identifier reuse;
- distinguishes Mapping Objects from assertions, Crosswalks, Rules, Change Candidates and projections;
- preserves independent Mapping Object versions;
- preserves immutable approved versions;
- pins source and target versions;
- represents unresolved references explicitly;
- preserves source and target object roles;
- represents direction explicitly;
- prevents invalid inverse generation;
- represents cardinality explicitly;
- identifies partial composite mappings;
- governs Mapping Types through a Registry;
- defines allowed source and target classes;
- treats mappings as non-transitive by default;
- defines exact-equivalence criteria;
- distinguishes semantic, conditional, broader, narrower, partial, incompatible, no-map and unresolved relationships;
- prevents text similarity from establishing equivalence;
- requires structured rationale;
- links material mappings to Mapping Evidence;
- assesses evidence sufficiency separately from confidence;
- preserves independent authority, rights and version for each supporting source;
- propagates evidence withdrawal to dependent mappings;
- represents source, target, mapping, ZAYAZ governance and Runtime authority separately;
- prevents mapping-based authority escalation;
- prevents mappings from creating certification or legal status;
- preserves Rights Record relationships;
- prevents public Crosswalks from exposing restricted source content;
- propagates rights revocation to dependent objects;
- represents applicability explicitly;
- prevents reuse outside approved purpose without review;
- preserves jurisdiction, sector, role, framework, product, device, firmware, methodology, dataset, Module, Component, tenant, white-label and temporal scope where relevant;
- represents conditions, exceptions and qualifiers;
- includes conditions in mapping identity and equivalence analysis;
- preserves multidimensional confidence;
- prevents confidence from replacing evidence, authority or review;
- represents uncertainty explicitly;
- represents source, target and semantic coverage separately;
- prevents coverage percentages from implying equivalence;
- identifies Crosswalk completeness;
- identifies lossiness and reversibility;
- preserves bitemporal validity;
- prevents current mappings from being applied retroactively without an approved rule;
- separates proposal, decision, conflict, Publication, projection and activation status;
- represents Crosswalk Sets as first-class governed objects;
- preserves Crosswalk purpose;
- prevents Crosswalk membership from merging member authority or rights;
- governs Mapping Rules as versioned objects;
- distinguishes deterministic, probabilistic, AI-assisted and human-judgement Rules;
- prevents Rule execution from creating authority;
- governs value mappings and unknown-value treatment;
- prevents silent defaulting of unmapped values;
- governs unit conversion with dimensional validation;
- preserves conversion formula, precision, rounding and uncertainty;
- governs taxonomy and code-list mappings;
- prevents label-only code matching;
- governs framework and regulatory Crosswalks;
- prevents a Crosswalk from automatically establishing legal compliance;
- prevents framework certification from being treated as interchangeable without evidence;
- preserves normative-force differences;
- governs Requirement-to-Control mappings;
- governs Control-to-Evidence mappings;
- prevents Evidence-class mapping from proving evidence sufficiency;
- governs certification and assurance mappings;
- prevents mappings from creating certification status;
- governs dataset-to-schema mappings;
- preserves null, invalid and out-of-range value treatment;
- governs schema-to-schema mappings;
- prevents unauthorised defaults;
- governs device and Origin Crosswalks;
- distinguishes device-model mappings from tenant device-instance evidence;
- preserves firmware applicability;
- governs methodology-to-computation mappings;
- prevents mappings from activating Computation Hub logic;
- governs Publication and reporting Crosswalks;
- prevents public claims from exceeding evidence and rights;
- treats automated and AI outputs as candidates;
- preserves model, prompt, Rule and retrieval provenance;
- prevents AI from approving equivalence, legal status, certification status or activation;
- requires risk-appropriate expert review;
- preserves reviewer competence and separation of duties;
- records Mapping Decisions;
- limits approved mappings to declared purpose;
- preserves conflicts as first-class objects;
- prevents silent conflict resolution by confidence score;
- propagates blocking conflicts to dependent outputs;
- represents no-map and gap states explicitly;
- includes gaps in completeness reporting;
- preserves supersession, correction and withdrawal history;
- integrates approved mappings into the semantic graph without losing metadata;
- enforces rights, purpose, tenant, temporal and authority filters during graph traversal;
- prevents unsafe transitive mapping composition;
- exposes composed mapping paths;
- governs Crosswalk composition;
- detects source, target, semantic, Rule, rights, applicability and coverage drift;
- performs downstream impact analysis;
- generates Change Candidates only through traceable processes;
- prevents Candidate generation from approving change;
- separates mapping approval, projection and activation;
- enforces tenant and white-label isolation;
- governs promotion to global canonical knowledge;
- protects sensitive mapping existence and evidence;
- measures mapping quality without creating authority;
- supports mapping assurance and audit;
- prevents AI Agents from granting authority, rights or activation;
- validates objective structure through HECATE;
- prevents HECATE from inventing equivalence or evidence;
- preserves Module lineage;
- preserves Component lineage;
- preserves complete mapping provenance;
- blocks automation where provenance is materially incomplete;
- supports Exact Replay and Semantic Replay;
- prevents retroactive reinterpretation of historical mappings;
- defines four conformance levels;
- supports conformance fixtures;
- governs migration and compatibility;
- preserves original references through source, target and Registry migration;
- enforces security, auditability, resilience and historical trust.
63. Foundational Principle
A semantic mapping is a governed claim about the relationship between two meanings.
It SHALL preserve exactly what is being connected, in which direction, for which purpose, under which conditions, with what evidence, authority, rights, confidence, coverage and temporal validity.
Similar labels are not equivalent concepts. Shared intent is not identical scope. A partial overlap is not full satisfaction. A Control mapping is not proof of compliance. An Evidence-class mapping is not proof of evidence sufficiency. A manufacturer specification is not proof of field performance. A schema transformation is not automatically lossless. A composed Crosswalk is not automatically transitive.
Every unmapped concept SHALL remain visible. Every conflict SHALL remain reviewable. Every lossy transformation SHALL be disclosed. Every automated proposal SHALL remain distinguishable from an approved mapping. Every approved mapping SHALL remain separate from projection and activation.
By governing Mapping Objects, Mapping Rules and Crosswalk Sets as stable, evidence-linked, rights-aware, bitemporal and historically reconstructable objects, Pergamum Pulse can connect regulations, standards, Controls, evidence, datasets, devices, methodologies, certifications and ZAYAZ schemas without sacrificing constitutional authority, semantic precision, tenant isolation or trust.