Codex Resonance
/
Codex Commons
/
🧬
CC-EXTRACT-ARQUA-01 — Commons Candidate Extraction from Recent Arqua–CR Work v0.1
/
🧪
CC-EXP-C04-01 — Mapping Qualification Envelope — Decomposition & Generality Test v0.1
🧪

CC-EXP-C04-01 — Mapping Qualification Envelope — Decomposition & Generality Test v0.1

Experiment ID: CC-EXP-C04-01

Version: 0.1

Date: 19 September 2026

Candidate: CC-C04 — Mapping Qualification Envelope (MQE)

Standing: INTERNAL — EXECUTED DECOMPOSITION / GENERALITY / HOSTILE TEST. NO COMMONS ADMISSION OR PUBLICATION AUTHORISED.

Question

Is there a reusable cross-domain semantic profile for qualifying mappings between independently governed model elements without collapsing mapping into identity, truth, conformance or authority?

Candidate problem:

A mapping such as A MAPS_TO B is usually incomplete unless we know:

  • what A and B are;
  • which versions/lenses apply;
  • why the mapping exists;
  • what relation is actually asserted;
  • scope/applicability;
  • evidence/rationale;
  • who made/accepted it;
  • temporal standing;
  • conflicts/supersession;
  • revalidation conditions.

Executive result

STRONG PASS — A QUALIFIED MAPPING PROFILE IS GENERAL AND COMPLEMENTS RRAP.

However, “Mapping Qualification Envelope” should remain a working name.

The stable semantic core is not a giant mapping object. It is a qualified assertion about a relationship between independently identified source and target elements.

Core candidate

Critical distinction

A mapping is itself a proposition/claim with provenance and standing.

Therefore:

mapping existence ≠ equivalence

mapping assertion ≠ accepted mapping

accepted mapping ≠ conformance

mapping ≠ authority

mapping ≠ truth

This aligns directly with the approved Commons Non-Promotion Rule.

Decomposition

Core semantic fields

Candidate minimum:

  1. source_ref
  2. target_ref
  3. relation_type
  4. mapping_purpose
  5. assertion_provenance

These are required for a meaningful qualified mapping.

Conditional qualifiers

  1. source version/lens;
  2. target version/lens;
  3. scope/applicability;
  4. rationale/evidence;
  5. effective time;
  6. qualification/confidence;
  7. conflict refs;
  8. supersession;
  9. revalidation trigger;
  10. acceptance/standing ref.

Not every domain requires every field.

Why mapping purpose is mandatory

The same two elements may legitimately have different relationships for different purposes.

Example:

A customer process and APQC reference may:

  • MAP_TO for taxonomy harmonisation;
  • OVERLAP_WITH for architecture analysis;
  • ALIGN_WITH for benchmarking;

without being SAME_AS.

Without purpose, consumers may over-generalise the assertion.

Finding: mapping purpose is a core semantic qualifier, not optional metadata.

Why lens matters

One external framework owner may publish multiple lenses.

Example:

TM Forum process, information, component and API artefacts.

A mapping must identify the relevant source/target lens where ambiguity is possible.

Lens may be encoded through the referenced element/type rather than a mandatory separate field, but the semantics must be recoverable.

Generality tests

G1 — Industry framework → customer process

APQC process reference maps to customer process for benchmarking.

Relation/purpose/version needed.

Does not imply identity.

PASS.

G2 — Banking framework → capability

BIAN domain aligns with customer capability for sector analysis.

One BIAN domain may overlap several capabilities.

PASS.

G3 — Telecom information model → enterprise concept

SID concept maps to customer semantic concept.

Mapping may be candidate/accepted/contested and version-specific.

PASS.

G4 — CSDM → architecture repository

Operational application/service record maps to architecture application record.

Identity may be one-to-one, one-to-many or conditional.

PASS.

G5 — Data product ontology → customer data product

External descriptor/ontology term maps to customer product/interface semantics.

Source vocabulary remains external.

PASS.

G6 — Vendor capability → Arqua responsibility

Vendor capability aligns to an Arqua responsibility for a declared workload.

Requires V1 evidence, V2 interpretation and conditions.

PASS.

G7 — Regulatory requirement → customer control

Requirement maps to control.

Mapping does not prove compliance or legal sufficiency.

STRONG PASS.

G8 — Clinical terminology mapping

Terminology A maps to terminology B for a declared use/context.

Exact equivalence, broader/narrower or approximate mapping matters.

PASS.

G9 — Software schema migration

Field v1 maps to field v2.

Temporal/version/supersession semantics required.

PASS.

G10 — Multilingual terminology

Term in language A maps to term in language B for a domain/context.

Translation mapping may not be semantic equivalence.

PASS.

Hostile tests

H1 — SAME_AS abuse

Mapper selects SAME_AS because names look similar.

