Appendix — Node Model

The Node Model is not enabled in AEON Core v1 by default.

Canonical topic owner: profile or processor specifications that explicitly enable node syntax.

1. Purpose

The Node Model introduces a non-binding structural container intended for:

• mixed content

• ordered child slots

• structural grouping without introducing named binding identity

Nodes exist to represent structure without named binding identity.

They are explicitly not objects, lists, or bindings.

2. Design Principles

The Node Model is governed by the following invariants:

1. Nodes do not introduce bindings

2. Node children use indexed canonical path segments

3. Nodes are opaque to AEON Core

4. Nodes do not create named Assignment Events

5. Nodes preserve ordering

Nodes are structural only. They preserve ordered child structure while exposing child slots through the same bracket-index path model used by lists and tuples.

3. Syntax

3.1 Node Declaration

A node is declared using the following syntax:

<tag(child1, child2, child3)>
<tag>

Where:

• tag is an identifier naming the node type

• <tag(...)> encloses an ordered list of node children

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

Whitespace and separators between children are significant only for ordering.

3.2 Node as Binding Value

A node may appear only as the value of a binding:

content = <paragraph("Hello ", <strong("world")>)>

In this example:

• $.content is a canonical binding

• paragraph and strong are node tags

• the first node child is addressable as $.content[0]

4. Node Children

4.1 Child Types

A node child MAY be any of the following:

• literal value

• object literal

• list literal

• node

• reference (~, ~>)

• anonymous typed value (:type = value)

Anonymous typed children annotate only the immediate child value. They do not create named bindings or ordering side effects:

page:node = <page(
  :string = "hello"
  <tag>
  :int32 = 3
)>

Nested anonymous typed values such as :n = :n = 3 are invalid.

4.2 Ordering

Node children are:

• strictly ordered

• preserved exactly as written

• not sorted, normalized, or deduplicated

Ordering is observable only by consumers that interpret node values.

5. AEON source-path semantics

5.1 Nodes

A node literal is reached through the canonical path of its owning value slot. When a node is the value of a binding, the binding path identifies the node value. Node children then use bracket-index segments beneath that path.

p = <paragraph("text")>

AEON source paths:

• $.p ✔

• $.p[0] ✔

• $.p.text ✘

Portable AES expands the implicit AEON node head. For a node at source path S, the NodeLiteral remains at E(S), its NodeHead is at E(S)[0], and source child S[i] maps to E(S)[0][i]. Therefore the first child above is represented at $.p[0][0], while $.p[0] is the node head.

5.2 Bindings Inside Node Children

If a node child contains an object literal with bindings:

p = <paragraph({ emphasis = "strong" })>

Then:

• $.p is a binding

• $.p[0] is the anonymous object child

• $.p[0].emphasis is an AEON source binding path

• The object literal behaves normally

• Portable AES represents the object child at $.p[0][0] and the nested binding at $.p[0][0].emphasis

6. Assignment Events

A node binding emits a value-less NodeLiteral event. Each node head emits a required indexed NodeHead event carrying the tag, and each child emits its own descendant event. Portable children are not optional synthetic views.

title = <heading("Hello")>

Emitted events:

• path=$.title, kind=NodeLiteral, with no value

• path=$.title[0], kind=NodeHead, value=heading

• path=$.title[0][0], kind=StringLiteral, value=Hello

7. References

References (~, ~>) inside node children are:

• syntactically valid

• symbolically preserved

• validated normally (missing, forward, self)

However:

• an AEON source child target such as $.page[0] is translated to the corresponding portable path such as $.page[0][0]

• node heads are portable AES targets, but AEON v1 has no source-path spelling for targeting the implicit head directly

• references target canonical paths, not raw source positions

8. Profiles and Enablement

Node syntax is not enabled by default.

A processor/profile must explicitly enable node syntax.

Example:

aeon:profile = "node"

Document profile declaration is advisory under zero-trust processing. Processors MUST select from an explicit whitelist/registry and verify profile compatibility before enabling node syntax.

Without processor/profile enablement:

• node syntax MUST produce a ProfileError

• parsing MUST fail-closed

9. Mode Interaction

Node semantics are mode-agnostic.

• transport vs strict does not change node behavior

• typing rules apply only to bindings, not node structure

10. Non-Goals (Explicitly Excluded)

The Node Model does not provide:

• automatic traversal semantics

• implicit binding creation

• execution or evaluation

• rendering rules

Any such behavior must be implemented outside AEON Core.

11. Rationale

The Node Model exists to support structure without identity.

It allows AEON to express:

• mixed content

• hierarchical grouping

• ordered child elements

…without violating AEON’s core invariants:

• immutability

• explicit identity

• canonical path determinism

• auditability

12. Summary

• Nodes are structural containers

• Bindings are the only named identity-bearing construct

• Node children are ordered and bracket-index addressable

• Nodes are profile-gated and optional

• AEON Core remains a binding-centric system