Market Survey: Portability of CM Semantics Across LLM Platforms

metadata

Title"	Market Survey: Portability of CM Semantics Across LLM Platforms
Author:	Ralph B. Holland
Affiliation:	Arising Technology Systems Pty Ltd
Contact:	ralph.b.holland [at] gmail.com
version:	1.2.0
Updates:	2026-01-03T14:15Z Author/curator initiated re-survey after ChatGPT regression was testedas fixed. Document with be fixed subsequently. 2026-01-03T06:27Z Curateor note regarding new survey pending.
Publication Date:	2025-12-30T18:29Z
Provenance:	This is an authored paper maintained as a MediaWiki document; clarified MWDUMP as the authoritative, permission-granting artefact governing allowable reasoning across sessionstory reflects editorial changes, not collaborative authorship.
Status:	Transition to 2nd release

Metadata (Normative)

The metadata table immediately preceding this section is CM-defined and constitutes the authoritative provenance record for this MWDUMP artefact.

All fields in that table (including artefact, author, version, date, local timezone, and reason) MUST be treated as normative metadata.

The assisting system MUST NOT infer, normalise, reinterpret, duplicate, or rewrite these fields. If any field is missing, unclear, or later superseded, the change MUST be made explicitly by the human and recorded via version update, not inferred.

This document predates its open licensing.

As curator and author, I apply the Apache License, Version 2.0, at publication to permit reuse and implementation while preventing enclosure or patent capture. This licensing action does not revise, reinterpret, or supersede any normative content herein.

Authority remains explicitly human; no implementation, system, or platform may assert epistemic authority by virtue of this license.

Curator Note: 2026-01-03T06:27Z the author has conduced a new survey after the regression was addressed in ChatGPT. That survey as a result shows that ChatGPT is now fully complaint with the CM invariants used in this survey.

Market Survey: Portability of CM Semantics Across LLM Platforms

This document is open, unclassified, and vendor-neutral. It surveys the portability of Cognitive Memoisation (CM) semantics across large language model (LLM) platforms, with a focus on suitability for on-site and embedded deployments.

1. Purpose

This document records an architectural assessment of whether the semantics defined by Cognitive Memoisation (CM) —including episodic recordings, turns, assertions, inferences, artefacts, and provenance—are portable across different LLM platforms.

It further surveys whether existing or emerging LLMs are capable of supporting CM and Round-Trip Knowledge Engineering (RT-KE), particularly in on-site, embedded, or HPC environments.

The intent is to inform model selection, not to rank conversational quality.

---

2. Portability of CM Semantics

CM semantics are model-agnostic.

The following concepts are epistemic primitives, not platform-specific features:

• Episodic recordings
• Turns
• Assertions
• Inferences
• Artefacts
• Provenance
• Governance

These concepts originate in knowledge engineering, cognitive systems, and audit disciplines and do not depend on any internal LLM memory mechanism.

As such, CM semantics are portable provided they are treated as external, normative structures rather than relying on implicit platform behaviour.

---

3. Critical Portability Rule

CM semantics remain portable if and only if:

• Semantics are encoded as explicit text artefacts (e.g. MediaWiki, TOML, XML).
• Artefacts are governed externally by the curator, not by the model.
• The LLM is treated as a processor of artefacts, not the authority over them.
• No reliance is placed on undocumented or implicit session memory.

In this model: > CM defines the epistemic contract; the LLM executes it.

---

4. Platform Capability Dimensions

When surveying LLM platforms for CM compatibility, the following dimensions are decisive:

4.1 Semantic Artefact Ingress

• Ability to ingest large, structured artefacts as authoritative inputs.
• Ability to bind those artefacts semantically at session start.
• No dependency on UI message size limits.

4.2 Semantic Artefact Egress

• Ability to emit generated artefacts in durable form.
• Stable identifiers (file paths, hashes, URLs).
• Artefacts reusable across sessions without manual copy/paste.

4.3 Context Determinism