FAIL mapping quality unless equivalence basis is explicit.

MQE must not validate relation correctness merely because relation is populated.

H2 — Mapping accepted by one institution, rejected by another

Both standings can coexist.

Mapping assertion identity and acceptance standing must remain separate.

PASS.

H3 — Mapping changes after framework version update

Old mapping remains historical; new version triggers reassessment.

PASS.

H4 — Mapping produced by AI

AI can assert/propose mapping with provenance.

It does not become accepted mapping automatically.

PASS.

H5 — Conflicting mappings

A maps to B under one purpose and C under another; or two agents disagree.

Preserve both with purpose/provenance/standing/conflict.

PASS.

H6 — Mapping inferred by formal ontology

If an explicit logic licenses entailment, mapping/relationship may be derived.

Record derivation/provenance; do not pretend human assertion.

PASS.

H7 — Mapping has no purpose

Consumers cannot know intended use.

FAIL for MQE-conformant qualified mapping.

Purpose remains mandatory.

H8 — Mapping source is public

Public availability does not grant reuse rights, authority or customer acceptance.

PASS — Non-Promotion Rule.

H9 — Mapping drives runtime action

A semantic mapping may contribute context but does not create execution authority.

PASS.

H10 — Exact identifier crosswalk

Simple ID A ↔ ID B under a master-data authority.

Purpose may be identity resolution and relation exact-match.

Still requires provenance/authority basis.

PASS.

Relationship to existing vocabularies

Likely reuse areas:

  • SKOS mapping relations for exact/close/broad/narrow/related concept mappings where applicable;
  • OWL equivalence/subsumption where formal ontology semantics genuinely apply;
  • PROV-O for mapping assertion provenance;
  • DCAT/DCTERMS for source/version/catalogue metadata where applicable;
  • domain-specific crosswalk/mapping standards.

MQE should not invent replacements for these.

Candidate contribution is the qualification envelope/profile around the mapping assertion.

Relationship to RRAP

RRAP answers:

What role is this representation/evidence item playing?

MQE answers:

What exactly is being asserted when this source element is related to this target element, for what purpose and under what standing?

They complement each other.

A Mapping Assertion itself could carry an RRAP role where useful, but neither profile depends on the other.

Relationship to SNPP

SNPP/Commons Non-Promotion Rule constrains MQE:

  • MAPS_TO does not promote to SAME_AS;
  • ALIGNS_WITH does not promote to CONFORMS_TO;
  • accepted mapping does not promote to authority;
  • mapping transfer does not promote acceptance.

MQE is therefore a concrete semantic profile where the governance rule is directly useful.

Prior-art risk

The individual ingredients are established:

  • qualified relationships;
  • provenance;
  • SKOS mappings;
  • ontology equivalence;
  • crosswalks;
  • versioning.

Do not claim invention.

Potential Commons contribution:

a small cross-domain profile requiring mapping purpose, explicit relation semantics and provenance while preserving source/target independence and mapping standing.

Working-name test

Mapping Qualification Envelope (MQE)

Useful internal phrase but “qualification” may overlap Arqua Context Qualification and imply validation.

HOLD as internal lineage name.

Qualified Mapping Assertion Profile (QMAP)

Emphasises mapping as assertion and qualification.

Risk: “qualified” still may imply quality approval.

PASS.

Mapping Assertion Profile (MAP)

Simple and accurate, but acronym is generic/ambiguous.

PASS/HOLD.

Mapping Context Profile (MCP)

Conflicts with common technology acronym and understates assertion standing.

REJECT.

Preferred working candidate after this test:

Qualified Mapping Assertion Profile (QMAP)

Do not rename formally yet.

Minimum invariants

  1. Source and target retain independent identity.
  2. Mapping is an assertion/proposition, not identity by default.
  3. Relation semantics must be explicit.
  4. Mapping purpose is mandatory.
  5. Provenance is mandatory.
  6. Mapping standing/acceptance is separate from mapping existence.
  7. Version/lens/applicability must be recoverable where material.
  8. Conflicting mappings may coexist.
  9. Superseded mappings remain reconstructable.
  10. Mapping does not establish conformance, authority or runtime permission unless separately licensed.

Experiment result

10/10 generality cases PASS.

10/10 hostile cases survive with required guardrails.

Decision

CC-EXP-C04-01 — STRONG GENERALITY / DECOMPOSITION PASS.

The Mapping Qualification Envelope candidate should advance as a small mapping-assertion interoperability profile.

Recommended next:

  1. prior-art reduction against SKOS/OWL/PROV and mapping/crosswalk patterns;
  2. test QMAP naming;
  3. determine whether relation vocabulary CC-C02 should be inside QMAP or separately reuse external relations;
  4. do not admit/publish yet.

Linked

🔎CC-EXP-C04-02 — QMAP Prior-Art & Relation Vocabulary Reduction v0.1