AEON makes meaning visible before it becomes authority.

AEON is designed around a simple security-minded idea: a document may declare structure, types, references, contracts, and intent, but it does not get to prove those claims about itself. Consumers bring the trusted contract.

That is the deeper reason for the language’s visible shape. AEON preserves what was written, avoids implicit parser decisions, validates before materializing meaning, and keeps each processing layer honest about what it is allowed to know.

AEON separates representation from interpretation. A value can be syntactically valid, structurally valid, and still fail domain meaning. For example, 0 may be a valid number but an invalid temperature reading if the consumer requires a unit.

The point is not to eliminate meaning. The point is to prevent implicit, invisible, uncontrolled decisions about meaning.

temperature:number = 0 // celcius, fahrenheit ?
---
temperature@{unit:string = "celsius"}:number = 0
---
temperature@{unit:string = "fahrenheit"}:number = 32

AEON’s processing model is deliberately layered. The lexer handles syntax. AEON Core produces the Assignment Event Stream. AEOS validates form. A Tonic may materialize meaning only after those earlier boundaries have held.

This keeps validation separate from execution and processing. No layer is allowed to quietly upgrade trust by doing work that belongs to another layer.

bytes → tokens → AES → AEOS → Tonic → runtime

Many parsers effectively read text and materialize application objects in one move. AEON splits that path. The pre-parse boundary controls bytes and sizes before syntax is trusted. The lexer only recognizes syntax and advances without backtracking traps. The parser builds structure and paths without creating domain objects. AES records what was assigned. AEOS checks shape without silently mutating values or typecasting them. Only after those checks can a trusted Tonic materialize references and runtime objects, with limits in place for oversized graphs or memory-heavy reference expansion.

That split gives the consumer control over what the parser should accept, what should fail, and which later stages are allowed for the current context. A public upload, a signed internal document, and a local authoring draft can all use different acceptance boundaries without asking the document to secure itself.

pre-parse → byte limits, encoding checks, size controls
lexer     → syntax tokens, one pass, no backtracking traps
parser    → structure and paths, no runtime objects
AES       → ordered assignment events
AEOS      → validation, no mutation or typecasting
Tonic     → trusted materialization after limits and policy

Headers, contracts, profiles, schema declarations, and datatype labels are claims. They are useful claims, but they are not self-authenticating. A consumer verifies those claims against its own trusted registry, schema, profile, or policy.

This is AEON’s zero-trust posture: the document can ask to be interpreted a certain way, but it must never select its own trusted execution surface.

Every verification check — against a registry, against a schema, against a policy — happens outside the document and under consumer authority. The document presents; the consumer decides.

aeon:contracts = [
  "example.weather.v1"
]

temperature:number = 0

AEON keeps similar-looking values distinct until a trusted consumer decides what to do with them. Strings that look numeric, switches that read like words, and booleans that carry truth values are not collapsed into one vague space.

That restraint is practical security: validation can reject input before runtime objects exist, and audit tools can inspect what was claimed without first accepting what it means.

amount:string = "0"
amount:number = 0
approved:switch = no
verified:boolean = false

YAML has the classic Norway problem: a value such as NO may be read as a boolean instead of a country code. JSON permits duplicate object keys, which leaves consumers to decide whether first key, last key, or error wins. CSV relies on tools that often infer dates, numbers, and identifiers differently. XML preserves structure, but most values arrive as strings until conventions or schemas give them stronger meaning.

AEON sidesteps these problems by keeping each claim explicit. A country code is a string. A toggle is a switch. A duplicate key is an error rather than a mystery. A date is a date. A number-looking identifier can stay a string. A value like 7_000 is explicitly seven thousand rather than a locale-dependent spreadsheet guess. When a consumer needs stronger guarantees, AEOS can validate the assignment stream before anything becomes a runtime object.

//# YAML Norway problem: "NO" can become false.
countryCode:string = "NO"
decision:switch = no

//# JSON duplicate keys: consumers disagree on the winner.
id:string = "invoice-100"
id:string = "invoice-099" // duplicate key; AEON rejects this

//# CSV spreadsheet inference: values become dates or numbers.
sku:string = "00123"
shipDate:date = 2026-05-05
attendees:number = 7_000

//# XML conventions: text needs external typing rules.
quantity:number = 12
quantityText:string = "12"

AEON distinguishes source text, accepted assignment events, canonical form, and Tonic materialization. Author intent stays visible through parsing and validation; canonicalization gives tools a stable representation only after the consumer has chosen the rules it trusts.

That stable form is what makes cryptographic signing, tamper hashes, and encryption practical. A signer can hash the canonical stream instead of whatever whitespace, ordering, or editor formatting happened to be present in the source, while a Tonic can still materialize richer runtime objects later.

document:object={
  title:string="Release notes"
  total:number=7_000

  //? First names only
  authors:list=[
    "Bob"
    "Alice"
  ]
}
signature:envelope={
  algorithm:string="ed25519"
  keyId:string="example.publisher.2026"
  value:base64=$MEUCIQDx
}

A canonical representation can then normalize spacing, ordering, and numeric spelling for stable hashing while keeping the accepted values and envelope explicit.

aeon:header = {
  encoding = "utf-8"
  mode = "transport"
  profile = "core"
  version = "1.0"
}
document:object = {
  authors:list = ["Bob", "Alice"]
  title:string = "Release notes"
  total:number = 7000
}
signature:envelope = {
  algorithm:string = "ed25519"
  keyId:string = "example.publisher.2026"
  value:base64 = $MEUCIQDx
}