CEM-ML: Evolutionary Architecture for the Declarative Web Stack

[sashafirsov]

Declarative Amsterdam 2026 presentation introduction

Brief introduction

What if the languages and tools in a web application were not a tower of fixed,
unrelated standards, but an architecture able to evolve from shared declarative
contracts?

CEM-ML is the foundation of an open-source evolutionary architecture platform
for declarative web applications. It treats a language, its schema, its
transformations, and its presentation rules as related parts of one document
lifecycle. Instead of adding another hard-coded converter for every pair of
formats, CEM-ML lets schema packages describe how structured content is read,
validated, queried, transformed, formatted, and rendered.

The language is deliberately small and visual. Structure uses braces,
attributes use @, and | separates a node's header from its content:

@doc cem-ml 1
@ns cem = "https://cem.dev/ns/core/1"
@ns html = "http://www.w3.org/1999/xhtml"
@default html

{main @cem:screen=login |
    {h1 | Sign in}
    {form @cem:form=sign-in @method=post |
        {label @for=email | Email}
        {input @id=email @name=email @type=email @required}
        {button @type=submit | Sign in}
}   }

This is recognizable as a web document, but its meaning is not trapped in one
browser rendering step. During the tutorial, participants will change this
document, introduce and repair a validation error, inspect the resulting typed
structure and source-linked diagnostic, convert a second input format into the
same model, and transform the result into a working web view. One source stays
visible while its lifecycle expands.

That lifecycle is the platform's common semantic spine. CEM-ML currently reads
canonical CEM-ML and schema-packaged formats including CSV, JSON, YAML, CSS,
SCSS, Markdown, and the HTML/XML family. The same engine provides parsing,
validation, inspection, conversion, reporting, and transformation-graph
execution. Source mappings remain attached to the content, allowing a
diagnostic or generated result to be traced back to the bytes and transformation
that produced it.

The platform already applies this model beyond a command-line demonstration:

• The Rust cem_ml engine and its schema packages define the shared document
  lifecycle and compile to native and WebAssembly runtimes.
• CEM-QL supplies declarative queries, expressions, and templates over the same
  typed content rather than introducing an application-specific data model.
• The native CLI and synchronized browser/Node deployment projects expose the
  same operations to terminals, build systems, workers, and browser hosts.
• <cem-element> uses the browser runtime as a declarative, light-DOM component
  substrate: data, events, queries, and templates remain markup while the
  reusable runtime owns the necessary imperative machinery.
• Consumer Semantic Theme, CEM Components, CEM Studio, and CEM Site demonstrate
  how tokens, controls, a local-first workbench, and a static application can
  grow from that substrate rather than from framework-local UI behavior.

The architecture is evolutionary because those contracts are its DNA. A new
content type, schema version, query vocabulary, formatter, transform, component,
or host can join the lifecycle without redefining the whole stack. The platform
does not claim that every layer is finished: public CLI distribution is being
prepared, and the component catalog is actively migrating from compatibility
code to CEM-ML declarations. Those migrations are themselves useful evidence
for the central idea—the architecture is designed to replace and evolve its
parts while preserving shared semantics, diagnostics, and source identity.

Mini-tutorial journey

The proposed 60 minutes are organized around visible outcomes:

1. 0–7 minutes — Why evolve the stack? Start with the cost of disconnected
   formats, validators, build steps, component runtimes, and source mappings.
2. 7–17 minutes — Meet CEM-ML. Read and edit the small login document,
   covering only the syntax needed for the exercise.
3. 17–35 minutes — Ask the document questions. Validate it, inspect its
   structure, follow a source-linked error, and convert equivalent structured
   input through the same lifecycle.
4. 35–47 minutes — Turn data into an application view. Apply a declarative
   query/template transformation and render the result as light DOM.
5. 47–54 minutes — Reveal the platform. Connect the exercise to the CLI,
   WebAssembly runtime, <cem-element>, theme, components, Studio, and Site.
6. 54–60 minutes — What should evolve next? Discuss participant use cases
   and which languages, schemas, or application layers could join the model.

The goal is not for everyone to understand the implementation in one hour. It
is for participants to leave having seen and changed CEM-ML, having used its
core lifecycle, and having a concrete answer to the question: what becomes
possible when the declarative web stack is designed to evolve?

