AEON GP Convention v1

Status

Draft interoperability convention

1. Purpose

AEON Convention v1 defines a lightweight interoperability convention built on top of AEON core syntax.

It standardizes a small set of common semantic labeling patterns so that a document can declare:

or

and receivers can reliably interpret shared conventions such as:

• measurements
• currency
• namespaces
• precision and system context
• separator-encoded values
• format labels

This convention does not extend AEON core semantics. It relies entirely on existing AEON constructs:

• attributes (@{})
• separator syntax (:sep[...])
• ordinary scalar values

2. Design Goals

AEON Convention v1 aims to be:

• minimal • predictable • non-computational • cross-domain • easy to validate downstream

It provides semantic interoperability without turning AEON into a domain-specific language.

3. Non-Goals

AEON Convention v1 does not require AEON core to:

• convert units • normalize numeric values • infer measurement systems • evaluate formats • compute derived values

Examples:

These statements only label the data.

Any computation or interpretation belongs to:

• schemas • profiles • processors / tonic layers • application logic

4. Convention Declaration

Documents using the convention should declare it in meta.

4.1 Single Convention

4.2 Multiple Conventions

4.3 Rule

convention and conventions are mutually exclusive.

A document must not declare both.

Implementations may internally normalize:

as

but this normalization must not appear in serialized documents.

5. Core Principle

A convention defines interpretation agreements, not language semantics.

AEON core preserves:

• bindings • attributes • separators • scalar values

The convention defines how these preserved patterns are commonly understood.

6. Reserved Attribute Keys

The following attribute keys have defined meaning under Convention v1.

Unknown keys remain allowed and are treated as opaque unless defined elsewhere.

6.1 unit

Declares a measurement unit label associated with a value.

Meaning:

• identifies the unit of measurement • purely descriptive • does not imply conversion or dimensional reasoning

6.2 system

Declares the system or standard context in which a unit or label should be interpreted.

Meaning:

• disambiguates unit systems • provides contextual classification • does not imply conversion behavior

6.3 precision

Declares the intended representational or measurement resolution of a value.

Meaning:

• indicates expected granularity or accuracy • does not require rounding or formatting

6.4 currency

Declares a currency denomination associated with a numeric value.

Meaning:

• identifies monetary denomination • does not imply exchange-rate logic or accounting rules

6.5 ns

Declares a namespace for a semantic token.

Meaning:

• qualifies interpretation within a named semantic domain • reduces ambiguity between similar labels

6.6 dimensions

Declares the ordering or semantic structure of packed dimensional values.

Meaning:

• describes the dimension ordering • does not parse or validate the value

6.7 format

Declares a representation label for a value.

Meaning:

• labels the representation pattern • does not require validation unless enforced elsewhere

7. Separator-Assisted Scalar Conventions

AEON core provides separator syntax. Convention v1 standardizes common interpretation patterns.

General Form

Meaning:

• :sep[...] declares the separator token • the scalar is intended to be read as packed data • interpretation depends on surrounding attributes or schemas

7.1 Version Pattern

Meaning:

• dot-separated version segments

No semantic version precedence is implied.

7.2 Dimension Pattern

Meaning:

• x-separated dimensional values • dimension order declared by dimensions • measurement unit declared by unit

7.3 Date Pattern

Meaning:

• - separated date segments • ordering defined by format

8. Unknown Keys

Convention v1 permits extension.

Rule:

• known reserved keys have stable meaning • unknown keys may appear • unknown keys should be treated as opaque unless a schema or profile defines them

This enables forward compatibility.

9. Validation Posture

Convention v1 itself is descriptive.

Validation belongs to downstream layers.

Examples:

A schema might require:

• currency to match ISO codes • unit to match an allowed list • precision to match allowed increments • format="semver" values to match a pattern

These checks are not AEON core responsibilities.

10. Example Document

11. Interpretation Summary

12. Definition

AEON Convention v1 is a versioned interoperability agreement that standardizes common attribute labels and separator-based scalar representations using AEON core constructs, without extending AEON core semantics.

13. Governance Recommendation

Keep Convention v1 intentionally small.

Recommended reserved key registry:

Future conventions may extend this registry or specialize it for particular domains.

===

Appendix — AEON Convention v1

Status

Proposed interoperability convention

1. Overview

AEON Convention v1 defines a lightweight interoperability convention built on top of AEON core syntax.

It standardizes a small set of commonly used semantic labeling patterns while preserving AEON’s core principles:

• AEON core remains syntax and structure only
• Conventions define interpretation agreements
• No new computation or evaluation semantics are introduced

This convention allows documents to declare predictable metadata patterns such as:

• measurement labeling
• currency labeling
• namespace qualification
• representation formats
• separator-encoded scalar values

2. Convention Declaration

Documents using this convention should declare it in the meta object.

Single convention

Multiple conventions

Rule

convention and conventions are mutually exclusive.

A document must not contain both fields.

Implementations may internally normalize:

to

but serialized documents must use only one form.

3. Design Principles

AEON Convention v1 follows these principles:

1 — Non-invasive

The convention introduces no new AEON language features.

2 — Descriptive only

Attributes describe data but do not instruct computation.

3 — Domain neutral

The convention provides labeling patterns usable across domains.

4 — Extensible

Unknown attribute keys remain valid unless restricted by schemas or profiles.

4. Core Language Independence

AEON Convention v1 introduces no new syntactic, canonicalization, or evaluation rules.

All structural behavior remains governed by AEON core.

Specifically, the convention does not define:

• parsing rules
• ordering rules
• canonicalization rules
• evaluation rules

These remain entirely within AEON core.

5. Reserved Attribute Keys

The following lowercase attribute keys are defined by AEON Convention v1.

Attribute keys defined by this convention must be lowercase ASCII identifiers.

6. Attribute Definitions

6.1 unit

Declares a measurement unit label associated with a value.

The attribute is descriptive only and does not imply conversion or dimensional computation.

6.2 system

Declares the measurement or classification system associated with a value.

This attribute exists to disambiguate units that vary between systems.

6.3 precision

Declares the intended representational or measurement resolution.

The attribute does not require rounding or formatting.

6.4 currency

Declares a monetary denomination.

The attribute does not imply exchange rate handling or accounting rules.

6.5 ns

Declares a semantic namespace for a value.

Namespaces reduce ambiguity between identical labels used in different domains.

6.6 format

Declares a representation format for a value.

The format label identifies the structure of a packed scalar representation.

It does not require validation unless enforced by a schema or profile.

7. Separator-Encoded Scalars

AEON core provides separator syntax:

Convention v1 standardizes common interpretive patterns using this syntax.

Example:

The separator describes representation structure but does not imply automatic parsing.

8. Unknown Keys

Unknown attribute keys remain valid.

Processors should treat unknown keys as opaque unless:

• a schema defines them
• a profile defines them
• a processor explicitly supports them

This ensures forward compatibility.

9. Example Document

10. Summary

AEON Convention v1 provides a small interoperability layer for labeling data while preserving AEON’s core philosophy:

• AEON core defines structure
• conventions define interpretation
• processors define behavior

This separation allows conventions to evolve without expanding the AEON language itself.

If you'd like, we can also define a very small follow-up appendix that will matter later:

Appendix — Convention Naming and Versioning Rules

Because that determines whether the ecosystem ends up with nice names like:

or chaotic ones like: