AEON v1 Value Types Reference

Scope: complete value-kind reference for AEON Core v1, aligned to current TypeScript parser/AES implementation.

1. Binding Forms

All values are bound as:

Transport vs typed-mode example:

contact = "John"
contact:string = "John"

Mode requirements:

• transport allows untyped non-header bindings and allows custom datatype labels;

• strict requires a datatype annotation on non-header bindings and rejects custom datatype labels by default;

• custom requires a datatype annotation on non-header bindings and allows custom datatype labels;

• typed modes require datatype annotations on attribute entries that carry values;

• typed modes do not require generic args (arr:list = [...] is valid);

• typed modes do not require datatype clarifiers. Clarifiers are preserved datatype claims whose interpretation belongs to profiles, schemas, or consumers.

• typed modes do not require datatype annotations on anonymous list elements, tuple elements, or node children.

Implementations MAY still expose an explicit datatype-policy override, but the default semantic behavior is mode-driven.

Reserved datatype names in Core are compatibility labels, not full semantic contracts.

The datatype label zdt is reserved for a possible future zoned datetime type. It is not operational in AEON Core v1, is not an accepted Core v1 datatype family, and does not introduce bracketed zoned-datetime lexical syntax in v1.

Anonymous values inside list, tuple, and node-child containers MAY carry a local datatype annotation:

values:list = [:int32 = 3, :string = "4"]
pair:tuple = (:float64 = 10.5, :float64 = 2.0)
page:node = <page(:string = "hello", <tag>, :int32 = 3)>

This form is an annotation on an immediate anonymous value, not a binding. It is therefore invalid at document root, invalid inside objects where keyed bindings are required, and invalid when nested as another anonymous typed value:

:n = 3                  // invalid: no container element context
a:object = { :n = 3 }   // invalid: objects require keyed bindings
a:list = [:n = :n = 3]  // invalid: typed value cannot wrap another typed value

Container typing and anonymous value typing are not equivalent. numbers:list<int32> = [1, 2, 3] declares an expectation on the container binding, while values:list = [:int32 = 3, :string = "4"] annotates individual anonymous elements without changing their order or making them named bindings.

In particular:

• Core recognizes reserved names such as int, uint, int32, float64, obj, envelope, trimtick, prose, sep, kadot, symbol, and sansa;

• Core checks literal-family compatibility only;

• stronger semantic enforcement such as integer-only, unsigned-only, width, or range belongs to profile/schema validation layers;

• aeon.gp.profile.v1 and aeon.gp.schema.v1 are the intended general-purpose baseline for making those stronger meanings operational.

1.1 Reserved Datatype Name Table

This section lists the accepted datatype-name families used by Core v1.

Future-reserved labels, including zdt, are intentionally excluded from this table.

Interpretation:

• Type is the canonical name used in examples and docs;

• Alternative names are short aliases;

• Reserved are other accepted reserved compatibility names in the same family.

string

trimtick

prose is a reserved compatibility label for formatted trimtick text, such as Markdown or other application-level prose formats. Core treats prose as the same literal family as trimtick; richer format semantics belong to profiles or application contracts.

number

infinity

nan

boolean

toggle

hex

radix

encoding

date

time

datetime

sep

symbol

sansa

sansa is the reserved datatype label for SANSA address literals. SANSA means Semantic Address NameSpace Abstraction. In strict mode, SANSA address literal values are written with the :sansa datatype annotation. Core validates and preserves the accepted literal surface; resolution, selector expansion, authorization, and qualifier meaning belong to consumers.

object

list

tuple

node

null

2. Value Kind Catalog

3. Literal Details

3.1 String

Examples:

name = "John"
alias = 'J'
multiline = `Hello
World`

