Processing Model

Processing Model

AEON processes documents through a strict pipeline of phases. Each phase has a single responsibility, limited authority, and a well-defined output.

The Pipeline

Text → Lexer → Parser → AES → AEOS (optional) → consumer-selected Tonic/materializer → Runtime

Phase	Input	Output	Authority
Lexer	Raw text	Tokens	Syntax only
Parser	Tokens	Assignment Event Stream (AES)	Structure and identity
AEOS	AES	Validation diagnostics	Form constraints
Consumer-selected Tonic/materializer	AES + validation	Runtime objects	Meaning and materialization

Phase 1: Lexer

The lexer tokenises raw AEON text. It classifies tokens and comment channel prefixes.

It guarantees: syntax is valid AEON.

It does not guarantee structure, validity, identity, or meaning.

Phase 2: Parser (AEON Core)

The parser consumes tokens and produces the Assignment Event Stream (AES). This is the core semantic output of AEON.

The parser enforces:

• canonical path assignment
• path uniqueness (no duplicate canonical paths)
• ordering
• reference legality (no forward or self-references)
• mode rules (transport, strict, custom)
• datatype annotation requirements per mode

AES preserves:

• canonical paths
• lexical order
• original value forms
• spans and provenance
• symbolic references (unresolved)

AES does not:

• resolve references
• coerce values
• materialize runtime objects

Phase 3: AEOS (Validation)

AEOS validates the form of the assignment stream against consumer-provided constraints.

It may check:

• required bindings
• literal kinds (e.g., "is this actually a StringLiteral?")
• structural constraints
• pattern constraints

It must not:

• coerce values
• resolve references
• inject defaults
• compute derived values
• interpret meaning

AEOS validates representations, not interpretations.

Example: validating that $.greeting is a string literal:

const schema = {
  rules: [
    { path: '$.greeting', constraints: { required: true, type: 'StringLiteral' } }
  ]
};

const result = validate(compile.events, schema);

Phase 4: Consumer-Selected Tonic or Materializer

A trusted, consumer-selected Tonic or materializer is the layer that may interpret meaning. It consumes AES, optionally after AEOS validation, and produces runtime objects.

A consumer-selected Tonic or materializer may:

• resolve references (clone and pointer)
• coerce values
• enforce domain rules
• construct runtime objects
• apply profile-specific transforms

A consumer-selected Tonic or materializer must:

• operate deterministically
• not mutate AES (AES is immutable)
• not override upstream failures

AES Immutability

This is the critical invariant. A consumer-selected Tonic or materializer may interpret AES however it needs:

AES: a:string = "0"
Tonic/materializer interprets: a as number 0
Runtime: a = 0 (materialized)

But a Tonic or materializer absolutely cannot rewrite AES:

AES: a:string = "0"
Tonic/materializer says: "Rewrite this to a:number = 0"
❌ Forbidden. AES is append-only and immutable.

This guarantees:

• original claims are permanently preserved
• interpretation is auditable
• determinism is maintained
• multiple interpretations can run against the same AES

Pre-Materialization Validation

A key practical benefit: validation happens before meaning is materialized.

Traditional parsers:

Input → Materialize → Consumer validates (too late)

AEON:

Input → AES (immutable) → AEOS validates form →
If valid: consumer-selected Tonic/materializer interprets → If invalid: reject before materialization

This means consumers can reject input at the validation layer without ever creating runtime objects.

Fail-Closed Behavior

Security-sensitive AEON systems should fail closed at every phase:

• Syntax failure → stop (no tokens)
• Structure failure → no AES
• Schema failure → no interpretation (by default)
• Tonic failure → no runtime output

No silent recovery into trusted output. No partial trust.

Why Single-Dimension Layers

Each phase verifies exactly one dimension of correctness:

• syntax is independent of structure
• structure is independent of validity
• form is independent of meaning
• meaning is independent of input claims

This prevents implicit trust escalation — no layer can upgrade trust without explicit authority. Systems that combine parsing, validation, and interpretation introduce hidden coupling where the system trusts conclusions it never explicitly proved.

Next Steps

• System Architecture — the philosophy behind the layer separation
• Security Model — how the pipeline serves as a security boundary
• Conformance & CTS — testing your implementation against the pipeline contract