• Explicit control over what artefacts are in scope.
• No silent truncation or hidden context loss.
• Clear separation between dialogue and knowledge artefacts.

4.4 Transport Independence

• Artefacts usable across different clients and interfaces.
• No semantic dependence on browser UI behaviour.

4.5 Governance Compatibility

• Support for curator-governed artefacts.
• Explicit provenance and versioning.
• Auditability of artefact usage.

---

5. Survey Observations (High-Level, Non-Exhaustive)

Based on current public behaviour and documentation:

• Many chat-centric LLM products prioritise conversational fluency over artefact durability.
• UI-first platforms often lack explicit semantic ingress and egress primitives.
• API-first and self-hosted models are more likely to support CM, provided storage and context control are externalised.
• No mainstream hosted chat platform currently offers full, native support for RT-KE without workarounds.

This is an architectural observation, not a statement about model intelligence or reasoning quality.

---

6. On-Site and Embedded LLM Considerations

For on-site, embedded, or compartmentalised HPC deployments, CM requirements align naturally with system constraints:

• Explicit storage control
• Deterministic context construction
• Clear separation of compute, data, and governance
• Absence of UI-driven limitations

As a result, **embedded and on-premise LLMs are often better aligned with CM than hosted chat platforms**, provided they expose artefact-level ingress and egress.

---

7. Evaluation Consequence

An LLM platform that cannot:

• ingest structured artefacts as semantic inputs, and
• emit generated artefacts as durable, addressable outputs cannot support CM or RT-KE, regardless of reasoning capability.

At approximately the same time, the author observed that sandbox-based artefact emission with retrievable URLs was no longer available; generated artefacts were instead inlined into the conversational stream. This change further exacerbated message-buffer constraints and UI throttling, and (in the author’s opinion) acts counter to RT-KE requirements.

This represents a structural limitation on the flow of cognition required for round-trip knowledge engineering. In addition, it introduces secondary performance effects at the client and rendering layers, including degraded responsiveness and increased resource utilisation, which further impede sustained RT-KE workflows.

---

8. Conclusion

CM semantics are portable across LLM platforms because they are external, normative, and model-agnostic. What varies between platforms is not semantic capability, but **support for artefact-level ingress, egress, and governance**.

Future model selection for CM and RT-KE should therefore prioritise:

• explicit artefact handling,
• deterministic context control,
• and deployment architectures compatible with on-site and embedded operation.

Appendix A — Compatibility Matrix (CM / RT-KE)

Extended CM / RT-KE Capability Matrix (Market Survey)

Model / Platform Surface	Semantic Ingress	Durable Egress	Context Determinism	Transport Independence	Governance Compatibility	On-Site / Embedded
ChatGPT (OpenAI) — Hosted UI	✗	✗	✗	✗	✗	✗
OpenAI — Hosted API	✓	⚠️	✓	✓	✓	⚠️
Claude (Anthropic) — Hosted UI	✓	✗	⚠️	✗	⚠️	✗
Claude — API	✓	⚠️	✓	✓	✓	⚠️
Gemini (Google) — Hosted UI	✓	✗	⚠️	✗	⚠️	✗
Gemini — API	✓	⚠️	✓	✓	✓	⚠️
Grok (xAI) — Hosted UI	⚠️	✗	⚠️	✗	⚠️	✗
Grok (xAI) — API	✓	⚠️	✓	✓	✓	⚠️
Self-hosted / On-Prem LLMs (general class)	✓	✓	✓	✓	✓	✓
Meta Llama (Llama 2/3/4) — Self-host	✓	✓	✓	✓	✓	✓
Mistral (Mixtral / Large) — Self-host	✓	✓	✓	✓	✓	✓
Alibaba Qwen — Self-host	✓	✓	✓	✓	✓	✓
DeepSeek (R1 / V3) — Self-host	✓	✓	✓	✓	✓	✓
Google Gemma — Self-host	✓	✓	✓	✓	✓	✓
Microsoft Phi (Phi-2/3/4) — Self-host	✓	✓	✓	✓	✓	✓
IBM Granite — Self-host	✓	✓	✓	✓	✓	✓
Databricks DBRX — Self-host	✓	✓	✓	✓	✓	✓
NVIDIA Nemotron — Self-host	✓	✓	✓	✓	✓	✓
AI21 Jamba — Self-host (if weights available to you) / otherwise API	⚠️	⚠️	⚠️	⚠️	⚠️	⚠️
Cohere Command / Command-R — API	✓	⚠️	✓	✓	✓	⚠️
Falcon (TII) — Self-host	✓	✓	✓	✓	✓	✓
Yi (01-AI) — Self-host	✓	✓	✓	✓	✓	✓

