Specification ID: CC-QMAP-SPEC-01

Version: 0.1 Candidate

Date: 19 September 2026

Programme: Codex Commons

Standing: INTERNAL — CANDIDATE SPECIFICATION / HOSTILE REVIEW. NOT ADMITTED. NOT PUBLIC. NOT MACHINE-READABLE.

1. Purpose

The Qualified Mapping Assertion Profile (QMAP) provides a small cross-domain semantic profile for making mappings explicit, contextual, provenance-bearing and standing-preserving.

QMAP treats a mapping as a first-class assertion, not an anonymous edge.

2. Problem

Mappings are frequently over-interpreted:

• MAPS_TO becomes SAME_AS;
• alignment becomes conformance;
• public crosswalk becomes customer acceptance;
• vendor compatibility becomes proven capability;
• approximate correspondence becomes exact equivalence;
• semantic mapping becomes executable transformation.

QMAP prevents those collapses while reusing established relation vocabularies.

3. Scope

QMAP defines:

1. Mapping Assertion identity;
2. required assertion qualifiers;
3. relation-selection guidance;
4. temporal/conflict/supersession semantics;
5. anti-collapse invariants;
6. interoperability guidance.

QMAP does not define:

• universal mapping predicates;
• ontology reasoning;
• mapping quality scores;
• transformation/ETL logic;
• authority;
• conformance;
• execution permission;
• provenance ontology;
• domain semantics.

4. Mapping Assertion

A Mapping Assertion states that, for a declared purpose and applicable scope, a Source Resource bears an explicit Relation to a Target Resource, under declared provenance and qualification.

A Mapping Assertion has its own identity.

It may be asserted, derived, accepted, rejected, contested, superseded, cited, revalidated or itself mapped.

5. Required fields

Every QMAP Mapping Assertion MUST identify:

1. mapping_assertion_id
2. source_ref
3. target_ref
4. relation_ref
5. mapping_purpose
6. assertion_provenance

6. Required when material

A Mapping Assertion MUST additionally identify where material:

1. source version;
2. target version;
3. source lens/type;
4. target lens/type;
5. scope/applicability;
6. effective time/interval.

7. Optional / linked qualifiers

QMAP MAY reference:

• rationale/evidence;
• acceptance/standing;
• confidence/qualification;
• conflict refs;
• supersedes/superseded-by;
• revalidation trigger;
• derivation/inference rule;
• grouped/composite mapping ref;
• jurisdiction/community;
• external authority.

These concerns remain independently governed.

8. Mapping purpose

Mapping purpose is mandatory.

The same resources may bear different mappings for:

• taxonomy harmonisation;
• benchmarking;
• semantic interoperability;
• architecture analysis;
• data transformation design;
• identity resolution;
• regulatory/control mapping;
• migration;
• reporting;
• operational use.

A mapping valid for one purpose MUST NOT be assumed valid for another without an explicit applicable basis.

9. Relation selection

QMAP does not own a universal relation vocabulary.

Selection order:

9.1 Established formal semantics

Use an established formal predicate when its semantics genuinely apply.

9.2 Concept-scheme mapping

Use SKOS mapping relations where the resources and intended semantics fit SKOS.

9.3 Domain vocabulary

Use a domain-defined predicate where appropriate.

9.4 Controlled local relation

If no suitable relation exists, a local predicate MAY be used only if:

• explicitly defined;
• owner/version identified;
• semantic strength is clear;
• it does not masquerade as equivalence;
• QMAP qualification is preserved.

10. Relation ≠ qualification

Relation semantics and assertion qualification are independent.

Example:

• relation = approximate/close relation;
• confidence = 0.72;
• provenance = model/version;
• purpose = terminology candidate mapping.

Do not create “weak exact equivalence” by mixing dimensions.

11. Mapping ≠ transformation

A Mapping Assertion describes a semantic relationship.

A transformation is an activity/process that converts, derives or produces something.

A transformation may use mapping assertions.

QMAP does not encode transformation logic.

12. Atomicity and composites

Default semantic unit: one Source + one Relation + one Target.

For n:m mappings:

• decompose into atomic assertions; or
• identify an explicit composite/grouped Source/Target resource where collective semantics are intended.

Do not hide semantics inside an undifferentiated table row/set.

13. Derived mappings

A derived/inferred Mapping Assertion MUST preserve:

• relation;
• derivation/inference provenance;
• applicable rule/logic where material;
• source premises where reconstructable.

Derived ≠ accepted.

14. Conflict

Conflicting Mapping Assertions MAY coexist.

QMAP does not choose the winner.

Each retains:

• identity;
• provenance;
• purpose;
• standing;
• effective scope/time.

Conflict may be linked explicitly for later assessment/governance.

15. Version and supersession

A source/target semantic version change MUST NOT silently inherit prior mapping standing where the changed semantics are material.

Historical assertions remain reconstructable.

A new/revalidated assertion is required where applicable.

16. Core invariants

I1 Source and target retain independent identity.

I2 Mapping Assertion is first-class.

I3 Relation semantics are explicit.

I4 Mapping purpose is mandatory.

I5 Provenance is mandatory.

I6 Relation ≠ confidence/qualification.

I7 Mapping existence ≠ mapping acceptance.

I8 Mapping ≠ equivalence by default.

I9 Mapping ≠ conformance.

I10 Mapping ≠ authority.

I11 Mapping ≠ runtime permission.

I12 Mapping ≠ transformation.