[sashafirsov]

Declarative Amsterdam 2026 — slide resources

Examples and supporting sources for the 30-slide session. The public Studio
route and selected workflows were verified on 3 November 2026.

• CEM demo site
• Declarative Amsterdam presentation slides
• CEM formats playground

Slide resources

All 30 physical slides are included below, in the current native deck order.
Slides 25 and 27–29 are optional references. Demonstration rows open ordinary
Studio projects, resources and configurations; reference rows link to the
supporting source or explanation. Slide 16 has separate query and expression
links. Clone a sample before editing. Stable IDs identify slides after reordering.

Slide	Stable slide ID	Demonstration or topic	Example or supporting reference
01	p1	CEM — DNA for structured data (reference)	Opening idea: DNA for structured data
02	h36c7c826c4eee100_0_0	CEM-ML — Declarative document lifecycle engine (reference)	Session brief and tutorial plan
03	p2	read	login: readme — read-edit
04	p3	Make capabilities reusable across systems (reference)	Reusable processing across formats and locations
05	p4	Keep useful rules as systems change (reference)	Supplier pipeline example
06	p5	Keep your markup knowledge (reference)	HTML Login source; CEM-ML Login source
07	p6	A small vocabulary for the whole journey (reference)	Namespace, nodes, attributes and content in Login
08	p7	edit	login: login-cem — validate
09	p8	Pick, extend, or create your own schemas (reference)	Schema package guide
10	p9	fail	login: login-invalid — validation-repair
11	p10	repair	login: login-invalid — validation-repair
12	p11	inspect	login: login-cem — inspect
13	p12	format	login: login-cem — format-pretty, format-tabular, source-colors
14	p13	compare	login: login-html — semantics-html, semantics-cem, html-conversion
15	p14	companion pipeline overview	Supplier transformation graph — availability
16	p15	query	login: login-cem — semantics-html-cemql, semantics-cem-cemql
16	p15	expression	login: login-expression — expression-html, expression-cem
17	p16	transform	login: login-view-graph — render-graph, render-html, render-cem
18	p17	source provenance	Login template and generated output — render-graph
19	p18	live	login: login-live-view — live-view
20	p19	Embedding applications (reference)	Provider and host responsibilities
21	p20	Find your place in the platform (reference)	Platform layers and implementation boundaries
22	p21	Put processing where the work happens (reference)	CLI, library and pipeline hosts
23	h209a9db50e1b8a77_0_0	Browser vs DCE security (reference)	DCE security promise and current limits
24	p22	Insulate each vendor’s contribution (reference)	Memory, Storage, CPU, Network, DOM and CSS scopes
25	p27	Six layers: foundations and boundaries (optional reference)	Six-layer foundations and enforcement gaps
26	p23	Make performance a lifecycle property (reference)	Lifecycle performance mechanisms and limits; Measured public startup
27	p28	Follow the source and the evidence (optional reference)	Local kit and frozen reference results (dated); Verified public workflow and exact build
28	p25	32 schema packages (optional reference)	Schema package catalog and capability limits; Package source guide
29	p26	Reuse expertise within explicit profiles (optional reference)	XSLT runtime profile; Native, Node and browser deployment contracts
30	p24	supplier	supplier-pipeline: supplier-stock — stock-source, availability

Examples already shared in this discussion

These original examples remain available alongside the guided Studio route:

• Slide 03: Login form CEM-ML
• Slide 04: 7e. Embedded XSLT fragment
• Slide 04 source: XSLT template fragment
• Slide 05: schema packages
• Slide 08: Hello, CEM-ML

Playground links prefill the source and formats; choose Render to produce
the preview.

The fragment-library link uses ordinary HTTPS so it opens from GitHub; use the
browser's View source action to inspect its markup.

Use checked-in or disposable example data. Do not enter real credentials.
Entered passwords or one-time codes block recovery until explicitly cleared;
they must never be exported. The Login view demonstrates local interaction,
not authentication or a credential service. Security and performance references
state their supported profiles and remaining boundaries.

The local kit and saved reference index documents the dated local-transfer fallback.
The public demo verification record
records the deployed build and successful public acceptance. Source references
are pinned to bc51404e; the separate kit instructions retain their recorded
host and installation limits. The native deck remains the slide-order authority.