Escape sequences for quoted strings (" and '):

• \\, \", \', `\ ``

• \n, \r, \t, \b, \f

• \uXXXX

• \u{X...} (1-6 hex digits, max 10FFFF)

Nuances:

• backtick strings are raw strings and may span multiple lines;

• non-backtick strings cannot contain raw newline;

• quoted Unicode escapes must decode to valid Unicode scalar values;

• \uXXXX high-surrogate forms are legal only when immediately followed by a valid \uXXXX low-surrogate form in the same decoded sequence;

• lone high-surrogate and lone low-surrogate escapes are illegal;

• malformed braced Unicode escapes, incomplete Unicode escapes, non-hex escape payloads, and out-of-range code points are illegal;

• invalid escapes fail closed with deterministic invalid-escape diagnostics.

Examples:

ok1 = "\u0041"
ok2 = "\u{41}"
ok3 = "\uD83D\uDE00"

bad1 = "\uD800"
bad2 = "\uDC00"
bad3 = "\u{"
bad4 = "\u{110000}"
bad5 = "line1
line2"

Canonical notes:

• ordinary strings canonically emit as double-quoted strings with minimal escaping;

• decoded line breaks in ordinary strings emit as escapes such as \n rather than changing the value to the trimtick literal family;

• canonicalization preserves the ordinary-string versus trimtick literal-family boundary.

AES:

• StringLiteral with value, raw, and delimiter.

3.2 Trimtick

Trimticks are a distinct multiline string form.

They still produce StringLiteral values in AES, but unlike ordinary strings they apply an explicit trimming step to the raw backtick payload. Because of that, they are documented separately here instead of being treated as just another spelling of string.

Examples:

note:trimtick = >`
  one
  two
`

note:trimtick = >`
    one
  two
`

body:prose = >`
  # Title

  Markdown-ish content.
`

Syntax:

• trimticks start with a single > marker;

• the marker must be followed by a backtick string opener;

• spaces between the marker and the backtick opener are accepted;

• repeated markers such as >>, >>>, and >>>> are invalid.

Trimming rules:

• trim the first empty line after the opener, if present;

• trim trailing empty lines before the closer;

• normalize whitespace-only interior lines to empty lines and exclude them from gutter analysis;

• determine the gutter character from the first nonblank line: TAB when that line begins with U+0009 TAB, otherwise SPACE;

• measure each nonblank line's gutter depth as its initial run of the gutter character;

• an unindented line or a line beginning with the other whitespace character has depth 0;

• the other whitespace character after a non-empty gutter run terminates the run and remains payload;

• remove the minimum gutter depth from every nonblank line;

• preserve trailing whitespace on nonblank lines;

• preserve interior blank lines as blank lines;

• if all remaining lines are empty, the resulting value is the empty string.

Gutter policy:

• U+0020 SPACE and U+0009 TAB are compared as exact code points;

• tabs are never assigned a visual width or converted to spaces during parsing;

• mixed source indentation is valid and may reduce the common gutter depth to zero;

• source-aware linters may warn about suspicious alignment, but indentation style is not a Core validity rule.

Single-line trimticks are valid and behave like ordinary raw backtick content, because there is no multiline gutter to remove.

Canonical notes:

• canonical output always preserves the trimtick literal family;

• one-line trimticks canonically use the compact > plus backtick form, including inside inline containers;

• multiline trimticks use spaces-only canonical gutters when the enclosing layout permits a multiline block;

• canonical output normalizes a multiline block's indentation gutter to spaces only;

• multiline trimticks rendered inside inline object or attribute forms remain trimticks and escape their line breaks within the compact form.

AES:

• StringLiteral; source-aware parser metadata may preserve the raw trimtick payload, but no marker-width field exists.

3.3 Number

Examples:

count = 42
ratio = 3.14e-2
half = .5
large = 1_000_000

Nuances:

• underscore separators are accepted only between digits and normalized in parsed numeric value;

• leading-dot decimals such as .5, -.5, and +.5 are accepted;

• invalid underscore forms include leading (_100), trailing (100_), consecutive (100__000), and adjacency to non-digits;

• numeric width/precision are not core-level semantics.

Canonical notes:

• underscore separators removed;

• canonicalization of :number values is value-normalizing while preserving the broad representation family (integer, decimal, exponent);

• leading-dot decimals normalize to an explicit zero (.5 → 0.5, -.5 → -0.5);

• decimal-family values trim redundant trailing fractional zeroes, but retain at least one fractional digit (10.00 → 10.0);

• exponent-family values normalize to lowercase e and trim redundant exponent sign and leading exponent zeroes (1.0E+03 → 1e3);

• zero follows the same family rule rather than a one-off special case: integer zero canonically emits as 0/-0, decimal zero as 0.0/-0.0, and exponent zero as 0e0/-0e0.

AES:

• NumberLiteral (value normalized, raw preserved).

• NumberLiteral is finite-only.

Underscore examples:

n1 = 100_000      // valid
n2 = _100_000     // invalid
n3 = 100__000     // invalid
n4 = 100_000_     // invalid

3.3.1 Infinity

Examples:

top = Infinity
bottom = -Infinity
ceiling:infinity = Infinity
floor:infinity = -Infinity
limit:infinity<speedofmass> = Infinity

Nuances:

• InfinityLiteral is a distinct literal family from NumberLiteral;

• infinity<T> is a non-finite domain claim: Core preserves the parameter and treats the value as an infinity literal, while schema, profile, or consumer validation may interpret the claimed domain;

• accepted surface forms are exactly Infinity and -Infinity;

• +Infinity, NaN, -NaN, +NaN, inf, and lowercase aliases are invalid;

• explicit :infinity compatibility is enforced in all modes;

• :number remains finite-only and rejects InfinityLiteral.

Canonical notes:

• canonical output preserves Infinity and -Infinity exactly;

• invalid spellings have no canonical form.

AES:

• InfinityLiteral with value and raw equal to Infinity or -Infinity.

3.3.2 NaN

Examples:

bad = NaN
signed = -NaN
badValue:nan = NaN
signedValue:nan = -NaN
badReading:nan<number> = NaN

Nuances:

• NaNLiteral is a distinct literal family from NumberLiteral;

• nan<T> is a non-finite domain claim: Core preserves the parameter and treats the value as a NaN literal, while schema, profile, or consumer validation may interpret the claimed domain;

• accepted surface forms are exactly NaN and -NaN;

• +NaN, Infinity, -Infinity, lowercase aliases, and shorthand forms are invalid;

• explicit :nan compatibility is enforced in all modes;

• :number remains finite-only and rejects NaNLiteral.

Canonical notes:

• canonical output preserves NaN and -NaN exactly;

• invalid spellings have no canonical form.

AES:

• NaNLiteral with value and raw equal to NaN or -NaN.

3.3.3 Null

Examples:

missing = !none
state = !notSet
deleted = !tombstone
reservationDate:null = !"postponed"
nextRetry:null<datetime> = !none

Nuances:

• NullLiteral is a distinct literal family from StringLiteral and NumberLiteral;

• null<T> is an absence-domain claim: Core preserves the parameter and treats the value as a null literal, while schema, profile, or consumer validation may interpret the absent value's expected domain;

• reserved sentinel forms are exactly !none, !notSet, !notApplicable, and !tombstone;

• custom null reasons must use a quoted string form after !;

• implementation-specific null distinctions should use quoted custom reasons such as !"js.undefined" rather than a separate null convention;

• quoted custom reasons must decode to a non-empty, non-ASCII-whitespace-only string;

• quoted custom reasons must not decode to any reserved null sentinel name;

• collision checks are performed on decoded strings without Unicode normalization;

• explicit :null compatibility is enforced in all modes.

Canonical notes:

• reserved sentinels preserve their exact spellings;

• quoted custom reasons canonicalize using ordinary AEON string canonicalization after !;

• canonicalization must not rewrite reserved sentinels into quoted reasons or vice versa.

AES:

• NullLiteral with mode, value, and raw.

3.4 Boolean

Examples:

enabled = true         // valid boolean literal
visible = false        // valid boolean literal   
show = TRUE            // invalid as boolean literal (not a boolean token)
activate = 'true'      // valid AEON, but string literal (not boolean)
pass = 1               // valid AEON, but number literal (not boolean)

Nuances:

• lowercase true/false keywords.

• explicit :boolean compatibility is enforced in both transport and strict.

Canonical notes:

• Canonical boolean tokens are lowercase true and false.

AES:

• BooleanLiteral.

3.5 Toggle

Examples:

state = on             // valid toggle literal
state:toggle = off     // valid toggle literal
state:toggle = true    // invalid

Nuances:

• lexical forms: yes, no, on, off;

• untyped toggle literals are allowed in transport mode;

• in strict mode, untyped toggle literals must be annotated with :toggle;

• machine-readable surfaced ToggleLiteral.value remains lexical (yes, no, on, off);

• finalized JSON materializes toggle literals as booleans.

AES:

• ToggleLiteral.

3.6 Hex

Examples:

color = #ff00aa
color:hex = #ff00aa

Nuances:

• parsed as hex literal payload without # in value;

• surfaced machine-readable value is the payload-only form, while raw preserves the original sigiled source token;

• _ is visual spacing only and is valid only between hex digits;

• leading, trailing, and consecutive _ forms are invalid;

• HexLiteral is distinct from RadixLiteral. #ff is not the same literal family as %ff, even when a radix profile or datatype annotation uses base 16;

• Core does not assign color, byte-array, identifier, numeric, or hash semantics to hex values; those meanings belong to profiles, schemas, or consumers.

AES:

• HexLiteral.

3.7 Radix

Examples:

bits = %1011
bits:radix[2] = %1011

Nuances:

• payload captured without %.

• radix literals are number-like rather than encoding-like;

• radix[base] is informative metadata rather than a generic type parameter;

• optional radix base metadata uses datatype clarifier syntax, for example radix[2], radix[10], or radix[16];

• Core syntax accepts numeric clarifier values and preserves them; profile/schema layers decide whether a numeric clarifier is a meaningful radix base;

• aeon.gp.profile.v1 requires exactly one integral numeric clarifier from 2 through 64 when radix carries an explicit base, and rejects string, empty, multiple, fractional, or out-of-range radix clarifiers;

• spaces around the radix base inside brackets are allowed in AEON source, but the integer itself must be contiguous;

• radix base forms with leading zeroes, non-decimal payloads, empty brackets, repeated bracket lists, or values outside 2..64 are invalid when a GP/AEOS layer activates radix-base semantics;

• decimal is a reserved alias for radix[10];

• reserved aliases such as radix2, radix6, radix8, and radix12 remain accepted as shorthand;

• optional leading sign + or - is allowed only once at the start of the payload;

• radix payload digits are 0-9, A-Z, a-z, &, and ! in that order;

• . is an optional radix decimal point and may appear at most once;

• radix decimals may omit the integer part when there is at least one radix digit after the dot (for example %.3, %-.3, %+.1);

• if present, the radix decimal point must still be followed by at least one radix digit;

• _ is visual spacing only and is valid only between radix digits;

• radix payload leading zeroes are allowed and preserved as part of the represented digit sequence (for example %00100101);

• / and = are not valid radix payload characters;

• lexical acceptance is not base-specific radix validity;

• base-specific digit checks still belong downstream for implementation/profile/schema enforcement;

• generic forms such as radix<2> are invalid; radix base metadata uses brackets.

• radix16 is not a reserved Core v1 shorthand. Use radix[16] for radix-family base-16 values.

• radix[16] remains distinct from hex; it produces RadixLiteral, while hex produces HexLiteral.

Canonical notes:

• canonicalization of :radix[...] values is representation-preserving rather than value-normalizing;

• _ separators are removed from canonical radix output;

• the remaining digit sequence, decimal-point placement, and leading-zero width are otherwise preserved.

AES:

• RadixLiteral.

3.8 Encoding

Examples:

payload = &QmFzZTY0IQ==
payload:base64 = &QmFzZTY0IQ==
code:encoding["base58"] = &FFF
payload:embed = &QmFzZTY0IQ==
payload:inline = &QmFzZTY0IQ==

Nuances:

• encoding literals use & as the literal prefix;

• payload captured without &;

• encoding, base64, embed, and inline all bind to the same EncodingLiteral family in Core v1;

• encoding/base64 payload accepts the Base64URL alphabet (A-Za-z0-9-_) with optional trailing = padding;

• standard base64 alphabet characters + and / are invalid in AEON encoding/base64 payloads;

• canonical encoding/base64 rendering preserves the accepted Base64URL payload spelling, including trailing = padding;

• lexical acceptance is not encoding-family validity;

• encoding does not always mean decoded Base64 data. Core preserves an encoded lexical payload; decoding, byte identity, media type, and text interpretation belong to profiles, schemas, or consumers;

• aeon.gp.profile.v1 allows encoding, inline, and embed to carry exactly one string clarifier as an encoding-name claim, for example encoding["base58"];

• base64 is an encoding-family compatibility label, not a radix-family label. base64 is not equivalent to radix[64];

• embed and inline are reserved compatibility labels over the same EncodingLiteral family; Core does not assign media, resource-loading, or inline-expansion behavior to them;

• Aeonic Semantic Language may define naïve payload order over the preserved encoded payload characters, but decoded-byte ordering, decoded-text ordering, media ordering, or hash ordering belongs to profiles, schemas, or consumers;

• a = &aa= is unambiguous in current lexer, because the second = remains part of the encoding token rather than being reinterpreted as assignment.

AES:

• EncodingLiteral.

3.9 Date / Time / DateTime / WTC

Examples:

year:date = 2025-
month:date = 2025-01
start:date = 2025-01-01
at:time = 09:30:00
utc:time = 09:30:00Z
local:time = 09:30:00+02:40
ts:datetime = 2025-01-01T09:30:00Z
yearTick:datetime = 2025-T09:30
monthTick:wtc = 2025-01T09:30&Australia/Sydney
z:wtc = 2025-01-01T00:00:00Z&Australia/Sydney
localTime:wtc = 2025-01-01T00:00:00&local         // resolver-local temporal context
subscriptionEnd:wtc = 2027-01-31T23:59:59&local  // late-bound civil deadline
geoTime:wtc = 2035-01-01T09:00&-36.7590183/144.2826718
coordinatedTime:wtc = 2026-01-01T09:10:10&UTC
atomicTime:wtc = 2026-01-01T09:10:10&TAI
earthRotationTime:wtc = 2026-01-01T09:10:10&UT1
terrestrialTime:wtc = 2026-01-01T09:10:10&TT
gpsTime:wtc = 2026-01-01T09:10:10&GPS
namedPlace:wtc = 2026-01-01T09:10:00+01:00&+/Antarctica/Elisabeth

Nuances:

• parser emits DateLiteral for date-only token;

• date admits year-, month-, and day-granularity forms as YYYY-, YYYY-MM, and YYYY-MM-DD; the trailing hyphen distinguishes a year date from an ordinary number;

• omitted month or day fields remain unasserted and are not silently replaced with 01; the same year-, month-, and day-granularity date ticks may appear before T in datetime and WTC values;

• parser emits DateTimeLiteral for time, datetime, and WTC tokens; the wtc datatype and preserved &temporal-context payload distinguish WTC without changing the parser value model;

• standalone time is part of Core v1 and follows ISO 8601 time forms;

• date, time, and datetime literal recognition includes intrinsic calendar/clock range validation;

• zone suffixes (Z, +hh:mm, -hh:mm) may attach to valid reduced-precision time forms already admitted by Core v1, such as 09: and 09:30;

• numeric offsets contain hours and minutes only. Second-level numeric offsets are not Core syntax; historical resolution requiring sub-minute offsets uses an applicable named-zone ruleset or other downstream reference data;

• datetime composes any valid date tick with the reduced-precision clock forms after T, so forms such as 2025-T09:30, 2025-01T09Z, 2025-01-01T09+02:00, and 2025-01-01T09:30Z are valid;

• WTC extends the same reduced-precision datetime bases with a temporal context suffix, so forms such as 2025-T09:30&Europe, 2025-01T09&Europe/Belgium/Brussels, 2025-01-01T09Z&Europe/Belgium/Brussels, 2025-01-01T09:30Z&local, and 2035-01-01T09:00&-36.7590183/144.2826718 are valid wtc literals;

• WTC temporal contexts may contain /, _, -, +, and . when used as part of a contiguous context, so named timezones such as America/Port-au-Prince, GB-Eire, Etc/GMT-1, and Etc/GMT+1, plus geographic positions such as -36.7590183/144.2826718, are valid context payloads;

• comment markers do not begin inside a contiguous WTC temporal-context payload; forms such as Europe//Brussels and Europe/*Brussels*/ are invalid context payloads, not shortened values followed by comments;

• uppercase Z is the Core v1 UTC marker form; lowercase z is not a temporal literal marker;

• invalid ranges such as 2025-13-40, 2025-02-29, 24:00, and 99:99 are not temporal literals in Core v1; second 60 remains structurally preservable in Core and is rejected by the general-purpose schema;

• strict datatype compatibility treats :time and :datetime as ordinary DateTimeLiteral-compatible forms and requires :wtc to be a DateTimeLiteral carrying a valid &temporal-context payload;

• the reserved resolver-local temporal context is exactly lowercase local (for example 2025-01-01T00:00:00&local); case variants such as Local and LOCAL are invalid rather than aliases;

• WTC preserves three temporal-value forms: unqualified values without an offset designator, offset-qualified values with an explicit numeric UTC offset, and UTC-qualified values with Z; a complete date-time with Z or a known offset can identify an instant, while reduced-precision and time-only forms retain missing context, and all forms remain lexically distinct;

• the exact spelling -00:00 remains a preserved offset-qualified Core form. Under aeon.gp.temporal.v1 it means that the local offset is unknown or unspecified, does not identify an instant from the offset alone, and MUST NOT be normalized to Z or +00:00;

• the temporal context is independent of the temporal-value form and may be local, a named timezone, a convention-defined named place beginning with +/, a timescale, or a geographic position; &local selects resolver-local rules while a named timezone selects an explicit ruleset, and either can supply context for zoned civil time;

• Core treats &+/Antarctica/Elisabeth as an ordinary preserved WTC context. The aeon.gp.temporal.v1 convention assigns exact leading +/ the meaning "named place", permanently distinguishing it from the unprefixed named context &Antarctica/Elisabeth;

• &local is late-bound rather than a fixed timezone. With an unqualified temporal value, it can describe a context-indexed family of instants: for example, 2027-01-31T23:59:59&local may resolve to just before midnight in each subject's applicable timezone. With a known-offset or UTC-qualified value, the instant is already fixed and &local supplies additional local context rather than making it float. In particular, 2027-01-31T23:59:59Z&local has the same instant as 2027-01-31T23:59:59Z; it does not first read the clock fields as local civil time;

• strings such as UTC, TAI, UT1, TT, and GPS are accepted and preserved by Core as ordinary named temporal contexts. The aeon.gp.temporal.v1 convention recognizes their timescale meaning and defines a separate timescale attribute; Core itself does not resolve or convert timescales;

• combinations such as 2026-01-01T09:10:10Z&TAI and 2026-01-01T09:10:10+01:00&TAI are therefore structurally preservable Core values. Their UTC-relative and TAI claims are incompatible under aeon.gp.temporal.v1 and are rejected by its general-purpose schema or a convention-aware downstream validator, not by parser dispatch;

• under that convention, -00:00 takes precedence over inferring a known offset from a named-zone context. 2026-01-01T09:10:10-00:00&Australia/Melbourne remains an unknown-offset claim and does not become an exact instant merely because the named zone is recognized;

• geographic temporal contexts use latitude/longitude or latitude/longitude/height component order. Core recognises and preserves the context but does not validate coordinate ranges, select a civil-time jurisdiction, or perform geodetic resolution;

• unless an active convention or profile overrides the interpretation, geographic WTC references use WGS 84 latitude and longitude in decimal degrees, in explicit latitude/longitude axis order, with an optional ellipsoidal height in metres;

• parsers, canonicalizers, and preservation-only processors MUST preserve the authored temporal-value form and temporal-context payload rather than resolving or rewriting them;

• WTC is represented as DateTime token family in AST/AES.

Core preserves reduced precision and does not silently insert missing calendar or clock fields. Under aeon.gp.temporal.v1, omitted fields define completion sets: 2025- contains 2025-01, 2025-01 contains 2025-01-01, 2025-T10:10 contains compatible month/day coordinates, and 10:Z contains 10:30Z. Containment is not equality or chronological precedence. A time-only form lacks a date even when it carries Z or a known offset.

Once seconds are present, omission of a fractional part means fractional value zero. This is distinct from an omitted minute or second field and preserves ordinary whole-second semantics. Core preserves one or more authored fractional digits without a universal precision ceiling. The general-purpose schema admits at most nine digits, including trailing zeroes, through temporal_max_fraction_digits.

AES:

• DateLiteral or DateTimeLiteral.

3.9.1 Year Range and Future Expansion

Core v1 date-bearing temporal literals use exactly four unsigned year digits. Negative years, signed years, and expanded years beyond 9999 are not Core v1 syntax.

Expanded-year support remains an explicit future Core requirement rather than an abandoned proposal detail, but it is not part of the planned 0.14.0 implementation line. The future revision that introduces expanded years will select its exact width and ordering rules at that compatibility boundary. It MUST NOT reinterpret an existing four-digit year token or introduce a second spelling for an already representable four-digit year.

The planned 0.14.0 temporal grammar remains exactly four digits, begins at 0001, and excludes year 0000, negative years, BCE dates, and years beyond 9999. Because current recognizers may admit 0000, that restriction is a compatibility change. The specification maintainers MUST retain the future expanded-year requirement, or replace it with an adopted successor specification and migration path, before removing any associated proposal document.

3.10 Separator Literal (^...)

Examples:

size:sep["x"] = ^300x250
dimensions:sep["w", "h", "d"] = ^300w400h200d
semver:kadot = ^3.14.15
ip1:sep = ^127.0.0.1
ip2:sep["."] = ^127.0.0.1
parts:sep["|"] = ^"hello world"|"this, [is] fine"
psv:sep["|"] = ^"id"|"name"|"phone"

Datatype clarifier grammar:

Clarifier rules (implementation-aligned):

• a datatype may carry at most one clarifier list;

• a clarifier list contains one or more string or numeric values;

• separator characters are string clarifiers, for example sep["x"];

• radix bases are numeric clarifiers, for example radix[16];

• repeated bracket lists such as sep["x"]["y"] are invalid;

• type-specific meaning and compatibility belong to profiles and AEOS.

Depth/policy:

• parser option maxSeparatorDepth (core option maxSeparatorDepth);

• default lock: 1;

• capability floor target: up to 8 via policy configuration.

Payload grammar:

• separator payload begins immediately after ^ and is read as one or more contiguous segments;

• each segment is either a raw segment or an ordinary quoted string segment;

• raw segments may use only A-Z, a-z, 0-9, and ! # $ % & * + - . : ; = ? @ ^ _ | ~ < >;

• quoted segments use ordinary AEON single-quoted or double-quoted string lexical rules;

• backtick strings are not valid separator segments;

• no raw separator escapes are defined;

• outside quoted segments, whitespace, \\, /, ,, and closing container boundaries are not payload characters;

• comment syntax resumes normally once a separator payload ends outside quoted segments.

• :sep may bind separator literals with or without explicit clarifiers.

• :kadot may bind unparameterized separator literals. The intended kadot shape is dot-separated numeric segments, for example ip:kadot = ^198.0.126.255 or semver:kadot = ^3.14.15, but Core only enforces the separator-literal family; stricter shape validation belongs to schema/profile layers.

• Core does not assign IP, semantic-version, dimension, table, product-code, or other domain meaning to separator literals.

• Aeonic Semantic Language may define naïve separator order over the canonical separator payload. Naïve order does not split payloads, even when datatype clarifiers such as ["."] are present.

• Domain ordering such as version order, numeric IP address order, or aspect-ratio order belongs to profiles, schemas, or consumers.

• Datatype clarifiers are preserved claims. aeon.gp.profile.v1 declares the GP interpretation of sep/separator string clarifiers as separator characters and rejects non-string separator clarifiers. Datatypes without an active GP clarifier rule, or GP entries with clarifiers = "none", do not accept explicit clarifier lists under the GP profile. Core-only processing preserves clarifier text but does not activate splitting or ordering from those clarifiers. Profile-defined splitting or ordering should use them only when the consumer trusts the source, validates the claim against the payload, or supplies separator structure from trusted configuration.

AES:

• SeparatorLiteral with raw payload preserved.

3.10.1 Symbolic Literal (|...|)

A symbolic literal is a nonempty atomic symbolic value distinct from textual data:

stage = |approved|
label = |in review|
quoted = |say "yes"|
escaped = |wait\|ready|

Lexical rules:

• the opening and closing delimiter is |;

• the decoded payload MUST contain at least one Unicode scalar, so || is invalid;

• spaces, comment markers, and quote characters inside the delimiters are payload content;

• raw line feeds and carriage returns are invalid;

• ordinary quoted-string escapes are supported, and | additionally represents a literal pipe;

• the decoded payload is significant, including leading and trailing spaces;

• canonical form uses pipe delimiters, escapes | as |, and otherwise applies minimal string-style escaping.

In transport mode, stage = |approved| infers SymbolicLiteral. In strict mode, :symbol is the reserved matching datatype. In custom mode, a custom datatype may bind a symbolic literal according to the ordinary custom-datatype rules.

A symbol is not inherently an enum, identifier, variable, reference, executable token, or schema constant. Those meanings belong to profiles, schemas, and consumers. Symbol identity compares the decoded symbol payload and does not equal a string with the same characters.

Core preserves datatype clarifiers structurally, but aeon.gp.profile.v1 assigns symbol the clarifiers = "none" rule. The GP profile therefore rejects explicit clarifiers on :symbol and does not extend the separator/radix custom-clarifier exception to symbolic literals.

AES:

• SymbolicLiteral with the decoded payload in value; source delimiters and escape spelling remain source-level syntax.

3.11 SANSA Address Literal

SANSA means Semantic Address NameSpace Abstraction.

Examples:

path:sansa = $.contact.name
context:sansa = ?.name
selector:sansa = $.inventory.items.*.sku
deepSelector:sansa = $.inventory.**
attribute:sansa = $.contact.name.@.unit
pattern:sansa = $.items.("item?*").sku
qualified:sansa = $.result:number|nan
external:sansa = $.["john"].isLocatedAt.["Brussels"]

Core role:

• :sansa marks a value as a SANSA address literal;

• strict mode requires the reserved :sansa datatype annotation for SANSA address literal values;

• the literal may express an exact path or selector;

• AEON Core validates and preserves the address form it accepts;

• AEON Core does not resolve the address, expand selectors, interpret qualifiers, or authorize access to any target.

• SANSA member selectors describe semantic traversal rather than object traversal.

• AEON-backed consumers may resolve SANSA literals against AEON bindings and canonical paths, but :sansa values are not limited to AEON path domains.

• A SANSA literal may address another semantic namespace, such as an RDF-like graph, database, service resource tree, filesystem namespace, or runtime object graph, when a consumer exposes that namespace.

• Exact address-expression identity, canonical target identity, selector equivalence, and resolved Binding Set equality are distinct semantic questions.

Lexical boundary:

• a SANSA literal begins where the value begins;

• it continues until ASCII whitespace, a comma, or a line break that closes the value in the current AEON context;

• quoted SANSA segments and qualifier arguments use SANSA/AEON quoted payload rules where the SANSA grammar allows them.

Reference boundary:

• target:sansa = $.contact.name stores an address as data;

• copy = ~contact.name is an AEON clone reference;

• pointer = ~>contact is an AEON pointer reference.

These forms are related by address syntax, but they are not interchangeable. AEON reference legality applies only to ~ and ~> values.

AES:

• SansaAddressLiteral with parsed address structure and/or source literal preserved by the implementation.

4. Structured Values

Core preserves structural representation for objects, lists, tuples, and nodes.

Shared semantics are layered on top of that representation:

• object member order is preserved but is not semantically significant in the GP profile;

• list element order and index-addressability are preserved;

• tuple position and arity are preserved;

• node tags, attributes, child order, and indexed child slots are preserved;

• structural equality and mutation compatibility are defined by Aeonic Semantic Language and any active schema/profile authority;

• structural ordering has no Core default.

4.1 Object

Example:

user = {
  id:number = 1
  name:string = "John"
}

AES:

• ObjectNode.

Reserved object aliases:

• :object

• :obj

• :o

• :envelope

All of these aliases perform the same Core compatibility check: the bound value must be an object. Core does not attach extra semantics to :envelope; it is an ordinary object alias that conventions may reuse.

Parameterized object claims:

scores:object<number> = {
  alice:number = 10
  bob:number = 12
}

object<T> is a preserved claim that object member values are expected to satisfy T. Core validates only that the bound value is an object and preserves the full datatype annotation. Member-value validation belongs to AEOS, profiles, conventions, or trusted consumer logic.

Example:

close:envelope = {
  integrity = {
    alg:string = "sha-256"
  }
}

Convention note:

• GP security conventions recommend close:envelope as the standard security-envelope spelling.

• That recommendation is convention-level only; Core does not privilege the key close.

4.2 List

Examples:

arr = [1,2,3]
arr:list = [1,2,3]
arr:list<number> = [1,2,3]

Nuances:

• strict requires datatype presence, not generic args;

• generic args are optional syntax and not enforced by core semantic typing rules.

• Core v1 reserves generic arguments for list<T>, tuple<T...>, object<T>, node<T>, null<T>, nan<T>, and infinity<T>.

• nested generic type annotations are valid surface syntax and count against max_generic_depth.

• list elements may carry local anonymous datatype annotations with :type = value.

AES:

• ListNode.

4.3 Tuple

Examples:

point = (10,20)
point:tuple = (10,20)
point:tuple<int32,int32> = (10,20)
edge:triple<string,string,string> = ("subject","predicate","object")

Nuances:

• tuple/list distinction is preserved in AST/AES;

• triple<A,B,C> is a semantic alias of tuple<A,B,C> and introduces no additional runtime behavior;

• strict does not require tuple generic args.

• tuple elements may carry local anonymous datatype annotations with :type = value.

AES:

• TupleLiteral.

4.4 Node

Examples:

content = <div(<span("hello", <br>, "world")>)>
content:node = <div(<span("hello", <br>, "world")>)>
doc:node<html> = <html(<head>, <body>)>
child:node<node> = <tag>
icon:node = <glyph>
title:node = <title:node<string>("Hello world")>

Nuances:

• node forms are <tag(...)> for nodes with children and <tag> for empty nodes;

• empty-node shorthand <tag> is exactly equivalent to <tag()>;

• child-bearing node forms require the closing >; <tag(...) is invalid;

• inline node-head datatypes are permitted syntactically, but strict mode reserves node heads for :node;

• non-node inline node-head datatypes such as <tag:pair("x", "y")> are transport/custom forms, not strict forms;

• binding:node<T> is a preserved profile/domain/materialization-target claim about the bound node value;

• binding-side node<T> accepts T = node or a custom profile/domain/materialization target such as html;

• binding-side node<string>, node<number>, and other reserved non-node value datatype arguments are invalid because child-content claims belong on node heads;

• <tag:node<T>(...)> is a preserved child-content claim about that node head's children;

• Core validates the binding-side reserved-argument rule, validates that node<T> binds or annotates a node value, and preserves the full datatype annotation;

• child list may contain mixed value kinds;

• node children may carry local anonymous datatype annotations with :type = value;

• nodes are values; node children do not become independent top-level named bindings, but ordered child slots use indexed canonical paths.

AES:

• NodeLiteral.

5. References

Examples:

a = 1
b = ~a
c = ~>a
item = ~$.items[0]
meta = ~a.@.ns

Nuances:

• clone (~) and pointer (~>) are distinct and preserved;

• ASCII inter-token whitespace may appear between the reference sigil and the following path, but canonical formatting removes it;

• attribute selectors are valid in reference paths;

• legality checks (missing/forward/self) are core-owned;

• reference-form identity compares the reference kind and canonical exact target path;

• evaluating the referenced target value without rewriting the source value is a read-only consumer operation, conceptually follow(reference), not a Core parse operation;

• resolving a reference is a separate materialization/substitution operation that may inline, clone, alias, or preserve an explicit runtime reference according to consumer policy;

• consumers that follow or resolve references must preserve the original reference form in AES or other representation-preserving outputs.

AES:

• CloneReference or PointerReference.

6. EBNF Summary

7. Canonicalization and Drift Controls

Implementers should align with:

• appendices/appendix-canonical-form

• Portable AES Event Contract

• AEON-v1-compliance

This page is intentionally implementation-cross-checked to reduce inter-implementation drift.