Appendix — Processing Model
Appendix to: AEON Specification v1
Canonical topic owners: AEON Specification v1 and AEOS Specification v1.
This appendix is an orientation aid for the v1 processing pipeline. Canonical phase ownership lives in the top-level v1 specs and compliance documents. If this appendix conflicts with the canonical v1 spec set, the canonical v1 spec set wins.
This appendix illustrates AEON's conceptual processing phases, Assignment Events, processor selection boundaries, tuple/indexed-path support, and annotation stream emission.
1. Processing Phases
Implementations should read these phases as a conceptual pipeline. Normative phase ownership and conformance requirements live in the canonical v1 specs and compliance documents.
Relationships: Connection from Phase 1: Lexing Input → Tokens Classify Comment Channels to Phase 2: Structural Parse Tokens → AST; Emit TupleLiteral; Connection from Phase 2: Structural Parse Tokens → AST; Emit TupleLiteral to Phase 3: Canonical Path Resolution Assign Canonical and Indexed Paths; Connection from Phase 3: Canonical Path Resolution Assign Canonical and Indexed Paths to Phase 4: Assignment Event Emission Emit Binding and Annotation Records; Connection from Phase 4: Assignment Event Emission Emit Binding and Annotation Records to Phase 5: Profile Interpretation Invoke Processors and Datatype Hints; Connection from Phase 5: Profile Interpretation Invoke Processors and Datatype Hints to Phase 6: Schema Validation Evaluate Constraints and Violations; Connection from Phase 6: Schema Validation Evaluate Constraints and Violations to Phase 7: Reference Evaluation Resolve Values, Aliases, and Indexed Targets; Connection from Phase 7: Reference Evaluation Resolve Values, Aliases, and Indexed Targets to Phase 8: Finalization Materialize Final Document Model.
2. Assignment Events
2.1 Definition
An Assignment Event is a normalized record emitted for each binding.
2.2 Required Fields
| Field | Type | Description |
|---|---|---|
path | string | Canonical path to the node |
key | string | Key name being bound |
value | Value | Parsed AEON value (ListNode, TupleLiteral, etc.) |
span | Span | Source location |
2.3 Optional Fields
| Field | Type | Description |
|---|---|---|
datatype | string | Datatype hint if present |
annotations | map | Assignment annotations |
raw | string | Raw literal text |
2.4 Example
p@{style:color = #FF0000}:point = { x = 23, y = 3, z = 34 }
Assignment Event:
{
"path": "$.p",
"key": "p",
"datatype": "point",
"annotations": { "style:color": "#FF0000" },
"value": { "x": 23, "y": 3, "z": 34 }
}
2.5 Tuple Example (v1 baseline)
score:tuple<string,int32> = ("alice", 95)
Assignment Events:
{
"path": "$.score",
"key": "score",
"datatype": "tuple<string,int32>",
"value": { "kind": "TupleLiteral", "elements": ["alice", 95] }
}
Element sub-events (if emitting per-element events):
{ "path": "$.score[0]", "value": { "kind": "StringLiteral", "raw": "alice" } }
{ "path": "$.score[1]", "value": { "kind": "NumberLiteral", "raw": "95" } }
3. Uniqueness (Const Semantics)
AEON documents are immutable by construction:
For any canonical path, there MUST be at most one Assignment Event
Duplicate path bindings MUST raise an error
No implicit override, merge, or replacement semantics
4. Annotation Stream Emission (v1 baseline)
Annotation stream records are emitted in Phase 4, in parallel with Assignment Events. They do NOT appear in the AES.
See Appendix: Annotation Stream for record format and binding rules.
Key invariants:
Annotation stream emission MUST NOT affect AES contents
AES with all comments stripped MUST equal AES with comments present
Annotation stream records are source-ordered
5. Processor Registry
5.1 Definition
A Processor is a deterministic transformation function applied to Assignment Events.
5.2 Design Principles
No implicit execution — Documents cannot invoke processors directly
Profile-scoped authority — Only the active profile enables processors
Determinism — Same input produces identical output
No structural mutation — Processors cannot add/remove nodes
Explicit phase boundary — Processors run in Phase 5 only
5.3 Processor Binding
Profiles declare processors bound to:
Datatype hints (e.g.,
point→geom.point)Annotation keys (e.g.,
style:color→core.hex)Canonical paths
5.4 Invocation
During Phase 5, for each Assignment Event:
Profile determines applicable processors
Processors invoked in deterministic order
Each processor receives the event and current value
Processor may validate, transform, or attach metadata
5.5 Processor Input
Processors receive:
path— canonical pathvalue— current value (may beListNodeorTupleLiteralin v1)datatype— if presentannotations— if present
5.6 Processor Output
Processors MAY:
Return a transformed value
Return the same value unchanged
Raise a validation error
Processors MUST NOT:
Return multiple values
Alter the canonical path
Emit new Assignment Events
6. Reference Evaluation Phase
6.1 Binding Visibility Rule
A binding becomes eligible as a reference target only after its Assignment Event has been committed.
Self-references (e.g., a = ~a) are therefore invalid.
6.2 No Forward References
References MUST target paths already bound earlier in the document.
The no-forward rule applies independently per namespace (data and attribute).
6.3 Indexed Reference Targets (v1 baseline)
In v1 mode, references may target indexed paths:
items = (10, 20, 30)
second = ~items[1] // clone of element at $.items[1]
Resolution proceeds using the same no-forward rule (referenced indexed path must be already bound).
6.4 Resolution Semantics
| Operator | Behavior |
|---|---|
~ (clone) | Resolve terminal value, copy |
~> (pointer) | Return alias to named binding |
6.5 Cycles
Because AEON forbids forward references, cycles are unrepresentable.
7. Error Reporting
Diagnostics should reference:
Canonical path
Span (when available)
Phase where error occurred
Example:
Error: Unknown processor "geom.point"
Path: $.p
Phase: Profile Interpretation