I13 Many-to-many semantics require decomposition or explicit grouping.

I14 Conflicting mappings may coexist.

I15 Historical/superseded mappings remain reconstructable.

I16 Derived mappings preserve derivation.

I17 Version change does not silently transfer mapping standing.

I18 Scope may be purpose/jurisdiction/community specific.

I19 Public availability does not establish reuse rights or acceptance.

I20 A relation must not be promoted to a stronger relation without an explicit licensed basis.

17. Interoperability

SKOS

Reuse concept-scheme mapping relations where appropriate.

OWL

Reuse formal identity/equivalence/subsumption only where formal semantics genuinely apply.

PROV-O

Reuse assertion provenance, derivation, attribution and revision.

RRAP

RRAP qualifies the role of representation/evidence resources.

QMAP qualifies relationships between source and target resources.

A Mapping Assertion may itself carry an RRAP role if useful.

Commons Non-Promotion Rule

QMAP is governed by:

No unlicensed semantic promotion.

18. Examples

EX1 — APQC

Source: APQC process reference.

Target: customer process.

Relation: domain-selected mapping relation.

Purpose: benchmarking.

Provenance: enterprise architect.

Does not imply process identity.

EX2 — BIAN

Source: BIAN domain.

Target: customer capability.

Purpose: sector architecture analysis.

May overlap rather than equal.

EX3 — TM Forum

Source: reference information concept.

Target: enterprise semantic concept.

Purpose: interoperability.

Version/lens required.

EX4 — CSDM

Source: operational application/service record.

Target: architecture application record.

Purpose: architecture↔operations trace.

Mapping does not make CSDM enterprise truth.

EX5 — Regulatory

Source: regulatory requirement.

Target: customer control.

Purpose: control coverage.

Mapping does not prove legal compliance.

EX6 — Vendor

Source: vendor capability claim.

Target: Arqua/customer responsibility.

Purpose: technology alignment.

Vendor claim standing remains separate from observed capability.

EX7 — AI-generated mapping

AI proposes source→target relation.

Provenance records model/version/rule.

Standing remains proposed until separately accepted.

EX8 — Temporal schema migration

Field v1 maps to field v2 for migration interval.

Later v3 changes semantics.

Old assertion remains historical; new mapping requires review.

19. Adoption

A consumer adopts QMAP when it:

• gives material mapping assertions identity;
• records source/target/relation/purpose/provenance;
• preserves relation semantics;
• does not infer stronger relations;
• preserves material version/scope/time;
• can retain conflict/supersession;
• separates mapping from transformation/conformance/authority.

20. Candidate conformance

A future implementation could claim QMAP profile conformance only if:

1. required fields are representable;
2. mapping assertions can be independently identified;
3. purpose/provenance cannot be omitted for material assertions;
4. external/domain relation semantics can be preserved;
5. conflicts/history can be retained;
6. transformation logic is not conflated with mapping semantics;
7. acceptance/authority/conformance remain separate.

No Commons conformance programme currently exists.

21. Hostile specification review

HSR-01 — Can relation be omitted?

NO — FAIL if omitted.

HSR-02 — Can purpose be optional?

NO for QMAP assertion — PASS.

HSR-03 — Can public crosswalk imply acceptance?

NO — PASS.

HSR-04 — Can confidence change exact relation semantics?

NO — PASS.

HSR-05 — Can transformation be stored as mapping?

NO — PASS.

HSR-06 — Can conflicting mappings coexist?

YES — PASS.

HSR-07 — Can AI assert mapping?

YES with provenance; not automatically accepted — PASS.

HSR-08 — Can a mapping itself be mapped?

YES — first-class assertion — PASS.

HSR-09 — Can version change silently inherit mapping?

NO — PASS.

HSR-10 — Does QMAP require Commons relation predicates?

NO — PASS.

HSR-11 — Does QMAP establish authority/conformance?

NO — PASS.

HSR-12 — Can n:m mapping hide atomic semantics?

Only if explicit grouped resource semantics exist; otherwise decompose — PASS.

Hostile specification result: PASS.

22. Remaining risks

1. “Qualified” may imply quality approval.
2. mandatory purpose may be burdensome for trivial identifier mappings.
3. first-class assertion identity may be heavier than simple crosswalks.
4. generic mapping assertion patterns may exist in standards/literature not yet reviewed.
5. relation/version metadata implementation remains undecided.
6. IP/publication review incomplete.

23. Naming

Preferred working name:

Qualified Mapping Assertion Profile (QMAP).

Before admission, test:

• Mapping Assertion Profile;
• Contextual Mapping Assertion Profile;
• Qualified Mapping Assertion Profile.

Do not rename yet.

24. Admission checklist

25. Decision

CC-QMAP-SPEC-01 v0.1 CANDIDATE — SPECIFICATION HOSTILE REVIEW PASS.

QMAP is coherent enough to proceed to focused mapping-assertion prior-art + naming review.

No admission, publication, namespace or implementation is authorised.

Linked

• 🧪CC-EXP-C04-03 — QMAP Semantic Stability & Hard Counterexample Test v0.1
• 🔎CC-EXP-C04-02 — QMAP Prior-Art & Relation Vocabulary Reduction v0.1
• 🧪CC-EXP-C04-01 — Mapping Qualification Envelope — Decomposition & Generality Test v0.1
• ⚖️CC-ADM-RRAP-01 — Representation Role Assignment Profile — Commons Admission Decision Package v0.1