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, 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

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:

• canonical single-line strings emit double-quoted strings with minimal escaping;

• canonical multiline strings may emit as trimticks using canonical indentation.

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 contiguous > through >>>> marker;

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

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

• the marker itself may not be split.

Trimming rules:

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

• trim trailing empty lines before the closer;

• inspect the remaining non-empty lines to determine common left indentation;

• remove that indentation according to the marker's tab policy;

• preserve trailing whitespace on non-empty lines;

• preserve interior blank lines as blank lines;

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

Marker-width policy:

• >`: spaces-only indentation analysis; tabs remain payload;

• >>`: tabs normalize to width 2 for indentation analysis;

• >>>`: tabs normalize to width 3 for indentation analysis;

• >>>>`: tabs normalize to width 4 for indentation analysis.

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

Canonical notes:

• canonical multiline semantic strings emit as spaces-only trimticks;

• canonical output normalizes the indentation gutter to spaces only.

• canonical output may collapse trimticks to ordinary string literals when the normalized value is rendered in an inline context;

• one-line normalized trimticks in inline containers canonically emit as ordinary double-quoted strings;

• multiline trimtick values rendered inside inline object or attribute forms canonically emit as escaped double-quoted strings rather than multiline trimtick blocks;

• multiline trimtick blocks are preserved in canonical output when the enclosing canonical layout is multiline.

AES:

• StringLiteral with trimtick parser metadata preserved.

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;

• non-:toggle custom datatype aliases such as :myToggle remain invalid even when general custom datatypes are otherwise enabled;

• 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;

• Shared Value Semantics 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:

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
z:wtc = 2025-01-01T00:00:00Z&Australia/Sydney
localTime:wtc = 2025-01-01T00:00:00&Local         // WTC local time convention
geoTime:wtc = 2035-01-01T09:00&-36.7590183/144.2826718

Nuances:

• parser emits DateLiteral for date-only token;

• parser emits DateTimeLiteral for time and datetime-family tokens and WTCDateTimeLiteral for WTC tokens with an &temporal-reference suffix;

• 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;

• datetime extends that same reduced-precision rule after the T, so forms such as 2025-01-01T09Z, 2025-01-01T09+02:00, and 2025-01-01T09:30Z are valid;

• WTC extends the same reduced-precision datetime bases with a temporal reference suffix, so forms such as 2025-01-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 references may contain /, _, -, +, and . when used as part of a contiguous reference, so named timezone references such as America/Port-au-Prince, GB-Eire, Etc/GMT-1, and Etc/GMT+1, plus geographic references such as -36.7590183/144.2826718, are valid reference payloads;

• comment markers do not begin inside a contiguous WTC temporal-reference payload; forms such as Europe//Brussels and Europe/*Brussels*/ are invalid reference 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, 99:99, and 23:59:60 are not temporal literals in Core v1;

• strict datatype compatibility treats :time and :datetime as DateTimeLiteral-compatible and :wtc as WTCDateTimeLiteral-compatible;

• local-time WTC convention is ...&Local (for example 2025-01-01T00:00:00&Local);

• WTC preserves whether the temporal value is instant-anchored (...Z&reference) or civil-time-anchored (...&reference); the temporal value and temporal reference together form the temporal context;

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

AES:

• DateLiteral or DateTimeLiteral.

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.

• Shared Value Semantics 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.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 Shared AEON Value Semantics 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

• appendices/appendix-aes

• AEON-v1-compliance

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