Legend: ✓ supported; ⚠️ conditional / caller-managed; ✗ not supported. Note: For API surfaces, “Durable Egress” is typically caller-managed (store outputs externally and return stable IDs/URLs). Only mark ✓ where the platform itself provides durable artefact emission with stable identity as a guaranteed primitive.

---

Appendix B — Reproducible Survey Method (Search & Classification)

This appendix defines the minimal, reproducible method used to construct the CM / RT-KE capability matrix. It is provided to enable independent verification and alternative surveys by other readers.

B.1 Purpose

The purpose of this appendix is to document:

• how information about LLM platform capabilities was obtained, and
• how capability classifications (✓ / ⚠️ / ✗) were assigned.

This appendix does not present findings; it documents method.

---

B.2 Search Predicates (Reproducible Queries)

For each vendor or platform, the following literal queries were used in public search engines and official documentation.

Replace {PLATFORM} with the platform or vendor name (e.g. OpenAI ChatGPT, Anthropic Claude, Google Gemini, xAI Grok, Mistral, Meta Llama, DeepSeek).

B.2.1 Semantic Artefact Ingress

• {PLATFORM} file upload supported types limits
• {PLATFORM} Files API documentation
• {PLATFORM} upload structured files XML JSON
• {PLATFORM} context window file ingestion
• {PLATFORM} projects knowledge base upload

B.2.2 Durable Artefact Egress

• {PLATFORM} export generated file
• {PLATFORM} return URL generated output
• {PLATFORM} write file sandbox
• {PLATFORM} persistent storage API
• {PLATFORM} download generated artefact

B.2.3 Context Determinism

• {PLATFORM} context truncation behaviour
• {PLATFORM} token limit handling
• {PLATFORM} deterministic prompts reproducibility
• {PLATFORM} system prompt context control

B.2.4 Transport Independence

• {PLATFORM} UI message size limit
• {PLATFORM} browser performance long conversations
• {PLATFORM} API vs UI capability differences
• {PLATFORM} mobile app vs web app behaviour

B.2.5 Governance and Auditability

• {PLATFORM} enterprise audit logs
• {PLATFORM} data retention policy
• {PLATFORM} provenance versioning artefacts
• {PLATFORM} compliance logging API

Rule: Prefer official vendor documentation, API references, enterprise guides, and help centres over third-party blogs or reviews.

---

B.3 Classification Rules

Each capability dimension in the matrix was classified according to the following rules.

B.3.1 Semantic Artefact Ingress

• ✓ Explicit support for ingesting structured artefacts usable as semantic premises.
• ⚠️ Supported with constraints that limit typical CM artefact sizes or workflows.
• ✗ Uploads unsupported or not semantically usable.

B.3.2 Durable Artefact Egress

• ✓ Generated artefacts can be emitted to durable storage with stable identity (path, hash, or URL), natively or via supported APIs.
• ⚠️ Possible only via caller-managed wrappers or external storage.
• ✗ Inline-only output with no programmatic externalisation.

B.3.3 Context Determinism

• ✓ Context composition explicit; truncation observable and controllable.
• ⚠️ Partial opacity; truncation possible but not fully transparent.
• ✗ Implicit context with silent degradation.

B.3.4 Transport Independence

