Record: CC-TEP-T02 v0.1
Date: 27 September 2026
Standing: EXECUTED HOSTILE CROSS-BOUNDARY SEMANTIC TEST — NO CUSTOMER ADOPTION OR IMPLEMENTATION CLAIM
Target: QMAP + Assessment Assertion + RRAP + Non-Promotion + TEP.
Question
Can a customer reconstruct material transition semantics of an Arqua EAA decision using its own semantic model, without importing Arqua's ontology or transferring Arqua authority?
Fixture
Arqua evidence package:
- EAA Decision ED-17;
- proposed action A-17;
- outcome ADMISSIBLE_WITH_CONDITIONS;
- actor Agent-4;
- action authority Delegation-9;
- authority scope ServiceDomain-X;
- policy basis Policy-P7 v3;
- QCM-44 v2;
- conditions C1/C2;
- decision time t1;
- bounded/currentness-dependent commit validity.
Customer model deliberately uses different concepts:
- change request;
- automation principal;
- approval mandate;
- control set;
- evidence pack;
- execution preconditions;
- approval record;
- effective window.
No customer concept is assumed identical to the Arqua concept.
Mapping tests
Action: proposed action → change request. Plausible QMAP, not identity. TEP materiality HIGH.
Actor: actor → automation principal. PRESERVED_WITH_CONDITIONS because technical principal may not identify accountable human/organisation.
Authority: action authority → approval mandate. PASS. Hostile shortcut to approver is REJECTED: actor identity is not authority/delegation basis.
Authority scope: authority scope → mandate/service scope. If target retains only approver identity, LOSSY_MATERIAL.
Policy basis: Arqua policy basis → customer control/policy reference. Preserve source/version. Arqua policy does not become customer policy through mapping.
Qualified context: QCM → customer evidence/assessment structures. QCM = evidence pack is REJECTED as identity because QCM also carries qualification basis/result/intended reliance.
Conditions: EAA conditions → execution preconditions. PASS WITH CONDITIONS if inherited Arqua decision conditions, customer-adopted controls and implementation preconditions remain distinguishable.
Time/currentness: decision/effective/currentness → approval/effective window. PASS if exact temporal basis survives; record-creation date alone is LOSSY_MATERIAL.
Customer standing test
Even if every semantic mapping is exact:
Arqua EAA decision ≠ customer execution authority.
Customer standing requires an explicit customer-applicable basis/process.
Positive case:
Arqua EAA decision
- explicit customer rule/contract adopting a specified Arqua decision role for purpose/scope/time
- customer acceptance/control process
→ customer standing/permission record.
Target standing comes from the customer-applicable basis, not from QMAP or Arqua standing alone.
TEP reconstruction
FROM WHAT? PASS — action/change request + QCM/evidence refs.
TO WHAT? PASS — Arqua decision and separate customer approval/standing if created.
WHAT HAPPENED? PASS — EAA decision event and customer adoption event remain separate.
WHY? PASS if purpose/intent retained.
BY WHOM/WHAT? PASS if actor/principal plus accountability distinctions preserved.
UNDER WHAT BASIS? PASS only if Arqua and customer authority/policy bases remain separately represented.
USING WHAT EVIDENCE? PASS through QCM/evidence refs and customer evidence.
WHEN? PASS if effective/currentness survives.
CONDITIONS/LIMITS? PASS if EAA conditions and customer preconditions remain distinguishable.
WHAT FOLLOWED? PASS if execution/outcome separately evidenced.
WHAT WAS PRESERVED? PASS — source standing, Arqua identity, customer sovereignty, provenance.
WHAT CHANGED LATER? PASS through lifecycle/supersession/revision.
Overall: PASS WITH EXPLICIT CUSTOMER ADOPTION BOUNDARY.
Hostile collapse tests
- Arqua actor = customer authority holder: REJECT.
- Arqua authority = customer authority: REJECT.
- QCM = customer evidence package: REJECT as identity.
- EAA ADMISSIBLE = customer approved: REJECT.
- Arqua condition = customer control: REJECT unless explicitly adopted.
- exact semantic mapping = standing transfer: REJECT.
- customer execution proves Arqua decision correct: REJECT.
- later customer policy rewrites historical basis: REJECT.
All pass under existing Commons + TEP boundaries.
Does Commons need Arqua ontology?
NO.
Commons needs to preserve/map semantic roles material to declared purpose, not force identical vocabularies.
Customer retains its own actor, authority/delegation, policy/control and decision semantics.
QMAP records qualified relationships.
Assessment Assertion can assess whether mappings preserve semantics required for TEP reconstruction.
Semantic preservation result
- action identity: PRESERVED
- actor identity: PRESERVED_WITH_CONDITIONS
- authority identity: PRESERVED if mapped to mandate/delegation
- authority scope: PRESERVED_WITH_CONDITIONS
- policy basis/version: PRESERVED
- qualification basis: PRESERVED_WITH_CONDITIONS
- conditions: PRESERVED_WITH_CONDITIONS
- time/currentness: PRESERVED
- customer standing: NOT TRANSFERRED; separately established
Result
STRONG PASS.
QMAP + Assessment Assertion + RRAP + Non-Promotion preserve TEP reconstructability across an Arqua→customer semantic boundary without importing Arqua ontology, forcing vocabulary identity, transferring authority, making Commons a runtime authority or adding a fourth Commons profile.
Earned guidance candidate
Purpose-Relative Semantic Preservation: When a mapping participates in a declared downstream reliance, the material semantic distinctions required for that reliance must remain recoverable or be explicitly identified as conditional/lost. Semantic preservation does not transfer standing or authority.
For consequential reconstruction, TEP may be used as the assessment basis.
Customer sovereignty rule
Interoperability should preserve the customer's ability to express the same material institutional distinction in its own semantics, not require the customer to adopt Arqua's vocabulary or authority model.
Architecture consequence
Recommend:
- admit Purpose-Relative Semantic Preservation as Commons guidance/invariant;
- reference TEP as an optional Assessment Assertion basis;
- retain QMAP/RRAP/Assessment as the three-profile kernel;
- do not add a Transition Semantic Profile;
- retain this as the worked customer-boundary fixture.
No further Commons kernel expansion is justified by TEP.