Origins

EML-U — the original vision

EML formally splits into two profiles. EML-P is what is built and shipping today — see Docs and the Workbench. This page preserves EML-U: the original, broader idea EML-P was drawn from, and the direction future work may take.

Definition

What EML-U is

EML-U is EML’s complete original Profile: universal semantic attachment, high-density symbols, structural and intent compression, non-linear representation, cross-host and AI-native collaboration.

EML-P ⊆ EML-U. EML-P (see Docs) is EML-U’s stable, linear, low-ambiguity, engineered subset. Every EML-P program should have an EML-U semantic representation; EML-U can contain semantics EML-P does not support yet.

Current status: theory-preservation stage. Zero code, zero engineering directory. This page and the linked documents are the preservation work itself.

Original capabilities

What EML-U preserves

None of this is implemented. It is recorded here so it is not forgotten while EML-P keeps getting engineered.

Position & structure

Multi-position semantic attachment — upper-right, upper-left, lower-right, lower-left
Layers of meaning above and below the code
Two-dimensional syntax, non-linear reading order
Multi-layer symbols, structural folding

Semantic modeling

Semantic graphs
Intent nodes
Host-neutral Semantic IR

Cross-host & cross-media

Multi-host projection — one semantics, projected to Python / C++ / JS / natural-language explanation / Agent JSON
Natural-language attachment (e.g. “ship v1 next week” carrying deadline semantics)
Data-field attachment — unit, type, source, privacy, quality
Workflow-node attachment — retryable, idempotent, needs human review, risk, cost
Multimedia time/space attachment — audio, image, video timelines, 3D scenes, game worlds

AI-native

AI-adaptive display
Domain-specific semantic packages
Multiple reader-projections of the same semantics

Relation to EML-P

How EML-P and EML-U relate

The two profiles are not competing designs — one is the engineered projection of the other.

EML-P ⊆ EML-U — EML-P is a linear projection of EML-U.

Any EML-U structure downgrades through the projection function Π_P into one of three outcomes:

Fully expressible

Downgrades completely into EML-P.

Executable, not preservable

Becomes EML-P plus explicit metadata.

Unsafe to express

Marked unsupported — never silently dropped.

{
  "status": "partial_projection",
  "preserved": ["core_operation"],
  "metadata": ["confidence", "authority"],
  "unsupported": ["two_dimensional_branch"]
}

No silent loss: if EML-P cannot represent something EML-U expresses, the system must report it explicitly — never quietly leave only the surface code behind.

EML-U may understand, import, and generate EML-P. EML-P specs may never retroactively delete EML-U theory, and what EML-P’s parser happens to support today must never be read back as EML-U’s boundary.

Roadmap

EML-U’s own roadmap (U0–U4)

Separate from EML-P’s own roadmap (see Docs) and from the deeper source document’s system-wide migration steps — EML-U’s U-numbering is its own.

Phase	Name	Description	Status
U0	Theory preservation	Archive the original documents, build a version timeline, mark what is implemented vs. not.	partial
U1	Semantic ontology	Semantic ID, Anchor Model, Overlay Node, Projection, Policy, Provenance, Semantic Graph.	planned
U2	2D & multi-position syntax	Upper/lower semantic layers, two-dimensional flow, folding nodes, graph projection.	planned
U3	Cross-host	Code, natural language, tables, JSON, workflow, image, audio, video, game worlds.	planned
U4	AI-native interface	Agent semantic graph, intent compression, adaptive projection, semantic negotiation, human/AI dual view.	planned

EML-U engineering, when it starts, is meant to live in an independent experimental directory — not mixed into EML-P’s current packages.

Read the source

The normative documents

This page is a readable summary. These three documents are the actual source — read them before building anything on EML-U.