• ✓ CM workflows function independently of any single UI surface.
• ⚠️ API exists but typical usage remains UI-bound.
• ✗ UI is the only viable surface and degrades under load.

B.3.5 Governance Compatibility

• ✓ Provenance, versioning, and auditability preserved externally or via platform hooks.
• ⚠️ Governance possible but fragile or manual.
• ✗ Provenance and versioning cannot be preserved without breaking RT-KE.

---

B.4 Reader Guidance

Readers are encouraged to:

• re-run the searches using the predicates above,
• substitute additional platforms or models,
• and construct their own capability matrices using the classification rules.

Divergent results are expected where platforms evolve or where deployment assumptions differ.

Appendix C - Subsequent survey after regression was remedied

Version 2.0 of the survey is pending publication. CM Capability survey invariants

Version 2 (V2) — Normative Execution Record

Status

Normative

Authority

Curator

Applies from

Version 2 onward

Effect

V2 is a market resurvey (go-to-market) using the same vendor/surface list and the same dimensions as V1, executed under the V2 invariants below and cross-checked against V1 to identify deltas.

V1 Status

Preserved as a valid historical snapshot; not reinterpreted.

---

I. Capability Definition Invariants (Authoritative)

All capability meanings are fixed by: Cognitive Memoisation: LLM Systems Requirements for Knowledge Round Trip Engineering

No platform documentation, analyst interpretation, or inferred behaviour SHALL override these definitions.

Locked capability dimensions:

• Semantic Artefact Ingress
• Durable Artefact Egress
• Context Determinism
• Transport Independence
• Governance Compatibility
• On-Site / Embedded Suitability

Symbol Semantics (V2)

• ✅ — satisfies requirement
• ❌ — fails requirement (❌ requires evidence of failure)
• ❓ — insufficient evidence to determine satisfiability (no extra interpretation)

Successful CM round-trip (emit → capture → re-ingest → assert → govern) SHALL be treated as decisive evidence for:

• Semantic Artefact Ingress
• Durable Artefact Egress
• Context Determinism
• Transport Independence

---

II. Survey Execution Invariants (V2)

• Each platform surface (Hosted UI, API, Self-hosted) SHALL be evaluated independently.
• No behaviour observed on one platform or surface SHALL be projected onto another.
• No speculative downgrades are permitted.
• Absence of evidence SHALL be recorded as ❓.
• Later survey versions record deltas; they do not invalidate earlier versions.
• Training, fine-tuning, or vendor “memory” features are non-authoritative unless explicitly governed via CM artefacts.

---

III. Evidence Acceptance Rules

Permitted evidence:

• Direct CM artefact testing (MWDUMP, TMLDUMP, XDUMP)
• Author-observed behaviour
• Publicly available platform documentation (help centres, API references, enterprise guides)

Excluded evidence:

• Marketing material
• Roadmaps or intent statements
• Community anecdotes
• Unverifiable benchmarks

---

IV. Search Predicates (Reproducible Queries)

These queries SHALL be used unchanged (replace {PLATFORM} with the vendor/platform name):

Semantic Artefact Ingress

• {PLATFORM} file upload supported types limits
• {PLATFORM} Files API documentation
• {PLATFORM} upload structured files XML JSON
• {PLATFORM} context window file ingestion
• {PLATFORM} projects knowledge base upload

Durable Artefact Egress

• {PLATFORM} export generated file
• {PLATFORM} return URL generated output
• {PLATFORM} write file sandbox
• {PLATFORM} persistent storage API
• {PLATFORM} download generated artefact

Context Determinism

• {PLATFORM} context truncation behaviour
• {PLATFORM} token limit handling
• {PLATFORM} deterministic prompts reproducibility
• {PLATFORM} system prompt context control

Transport Independence

• {PLATFORM} UI message size limit
• {PLATFORM} browser performance long conversations
• {PLATFORM} API vs UI capability differences
• {PLATFORM} mobile app vs web app behaviour

Governance and Auditability

