EMBER — Semantic Intent Language

EMBER is the artifact language of Project Phoenix. Extension: .sil — Semantic Intent Language

---

What EMBER Is

EMBER is the second DSL in the methodology-as-infrastructure family.

Where CAL is methodology-as-executor — a language that runs cascade analysis and produces decisions — EMBER is methodology-as-memory — a language that carries the artifacts of a transformation pipeline forward, across agents and humans, in a format both can read without a manual.

CAL     →  methodology becomes computation
            write it, something executes it, decisions emerge

EMBER   →  methodology becomes representation
            write it, agents and humans read it,
            the pipeline carries it forward as permanent state

Neither is more correct. They operate at different layers of the same pattern.

---

Why EMBER Exists

Project Phoenix extracts business logic from legacy systems and rebuilds them from zero in a modern stack. Seven agents run in sequence — each one producing artifacts the next agent reads.

Without a shared format, those artifacts are documents. Prose. Ambiguous. Lossy at every handoff.

EMBER makes every handoff typed. Every agent produces .sil files. Every agent reads .sil files. Humans read .sil files without a manual.

The name reflects what the language captures: the business logic that survives the legacy system — the ember from which the new system rises.

---

The Pattern Family

Both CAL and EMBER instantiate Methodology-as-Infrastructure — the concept that analytical frameworks can be compiled into deterministic infrastructure other systems build upon.

Property	CAL	EMBER
Domain	Cascade analysis	Legacy modernization
Execution	Runs — produces scores and alerts	Represents — carries artifacts forward
Layer	Runtime / executor	Memory / intermediate representation
Pipeline	6D → Sense → Analyze → Decide → Act	Phoenix → Extract → Synthesize → Build → Certify
Keywords	FORAGE DRIFT FETCH CHIRP ...	SIGNAL WORKFLOW SCREEN SPEC EPISODE
Output	Analysis scores, cascade maps, action alerts	Mission briefs, process traces, specs, certification

---

The Five Constructs

EMBER has five constructs. One file format. One header rule.

Every .sil file opens with:

CONSTRUCT  <type>
ID         <domain.name>
VERSION    <integer>
─────────────────────────────────────────

Everything below the separator is the construct body.

Construct	Produced by	Purpose
signal	A-00	Pre-forage knowledge unit — what to look for
workflow	A-01	Server-side trace — what the system does
screen	A-02	UI layer trace — what the user sees
spec	A-03	Semantic intent — what was meant
episode	any	Change record — what shifted and why

Full construct reference with examples: Constructs →

---

How the Constructs Chain

A-00  SIGNAL    →  tells each agent what to look for
A-01  WORKFLOW  →  server-side trace per business process
A-02  SCREEN    →  UI trace per workflow
A-03  SPEC      →  synthesizes WORKFLOW + SCREEN → intent
A-04            →  reads SPEC + _mission.sil → stack decision
A-05            →  reads SPEC + SCREEN → builds system
A-06            →  reads SPEC → certifies system
      EPISODE   →  any step can write one, all steps read open ones

---

What EMBER Is Not

• Not a programming language — nothing in a .sil file executes
• Not a schema language — no type enforcement, no validators
• Not documentation — a working artifact, not an explanation
• Not CAL — CAL computes. EMBER represents.

Both are methodology-as-infrastructure. Different layers. Different jobs.

---

CAL vs EMBER Side by Side

CAL script                          EMBER spec

FORAGE entities WHERE sound > 7     CONSTRUCT  spec
ACROSS D1, D2, D3, D5, D6          ID         cart.checkout
DEPTH 3                             VERSION    1
SURFACE cascade_map                 ─────────────────────────────
                                    intent:
DRIFT cascade_map                     Allow a customer to purchase
  METHODOLOGY 85                      and receive confirmation
  PERFORMANCE 35
FETCH cascade_map THRESHOLD 1000    rules:
ON EXECUTE CHIRP critical "Act now"   - Charge before order created
                                      - Promo before total

↓ executes → produces scores        ↓ read by agents → informs build

CAL tells the system what to decide. EMBER tells the system what was meant.

---

Relationship to Methodology-as-Infrastructure

EMBER is the second instantiation of the MaI concept:

Methodology-as-Infrastructure is the practice of encoding an analytical methodology into a deterministic, executable runtime layer that other systems can build upon.

EMBER extends this into the representation layer — methodology encoded not as execution but as typed, persistent, human-readable artifacts that carry intent forward across a multi-agent pipeline.

CAL proved the pattern works for analysis. EMBER proves it generalises to transformation.

---

Citation

@misc{shatny2026ember,
  author = {Shatny, Michael},
  title  = {EMBER: Semantic Intent Language for Project Phoenix},
  year   = {2026},
  publisher = {Zenodo},
  doi    = {10.5281/zenodo.18904231},
  note   = {ORCID: 0009-0006-2011-3258}
}

---

Related

• Constructs → — all five construct types with full examples
• File Structure → — how .sil files are organised on disk
• Runtime → — phoenix-runtime, the CLI that orchestrates the pipeline
• CAL — the sibling executor DSL — methodology-as-executor
• Methodology-as-Infrastructure — the concept both instantiate

---

EMBER v0.1 — Project Phoenix — 10.5281/zenodo.18904231