Test ID: CC-QMAP-FIX-SNOW-01

Date: 29 September 2026

Subject: Snowflake / EnterpriseWeb metadata-derived hypergraph and NBN network-ontology mapping

Standing: INTERNAL HOSTILE / CONFORMANCE FIXTURE. Based on vendor-presented meeting observations. This does not establish vendor capability, NBN implementation approval, Commons publication authority or Arqua conformance.

1. Test question

Does the accepted-internal QMAP semantic pattern remain sufficient when applied to the observed Snowflake / EnterpriseWeb pattern:

Iceberg metadata + NBN Network Ontology → source-to-ontology mappings → metadata-derived hypergraph → Unified View → Cortex orchestration?

The test is specifically intended to falsify the need for a new Arqua “Representation Mapping Assertion” construct.

2. Fixture assumptions

For this test only:

• NBN remains authority for its network ontology.
• The ontology is authored in Protégé, versioned in GitHub and published/shared into the graph environment.
• NBN is standardising on Apache Iceberg.
• EnterpriseWeb derives a hypergraph from metadata and maps NBN source representations to the NBN network ontology.
• A Unified View is supplied to Cortex orchestration.
• Mapping generation may be automated or AI-assisted.
• Mapping and transformation are treated as distinct concerns unless evidence shows otherwise.

3. Test cases

T1 — Simple source-to-ontology mapping

Example:

SERVICE_INSTANCE.SITE_ID
    → NetworkService locatedAt NetworkSite

QMAP coverage

• independently identified source and target;
• explicit relation;
• mandatory mapping purpose;
• provenance;
• source/target versions where material;
• scope/applicability.

Result: PASS.

No new construct is required.

T2 — AI / system-generated candidate mapping

EnterpriseWeb or another model proposes a source-to-ontology relationship from discovered metadata.

QMAP explicitly permits AI-generated mappings when model/rule provenance is retained and standing remains separate from generation.

Required distinction:

generated
≠ reviewed
≠ accepted
≠ authoritative

Result: PASS.

QMAP already contains the needed non-promotion boundary.

T3 — Ontology version change

A mapping targets ontology commit/version A. NBN later publishes materially changed ontology version B.

QMAP explicitly requires material source/target versions and states that semantic version change must not silently inherit previous mapping standing. Historical mappings remain reconstructable and revalidation/new assertion is required.

Result: PASS.

This is an exact fit for the NBN GitHub-versioned ontology pattern.

T4 — Conflicting source interpretations

Two source systems or mapping processes produce different semantic interpretations for the same or overlapping operational subject.

QMAP allows conflicting mapping assertions to coexist with independent:

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

QMAP does not choose the winner.

Result: PASS.

Resolution remains an enterprise governance / assessment responsibility rather than a mapping-profile responsibility.

T5 — Mapping versus transformation

Example:

Semantic assertion:
SERVICE_INSTANCE.SITE_ID
    maps to
NetworkService locatedAt NetworkSite

Transformation:
SQL / pipeline / graph-building logic
    materialises or derives a runtime representation

QMAP explicitly states Mapping ≠ Transformation and does not own ETL/transformation logic.

Result: PASS, WITH IMPLEMENTATION-BINDING REQUIREMENT.

The implementation must preserve a recoverable link from transformation/projection logic to the QMAP assertion(s) it operationalises. This is not a new QMAP semantic field requirement by default; it can be carried using provenance/derivation and implementation-contract references.

T6 — Mapping accepted for analytics but not operational action

A mapping is accepted for an analytical or exploratory purpose but must not automatically be relied upon for operational control or consequential action.

QMAP requires mapping purpose, supports scope/applicability and preserves acceptance/standing independently. It explicitly states:

• mapping ≠ authority;
• mapping ≠ runtime permission;
• mapping ≠ conformance.

Result: PASS.

Arqua Context Qualification and EAA remain downstream responsibilities.

T7 — Ontology path / composite mapping

A source field may correspond not to one target concept but to a semantic path or grouped relationship, for example:

SITE_ID
    ↔
NetworkService → locatedAt → NetworkSite

QMAP's default unit is one Source + one Relation + one Target. It permits decomposition into atomic assertions or an explicitly identified grouped/composite resource where collective semantics are intended.