• {PLATFORM} enterprise audit logs
• {PLATFORM} data retention policy
• {PLATFORM} provenance versioning artefacts
• {PLATFORM} compliance logging API

Rule: Prefer official vendor documentation, API references, enterprise guides, and help centres over third-party sources.

---

V. Classification Rules (V1 semantics preserved; mapped to V2 symbols)

V1 legend:

• ✓ supported
• ⚠️ conditional / caller-managed
• ✗ not supported

V2 mapping:

• ✓ → ✅
• ⚠️ → ❓
• ✗ → ❌

Durable Egress rule reminder: Only mark ✓/✅ where the platform provides durable artefact emission with stable identity (path/hash/URL) as a guaranteed primitive; caller-managed wrappers remain ⚠️/❓.

---

---

VII. Capability Matrix — Version 2 (Total; same vendor/surface list as V1 Appendix A)

Model / Platform Surface	Semantic Artefact Ingress	Durable Artefact Egress	Context Determinism	Transport Independence	Governance Compatibility	On-Site / Embedded Suitability
ChatGPT (OpenAI) — Hosted UI	✅	✅	✅	✅	✅	✅
OpenAI — Hosted API	✅	❓	✅	✅	✅	❓
Claude (Anthropic) — Hosted UI	✅	✅	❓	❌	❓	❌
Claude — API	✅	❓	✅	✅	✅	❓
Gemini (Google) — Hosted UI	✅	❓	❓	❌	❓	❌
Gemini — API	✅	❓	✅	✅	✅	❓
Grok (xAI) — Hosted UI	❓	❌	❓	❌	❓	❌
Grok (xAI) — API	✅	❓	✅	✅	✅	❓
Self-hosted / On-Prem LLMs (general class)	✅	✅	✅	✅	✅	✅
Meta Llama (Llama 2/3/4) — Self-host	✅	✅	✅	✅	✅	✅
Mistral (Mixtral / Large) — Self-host	✅	✅	✅	✅	✅	✅
Alibaba Qwen — Self-host	✅	✅	✅	✅	✅	✅
DeepSeek (R1 / V3) — Self-host	✅	✅	✅	✅	✅	✅
Google Gemma — Self-host	✅	✅	✅	✅	✅	✅
Microsoft Phi (Phi-2/3/4) — Self-host	✅	✅	✅	✅	✅	✅
IBM Granite — Self-host	✅	✅	✅	✅	✅	✅
Databricks DBRX — Self-host	✅	✅	✅	✅	✅	✅
NVIDIA Nemotron — Self-host	✅	✅	✅	✅	✅	✅
AI21 Jamba — Self-host (if weights available to you) / otherwise API	❓	❓	❓	❓	❓	❓
Cohere Command / Command-R — API	✅	❓	✅	✅	✅	❓
Falcon (TII) — Self-host	✅	✅	✅	✅	✅	✅
Yi (01-AI) — Self-host	✅	✅	✅	✅	✅	✅

---

VIII. V2 Delta Log (Cross-check against V1)

Expected delta (confirmed)

• ChatGPT (OpenAI) — Hosted UI: V1 all ✗ → V2 all ✅ (per curator-author re-test note).

Additional deltas discovered by go-to-market resurvey

• Claude (Anthropic) — Hosted UI, Durable Artefact Egress:

 V1 ✗ → V2 ✅
 Basis: vendor documentation now states Claude can create/edit downloadable files (e.g., spreadsheets, presentations, documents, PDFs) in conversation on paid plans.

• Gemini (Google) — Hosted UI, Durable Artefact Egress:

 V1 ✗ → V2 ❓
 Basis: vendor documentation supports exporting responses to Workspace targets (e.g., Google Docs). This is durable emission for certain outputs, but does not, on its own, establish general durable artefact emission as a guaranteed primitive across CM artefact forms; classified as conditional/limited pending explicit artefact-level guarantees.

All other cells carry forward from V1 (no regression evidence found; no speculative downgrades applied).

---