Appendix — Bindings and Identity

Status: informative summary for consolidated v1

Canonical topic owners: ../AEON-spec-v1.md, ../structure-syntax-v1.md, ../addressing-references-v1.md

If this appendix conflicts with the canonical v1 spec set, the canonical v1 spec set wins.

1. Binding as Identity Unit

A binding has the form:

Bindings are the identity unit in AEON. Identity-backed behaviors attach to bindings, not to arbitrary value fragments.

2. Why Bindings Matter

Bindings provide:

• canonical path identity
• source ordering
• source span anchoring
• uniqueness/immutability checks

These properties are required for deterministic references, diagnostics, schema matching, and canonicalization.

3. References Depend on Bindings

References (~, ~>) target bindings via address expressions. A value without binding identity is not a legal reference target.

4. Containers and Identity

• Object members are bindings and therefore identity-bearing.
• List/tuple elements are positional values; they are addressable via index segments but are not independent named bindings.
• Attribute metadata is binding-attached and follows the binding target model.

5. Node Literals

Node literals are values. Node children do not implicitly create top-level named binding identity, but ordered child slots use bracket-index canonical paths such as $.content[0]. If a node child contains bindings, those bindings continue below the indexed child path.

Valid introducer example:

Identity-bearing bindings in this example include $.content and $.content.key.

6. Validation and Diagnostics

Schema/validator rules operate on addressable targets derived from bindings and indexed container structure. Diagnostics should report canonical path plus span where available.

7. Summary

Bindings are the semantic spine of AEON: they anchor identity, determinism, and conformance behavior.