Result: PASS WITH CLARIFICATION.

No new top-level construct is required, but implementation guidance should make path/composite mappings explicit rather than hiding them inside an opaque mapping row.

T8 — Hypergraph relationship provenance

EnterpriseWeb derives a hypergraph relationship from source metadata + ontology mapping + derivation logic.

QMAP can identify the semantic mapping and its provenance, but the complete downstream derivation chain belongs jointly to:

• QMAP for the mapping assertion;
• PROV/derivation evidence for how the hypergraph edge was produced;
• Arqua representation/evidence mechanisms for downstream standing and use.

Result: PASS BY COMPOSITION.

QMAP should not be expanded into a universal derivation/provenance model.

T9 — Unified View consumption

A Unified View is assembled from the hypergraph and operational data and supplied to Cortex.

QMAP can tell us which source-to-semantic mappings contributed, but it does not establish that the assembled view is qualified for reliance.

Result: PASS BY BOUNDARY.

The correct chain remains:

QMAP mapping
→ accepted/usable enterprise representation
→ runtime context assembly
→ context qualification
→ Cortex / operational intelligence
→ proposed action
→ EAA

QMAP must not absorb RCA, Context Qualification or EAA responsibility.

4. Hostile counterexamples

H1 — Mapping stored only as procedural SQL

If semantic correspondence exists only implicitly inside SQL/transformation code and cannot be independently identified, purpose-scoped or provenance-bearing, QMAP conformance fails.

H2 — Hypergraph edge treated as ontology truth

If a derived hypergraph relation is promoted into authoritative ontology meaning solely because it was generated, QMAP / Commons Non-Promotion fails.

H3 — New ontology version silently inherits mapping

Fail. Revalidation/new assertion required where semantics materially changed.

H4 — Analytics acceptance reused for operations

Fail. Purpose/scope does not silently broaden.

H5 — Generated mapping treated as accepted mapping

Fail. Generation provenance does not establish institutional standing.

H6 — Mapping relation encoded as “sameAs” for convenience

Fail unless exact formal equivalence is actually intended and licensed by the applicable semantic basis.

5. Residual gap test

The Snowflake / EnterpriseWeb fixture does not reveal a missing semantic construct in QMAP.

It does reveal one implementation-contract requirement:

A technology implementation that operationalises QMAP mappings should preserve a recoverable reference from generated/runtime representations and transformation logic back to the mapping assertion identity, source/target versions and provenance used.

This is best handled by implementation binding / provenance / Arqua profile evidence, not by creating a new QMAP profile or new Arqua DAR.

6. Verdict

QMAP RESULT: PASS WITH IMPLEMENTATION-BINDING CLARIFICATION.

The Snowflake / EnterpriseWeb pattern does not falsify QMAP.

Specifically:

• simple mapping — PASS;
• AI-generated mapping — PASS;
• ontology versioning — PASS;
• conflicting mappings — PASS;
• mapping vs transformation — PASS WITH BINDING REQUIREMENT;
• purpose-bounded acceptance — PASS;
• path/composite mapping — PASS WITH CLARIFICATION;
• hypergraph derivation — PASS BY COMPOSITION;
• Unified View / runtime use — PASS BY BOUNDARY.

7. Architecture disposition

1. Do not create a new Arqua “Representation Mapping Assertion” construct.
2. Use QMAP for source↔ontology semantic mapping assertions.
3. Preserve transformation/projection logic as a separate implementation concern.
4. Use provenance/derivation evidence to connect mapping assertions to derived hypergraph structures.
5. Keep Unified View assembly distinct from Context Qualification.
6. Keep Cortex/tool capability distinct from EAA/admissibility.
7. Use the Snowflake / EnterpriseWeb case as a real-world QMAP and PF-02 Technology Alignment fixture.

8. Recommended follow-up

Add one implementation-facing conformance question to technology profiles:

Can each material derived representation, semantic projection or runtime view be traced to the mapping assertion(s), source/target versions, provenance and transformation/derivation logic that produced it?

No QMAP schema expansion is recommended unless a future implementation fixture demonstrates that the existing identity/purpose/provenance/version/scope model cannot express the required semantic relationship.