Proposal: Shared AEON Value Semantics

Scope: architectural ownership of deterministic value behavior across the AEON ecosystem.

1. Purpose

Shared AEON Value Semantics defines deterministic behavior for values after AEON Core has recognized their representation.

AEON Core answers:

What was written?

Value Semantics answers:

How do values relate to one another?

This proposal centralizes semantic contracts that would otherwise be duplicated across AEON-family consumers such as AEOS, SANSA, Tonics, and future runtime or storage layers.

2. Motivation

Several ecosystem components need the same value behavior.

These contracts describe values themselves. They do not belong exclusively to any one consumer.

If each consumer defines its own comparison, conversion, ordering, measurement, and arithmetic behavior, the ecosystem will drift. A query, a schema, and a runtime object may then disagree about the same value.

3. Architectural Position

The AEON ecosystem separates representation, shared value behavior, and consumer-specific application:

3.1 AEON Core

AEON Core defines:

• lexical grammar;

• value families;

• parsing;

• Assignment Event Stream;

• canonical representation.

Core does not define broad semantic behavior such as ordering domains, conversion policy, locale-sensitive collation, or arithmetic.

3.2 Shared Value Semantics

Shared Value Semantics defines:

• equality domains;

• comparison domains;

• ordering contracts;

• string and collation profiles;

• conversion contracts;

• measurement contracts;

• future arithmetic domains.

Shared Value Semantics begins only after a valid value representation exists.

3.3 Consumers

Consumers apply shared semantic contracts to their own domains:

• AEOS validates whether represented values satisfy schema/profile constraints.

• SANSA.Query evaluates query expressions over resolved semantic bindings.

• Tonics materialize validated values into runtime environments.

• Storage and transport layers may use shared semantics for indexing, sorting, and compatibility checks.

Consumers own their domain logic. They do not redefine the shared operation itself.

4. Ownership

The following concepts belong to Shared Value Semantics.

4.1 Equality Domains

Equality domains define:

• which value families may compare for equality;

• exact equality semantics within a family;

• cross-family equality rules, when any are allowed;

• behavior for explicit absence values, nulls, NaN, infinity, and other special values.

Consumers reference equality domains rather than defining local equality behavior.

4.2 Comparison Domains

Comparison domains define relational comparison for values such as:

• numbers;

• strings;

• dates;

• times;

• datetimes;

• instants;

• future domain-specific values.

Consumers use these domains for:

where .age > 18
order by .name
min(...)
max(...)
range validation

Where no comparison domain is defined, comparison must fail closed with a deterministic diagnostic.

4.3 Ordering and Collation Contracts

String ordering belongs to Shared Value Semantics, not to SANSA.Query alone.

Collation profiles define how text is compared for ordering. A profile must be:

• deterministic;

• platform independent;

• versionable;

• explicit;

• independent of host operating-system locale defaults.

A canonical locale-independent profile should provide a stable default. Locale-aware, natural-sort, and domain-specific ordering profiles may be defined later as named profiles.

Consumer syntax such as:

order by .name

uses the active value-semantics ordering profile. Future syntax may allow an explicit profile selection, but profile selection is separate from defining what the profile means.

4.4 String Case Mapping

Case mapping belongs beside string ordering because it raises the same Unicode, locale, normalization, and profile-selection questions.

Functions such as:

lower(...)
upper(...)

must use a deterministic string case-mapping contract. An implementation slice may temporarily use host runtime Unicode case mapping, but normative behavior must not depend on process locale, operating-system locale, database collation, or host-language defaults.

4.5 Conversion Contracts

Conversion contracts define deterministic conversion between value families.

Examples:

number("42")
string(42)
date("2026-07-21")

Each conversion must reuse the lexical contract already defined by AEON Core. Consumers must not define alternative parsing rules for the same conversion.

4.6 Measurement Contracts

Measurement contracts define deterministic measurements such as:

length(...)
count(...)

Examples include string length, collection count, byte length, and domain-specific measurements.

The measurement unit must be explicit in the contract. For example, string length may mean Unicode scalar count, grapheme-cluster count, byte count, or another profile-defined measure; consumers must not silently choose different meanings.

4.7 Arithmetic Domains

Arithmetic is a future value-semantics area.

Potential operations include:

+
-
*
/
sum(...)
average(...)
median(...)

Arithmetic domains belong to Shared Value Semantics so that query evaluation, validation, materialization, and future computation layers do not invent incompatible numeric behavior.

5. Reuse Principle

Every semantic contract should exist exactly once.

For example:

All consumers observe identical behavior.

Whenever a semantic operation derives, compares, orders, converts, measures, or combines values, it should reference the shared Value Semantics contract.

Consumers must not define equivalent behavior locally when a shared contract exists.

6. Profiles

Profiles extend or select semantic behavior without changing the core contract.

Examples:

• canonical string ordering;

• locale-specific collation;

• natural numeric-region sorting;

• decimal precision policy;

• temporal comparison policy;

• domain-specific conversion surfaces.

Profiles must be deterministic and versionable. A profile must not introduce executable behavior into documents.

Consumers may restrict which profiles they accept.

6.1 Profile Selection

The active value-semantics context is selected by the consumer, runtime, schema profile, or trusted host configuration.

Documents may carry values that become inputs to semantic operations, but a document must not grant itself a more permissive semantic profile. Profile selection is an authority-bearing consumer boundary, not a document-level escape hatch.

A consumer must make profile selection explicit when behavior would otherwise depend on:

• process locale;

• operating-system locale;

• database collation;

• host-language comparison defaults;

• installed Unicode, ICU, CLDR, or timezone database versions.

Implementations must not silently inherit those host defaults as normative AEON behavior unless the inherited behavior is identified as part of a named, versioned profile.

6.2 Profile Advertisement

Consumers should advertise the value-semantics profiles they support.

Example profile identifiers:

aeon.value.default.v1
aeon.value.string.codepoint.v1
aeon.value.string.natural.ascii.v1
aeon.value.string.locale.fr.v1
aeon.value.temporal.iso8601.v1

aeon.value.default.v1 is the candidate minimum consumer profile. It composes the minimum equality, ordering, concrete-value, and provisional case-mapping behavior defined in this proposal with the portable codepoint string profile.

aeon.value.string.codepoint.v1 is the portable locale-independent string-ordering floor. Natural-sort profiles, such as aeon.value.string.natural.ascii.v1, and locale-aware profiles, such as a French collation profile, must be named explicitly and remain profile-selected behavior rather than host-locale defaults.

Profile identifiers remain proposal-stage until promoted by focused contract documents. Implementations may expose local profile identifiers, but local identifiers should be clearly marked as non-portable.

6.3 Failure Without an Active Contract

Profile-dependent operations fail closed when no active contract defines their behavior.

This includes:

• string ordering;

• locale-aware string comparison;

• temporal comparison;

• case mapping;

• string-to-temporal conversion;

• numeric, decimal, or version-like natural sorting.

Consumers must report a deterministic diagnostic rather than falling back to host defaults.

6.4 AEON-Shaped Configuration

Consumer configuration may be represented as ordinary AEON data.

For example:

valueSemantics:object = {
  profiles:list<string> = [
    "aeon.value.default.v1"
    "aeon.value.string.codepoint.v1"
    "aeon.value.string.natural.ascii.v1"
    "aeon.value.string.locale.fr.v1"
    "aeon.value.temporal.iso8601.v1"
  ]
  stringOrder:object = {
    profile:string = "aeon.value.string.codepoint.v1"
  }
  caseMapping:object = {
    profile:string = "aeon.value.default.v1"
  }
  temporal:object = {
    profile:string = "aeon.value.temporal.iso8601.v1"
    timezoneAuthority:string = "iana"
    tzdbVersion:string = "2026a"
  }
}

This shape is illustrative until a profile-configuration contract is promoted. The important boundary is authority: a trusted consumer, schema profile, runtime, or host configuration may select this context; an arbitrary document being queried or mutated does not select its own value-semantics authority.

6.5 Value Family Semantic Classification

AEON Core value families do not all enter the same semantic domain.

Some families have intrinsic shared semantics. Some reuse a shared string, numeric, temporal, or structural contract. Others are only lexical carriers until a consumer, schema, convention, or profile selects a more specific interpretation.

A consumer must not treat every represented payload as a string merely because it has a textual source form. Textual transport and semantic string behavior are different contracts.

Initial classification:

Notes:

• nan is an operational Core compatibility label for NaNLiteral. It must be listed with the same audit weight as infinity, even though NaN does not enter equality or ordering in the minimum profile.

• Null sentinel spellings such as !none are value forms, not datatype labels. They are included in this table because they define the accepted null-value surface that value semantics must preserve.

• Reserved aliases inherit their canonical family's semantic basis. They do not create a separate semantic domain unless a profile explicitly adds one.

• Generic parameters and bracket arguments refine claims. They do not by themselves create comparison, ordering, conversion, or mutation compatibility behavior.

Separator literals illustrate why this classification is necessary:

ip:kadot = ^192.3.3.222
dim:sep["x"] = ^300x250
semver:kadot = ^3.14.15

All three values share separator-literal mechanics. They do not share one ordering contract.

An IP profile might compare numeric address components. A dimensions profile might compare width, height, area, or aspect ratio. A semantic-version profile might compare major, minor, and patch segments with version-specific pre-release rules. A generic string collation profile is not a safe fallback for any of those meanings unless the consumer explicitly selects string treatment.

When no active shared or profile-defined semantic basis exists for an operation, the operation fails closed.

6.6 Classification Edge Cases

The following families need special care before their behavior is promoted beyond the minimum profile:

• toggle has Boolean-like materialization in some outputs, but it is not automatically the same semantic family as boolean. A profile may define conversion, but comparison must not silently collapse yes, on, true, and 1.

• hex has no single natural meaning. It may represent color, bytes, an identifier, a hash prefix, or a numeric value. It is distinct from every radix family, including any radix profile that uses base 16. Equality beyond canonical hex-payload identity and ordering require a profile.

• radix is number-like, but Core preserves representation and does not perform base-specific digit validation as a semantic operation. Numeric comparison requires base validation and conversion under a profile.

• encoding is payload-like. The encoded payload is surfaced as characters and may be ordered naïvely by that payload surface, but that does not make decoded bytes, decoded text, radix comparison, media type, or decoded-content ordering a default interpretation.

• sep and kadot intentionally defer meaning. They are useful exactly because profiles can define IP addresses, dimensions, semantic versions, delimited records, product codes, or other structured scalar domains without changing Core syntax.

• sansa may contain exact paths or selectors, and may target AEON or non-AEON semantic namespaces. Address-expression identity, canonical target identity, selector equivalence, and resolved Binding Set equality are distinct questions and must not be collapsed.

• object, list, tuple, and node have preserved structure and minimum structural equality. Semantic ordering, coercion between structural families, and mutation compatibility are profile/schema responsibilities.

• References have two semantic surfaces: the reference form itself and the followed value. Consumers must be explicit about which surface an operation uses.

6.7 Toggle Semantics

Toggle values have two separate semantic surfaces:

• toggle-token identity;

• Boolean conversion or materialization.

Toggle-token identity is exact:

Boolean conversion is a distinct operation:

A consumer may materialize toggles as Booleans in an output format, such as finalized JSON, but materialization does not rewrite AEON value semantics. yes == true, on == true, no == false, and off == false require explicit conversion or a profile-defined comparison domain.

Without explicit conversion or an active profile-defined compatibility rule, toggle and Boolean values are cross-type comparisons and fail closed.

6.8 Hex Semantics

Hex values are their own AEON value family.

They are not radix literals, even when a radix profile uses base 16.

Examples:

color:hex = #ff00aa
mask:radix[16] = %ff00aa
octal:radix8 = %70

These values differ in:

• literal family: HexLiteral versus RadixLiteral;

• source sigil: # versus %;

• accepted payload grammar;

• datatype compatibility;

• canonicalization behavior;

• profile surface.

Core hex canonicalization removes _ visual separators and lowercases hex digits. Therefore canonical hex-payload identity treats these as the same hex payload:

#Ff_00_Aa
#ff00aa

That does not imply numeric comparison, byte comparison, color comparison, or radix comparison.

A consumer that wants to compare hex values as numbers, bytes, colors, hashes, or identifiers must select an explicit profile for that interpretation. A consumer must not compare hex:hex = #10 and mask:radix[16] = %10 as equal merely because the payloads contain compatible base-16 digits.

Core v1 does not reserve radix16 as a shorthand alias. Use radix[16] when a value is intended to remain in the radix-family numeric-representation surface. This keeps base-16 radix values explicit and avoids implying that hex and base-16 radix are interchangeable.

6.9 Encoding Semantics

Encoding values are encoded lexical payloads.

The Core v1 encoding-family labels are:

• encoding;

• base64;

• embed;

• inline.

All four labels bind to EncodingLiteral. The labels reserve compatibility surface, but they do not create four independent Core value families.

The accepted payload alphabet is Base64URL-shaped:

A-Z a-z 0-9 - _ =

This is a lexical transport alphabet. It is not a radix alphabet, and it is not a guarantee that the payload has been decoded, interpreted, or validated as bytes by Core.

Examples:

payload:encoding = &QmFzZTY0IQ==
blob:base64 = &QmFzZTY0IQ==
asset:embed = &QmFzZTY0IQ==
snippet:inline = &QmFzZTY0IQ==
base64ish:radix[64] = %QmFzZTY0IQ

base64 and radix[64] are different semantic surfaces:

• base64 is an encoding-family compatibility label over EncodingLiteral;

• radix[64] is a radix-family numeric-representation claim over RadixLiteral;

• encoding payloads may use -, _, and trailing = padding;

• radix payloads use the radix digit sequence defined for RadixLiteral;

• decoding bytes and converting a radix number are different operations.

By default, value semantics may compare encoding values by exact payload-string identity and naïve payload order.

Naïve payload order compares the preserved encoded payload characters using the active canonical codepoint string profile. It does not decode bytes, decode text, compare media content, compare hashes, or apply radix interpretation.

A profile may define richer behavior, such as:

• Base64URL decode validity;

• byte equality after decoding;

• MIME or media-type interpretation;

• embedded AEON or text decoding;

• hash or digest comparison;

• ordering by payload length, decoded byte length, decoded text, media content, or domain-specific metadata.

Those meanings require an explicit profile. A consumer must not treat base64 as radix[64], must not apply generic string collation as byte ordering, and must not assume that encoding, embed, or inline always means Base64 data with a particular media type.

6.10 Separator Semantics

Separator literals are compact structured lexical scalars.

They are powerful because the same literal family can carry many domain shapes:

version:kadot = ^0.11.0
ip1:sep = ^127.0.0.1
ip2:sep["."] = ^127.0.0.1
dim:sep["w","h","d"] = ^300w400h200d
psv:sep["|"] = ^"id"|"name"|"phone"

Core preserves the literal family, payload, and datatype separator specs. Core does not assign domain meaning to the separator characters. A separator spec such as [.] is preserved metadata and may be a useful claim, but it is not trusted parsing authority by itself.

The minimum shared behavior for separator literals is:

• canonical separator-payload identity;

• naïve separator order.

Canonical separator-payload identity compares the canonical separator payload as preserved separator-literal content. It does not compare decoded records, numeric parts, dimensions, versions, IP octets, or table columns.

Naïve separator order compares canonical separator payloads by the active canonical codepoint string profile. This is a deterministic fallback order over the preserved payload surface. It is not a domain order.

Naïve separator order does not split the payload, even when the datatype includes enough separator specs to make splitting possible.

For example:

ip1:sep = ^192.0.0.255
ip2:sep["."] = ^192.0.0.255

Both values are ordered by their whole canonical payload. The ["."] clarifier on ip2 does not cause naïve order to split the payload into ["192", "0", "0", "255"], compare numeric octets, or infer an IP address.

For example, naïve separator order may produce a different result from semantic-version ordering:

a:kadot = ^0.11.0
b:kadot = ^0.9.9

Under naïve separator order, the payload characters are compared directly. Under a semantic-version profile, the payload would be tokenized into numeric version components before comparison.

Profiles may define separator-domain behavior such as:

• semantic-version comparison;

• IPv4 or IPv6 parsing and address comparison;

• dimensions parsed into width, height, depth, area, volume, or aspect ratio;

• delimited-record parsing such as pipe-separated values;

• product-code segmentation;

• numeric segment validation;

• trailing-delimiter policy;

• duplicate or repeated separator handling.

Datatype separator specs and labels such as kadot may help a profile select or validate a domain, but they do not create domain order by themselves. A consumer that needs dimensions sorted by aspect ratio, IP addresses sorted by numeric address, or versions sorted by numeric components must select an explicit profile.

Profile-defined separator ordering must also account for trust. A profile may use separator specs only when the consumer trusts the source of the claim, validates the claim against the payload, or supplies the separator structure from trusted configuration. Untrusted document-local separator specs should be treated as data claims, not as authority to choose parsing or ordering behavior.

6.11 SANSA Address Semantics

SANSA address literals are structured address expressions carried as AEON values.

SANSA is namespace- and domain-neutral. It defines how semantic locations are expressed, not what those locations represent.

The same :sansa value family can carry:

• exact address paths;

• selector expressions that may resolve to zero, one, or many bindings;

• contextual-root expressions;

• qualified address literals;

• address expressions targeting AEON namespaces;

• address expressions targeting non-AEON semantic namespaces.

Examples:

exact:sansa = $.contact.name
selector:sansa = $.inventory.items.*.sku
contextual:sansa = ?.name
qualified:sansa = $.result:number|nan
rdfLike:sansa = $.["john"].isLocatedAt.["Brussels"]

AEON Core validates and preserves the SANSA literal. It does not decide whether the literal targets AEON bindings, an RDF-like graph, a database, a service resource tree, a filesystem namespace, a runtime object graph, or another semantic namespace.

The minimum shared behavior for SANSA address literals is:

• canonical address-expression identity;

• naïve address-expression order.

Canonical address-expression identity compares the canonical parsed address expression, including root kind, selector sequence, quoted payloads, and qualifier structure. It is syntactic identity of the address expression as data.

Naïve address-expression order compares canonical address-expression renderings by the active canonical codepoint string profile. It is a deterministic fallback order over address expressions as preserved values. It does not resolve the addresses.

These are separate questions:

Exact addresses and selectors must not be collapsed merely because a selector happens to resolve to one binding in a particular namespace snapshot.

A consumer must not assume that SANSA member selectors are AEON binding keys or object traversal unless the active namespace is an AEON-backed namespace or another trusted adapter defines that mapping. SANSA member selectors describe semantic traversal; the addressed domain belongs to the namespace.

6.12 Structural Container Semantics

AEON structural values have two separate surfaces:

• preserved representation;

• shared structural semantics.

Core preserves object members, list elements, tuple elements, node tags, node attributes, node children, lexical order, and index-addressable child slots where applicable.

Shared Value Semantics may then define structural equality over the preserved values.

The minimum structural equality surface is:

Structural equality is recursive and uses the active Shared Value Semantics equality rule for each contained value. If a contained value cannot be compared under the active equality profile, the structural comparison fails closed.

List and tuple values do not compare equal by default, even when they contain equal values in the same order. A profile may define an explicit coercion or compatibility operation, but the minimum profile does not silently collapse structural families.

Object member order is not significant for structural equality in the GP profile. Core may still preserve object member order for diagnostics, AES emission, canonicalization inputs, or source fidelity.

Node child order is significant for structural equality. Attribute order is not significant when attributes are represented as keyed attributes; duplicate-attribute rejection remains a Core representation guarantee.

Datatype annotations, generic parameters, and bracket arguments are preserved claims. They do not by themselves make two otherwise equal structural values unequal unless an active profile or schema declares annotation-sensitive equality.

Structural ordering is intentionally absent from the minimum profile. There is no portable default order for objects, lists, tuples, or nodes. Consumers that need sorted containers must provide an explicit order key, schema rule, or profile-defined container ordering.

Structural mutation compatibility is also profile/schema-owned. Mutation rules must define replace versus merge behavior, list insertion and reindexing, tuple arity compatibility, object member creation and deletion, node child mutation, attribute mutation, and conflict handling. A document-local datatype claim such as node<node> is an input to validation; it does not authorize the document to choose schema behavior for itself.

6.13 Reference Semantics

AEON references have two distinct semantic surfaces:

• the reference form;

• the followed value.

The reference form is the represented reference value. It includes:

• reference kind: clone reference ~ or pointer reference ~>;

• canonical exact AEON target path;

• source/provenance metadata, when retained by a consumer.

Reference-form identity compares the reference kind and canonical target path. For example, ~a and ~$.a identify the same clone-reference form after canonical path normalization, while ~a and ~>a do not identify the same reference form because clone intent and pointer intent are distinct.

Reference-form identity does not inspect the target value. It uses the canonical exact-path subset of AEON/SANSA addressing used by reference legality; selectors such as .*, .**, patterns, filters, and contextual roots are not part of AEON reference targets.

The followed value is the value reached by explicitly walking a legal reference path and evaluating the target value under the active consumer policy.

Conceptual operation:

follow(reference) -> value

follow(...) is not a Core parse operation and not a materialization operation. It is a read-only consumer operation used by schemas, queries, tonics, storage adapters, or runtime APIs when they intentionally want to inspect target-value semantics instead of reference-form semantics.

Following a reference:

• requires a legal reference target;

• must respect Core missing, forward-reference, and self-reference failures;

• must be bounded by consumer recursion/depth policy;

• must preserve diagnostics that identify both the reference source and the target path;

• must not rewrite, substitute, inline, alias, or erase the original reference form.

After follow(...), active Shared Value Semantics apply to the resulting target value. For example, a followed reference to a number compares as a number, and a followed reference to a list participates in structural list equality.

Without an explicit follow operation or consumer-declared followed-value mode, constraints and comparisons apply to the reference form itself. This allows schemas to ask either:

• "is this value a reference to the expected target?"; or

• "does the referenced value satisfy this constraint?"

Those are different operations and should produce different diagnostics.

Reference resolution is a separate operation. In reference-resolution or materialization mode, the value carrying the reference may be replaced, inlined, cloned, aliased, or represented as an explicit runtime reference according to clone/pointer policy. That operation belongs to Tonics, runtime materializers, storage adapters, or explicit consumer profiles. It must not be confused with follow(...).

Pointer references may carry aliasing, identity, or mutation-authority semantics during reference resolution. Those meanings belong to the consuming layer. Shared Value Semantics can define target-value comparison after following, but it does not decide whether a pointer may be mutated, aliased, inlined, or materialized as host identity.

7. Minimum v1 Consumer Contract

The first shared contract should cover the behavior already exercised by SANSA.Query and expected by AEOS-style validation.

This section is the candidate aeon.value.default.v1 profile. It is intentionally small and should become the first shared CTS surface when promoted.

7.1 Value Categories

The minimum profile recognizes these value and evaluation categories:

• finite number;

• positive infinity;

• negative infinity;

• NaN;

• string;

• Boolean;

• toggle;

• temporal value;

• lexical structured scalar;

• SANSA address literal;

• structural container;

• reference form;

• explicit null;

• explicit absence value, when exposed by a consumer;

• missing binding, when resolution produces no binding.

Missing binding is not a value. It is an evaluation state produced by a consumer such as SANSA.Resolve or AEOS path selection.

Explicit null and explicit absence values are values. They must not be collapsed into missing, false, an empty string, or zero.

For minimum-profile consumer predicates, a concrete value means a present value that is not part of the non-value group.

The minimum non-value group is:

• Missing;

• explicit null;

• explicit absence values;

• NaN.

Finite numbers, infinities, strings, Booleans, toggles, temporal values, lexical structured scalars, SANSA address literals, container values, and legal reference forms are concrete values for isValue(...) purposes.

7.2 Equality

The minimum equality surface is:

Consumers must not coerce strings, numbers, Booleans, toggles, nulls, absence values, structural families, or reference forms to make equality succeed. For example, a list and tuple with the same contained values require explicit coercion or a profile-defined compatibility domain before equality can be considered. A reference form and its followed target value are also distinct unless an explicit follow(...) operation or followed-value mode is active.

7.3 Ordering

The minimum ordering surface is:

Ordering must fail closed when the active profile does not define the compared category pair.

7.4 Value Predicate Basis

Consumers may expose predicates that classify evaluation results. Those predicates should be defined in terms of the shared value categories rather than by host-language truthiness.

For example, a minimum-profile isValue(...) predicate should return true when its operand evaluates to exactly one concrete value and false for Missing, explicit null, explicit absence values, and NaN. If the operand resolves more than one binding, the predicate should produce a cardinality diagnostic rather than choosing one binding.

isValue(...) is not a comparison guard. A query or validator that needs a number, string, temporal value, structural value, or other specific comparable domain should combine isValue(...) with semantic filters or profile-defined predicates for that domain.

7.5 Canonical String Profile Placeholder

The minimum/default profile requires a deterministic string equality and ordering profile, but this proposal does not yet define the final collation algorithm beyond the codepoint candidate.

Until that algorithm is promoted, consumers should treat string ordering as a named value-semantics dependency rather than redefining it locally.

The canonical string profile must eventually define:

• Unicode unit of comparison;

• normalization policy;

• case sensitivity;

• accent and combining-mark behavior;

• total-order tie breakers;

• behavior for invalid or unpaired Unicode representations, if exposed by a host.

Locale-aware, natural-sort, and domain-specific profiles remain explicit extensions.

7.6 Canonical Codepoint String Profile Candidate

The first portable string ordering candidate is a codepoint profile.

Candidate identifier:

aeon.value.string.codepoint.v1

The candidate profile orders strings by decoded Unicode scalar values from left to right.

The candidate profile:

• performs no normalization;

• performs no case folding;

• does not ignore accents, combining marks, punctuation, or whitespace;

• compares each decoded scalar value numerically;

• sorts the shorter string first when every shared scalar compares equal.

Exact string equality compares the decoded scalar sequence exactly.

This profile is a stable portability floor. It is not intended to model human-language collation.

aeon.value.default.v1 uses this codepoint profile for string ordering unless a consumer explicitly selects another string profile.

7.7 String Collation Profile Framework

Richer string ordering profiles must define the full ordering contract they apply.

A string profile defines the complete string comparison and mapping contract, including normalization, case mapping, locale or domain rules, numeric-region handling, and tie-breaker behavior. Partial profile definitions are not permitted; a consumer must not combine unrelated normalization, collation, case-mapping, natural-sort, or host-default behaviors into one implicit algorithm.

A string collation profile should define:

• normalization behavior before comparison;

• case-sensitive or case-insensitive behavior;

• accent and combining-mark behavior;

• ignored characters, if any;

• punctuation grouping;

• contraction and expansion rules;

• numeric-region recognition;

• decimal, version-like, or segmented-number behavior;

• tie-breaker behavior when primary comparison keys match.

Numeric-looking regions must not require fixed-width machine-number conversion. Profiles that support natural sorting should compare numeric regions by a deterministic arbitrary-precision or digit-sequence algorithm.

For example, a natural-sort profile must explicitly define whether:

job-2 < job-10
1.10 < 1.2

and why.

An exploratory ASCII numeric-region profile may be identified as:

aeon.value.string.natural.ascii.v1

Under that profile, non-numeric regions are compared by decoded Unicode scalar value, while consecutive ASCII digit regions are compared as arbitrary-precision digit sequences. For example:

part-2 < part-10

This profile is useful for testing human-oriented numeric ordering without making natural sort the default string behavior.

For example, a French locale profile such as aeon.value.string.locale.fr.v1 may order éclair before zebre, while the codepoint profile orders by scalar value and therefore produces a different result. Both behaviors are valid only when selected through their named profiles; neither may be silently inherited from the host process locale.

7.8 Case Mapping

The minimum case-mapping surface is:

lower(string) -> string
upper(string) -> string

Case mapping is deterministic and profile-defined. It must not depend on process locale, operating-system locale, database collation, or host-language defaults.

The canonical case-mapping profile must eventually define:

• Unicode case-mapping table or referenced version;

• locale-sensitive exceptions, if any;

• normalization behavior before and after mapping;

• whether one input scalar may expand to multiple output scalars.

Until the canonical case-mapping profile is locked, consumer implementations may expose lower(...) or upper(...) as implementation-slice behavior, but should document that normative behavior is still owned by Shared Value Semantics.

7.9 Temporal Profile Candidate

AEON Core recognizes temporal datatype names such as:

• date;

• time;

• datetime;

• wtc.

Shared Value Semantics defines a conservative same-family temporal comparison surface for canonical AEON temporal payloads. Richer temporal ordering, validation, conversion, temporal-reference behavior, and mutation compatibility remain profile-defined.

Candidate identifier:

aeon.value.temporal.iso8601.v1

A temporal profile should define:

• recognized temporal categories;

• equality and ordering domains for each category;

• whether cross-category comparison is allowed;

• normalization before comparison;

• relationship to applicable temporal conventions such as aeon.gp.temporal.v1;

• timezone offset behavior;

• temporal-reference authority and timezone database version, when applicable;

• precision and fractional-second behavior;

• diagnostics for unsupported or ambiguous temporal values.

The minimum temporal comparison surface is:

Temporal transport as text does not imply string comparison. Temporal values are compared through the active temporal value-semantics profile. The default minimum profile uses canonical payload order only within the same temporal family.

7.10 Mutation Compatibility

Future mutation operations should consume the same Shared Value Semantics contracts used by query and validation.

Mutation compatibility includes:

• whether a write value is compatible with a target datatype;

• whether conversion is allowed;

• which normalization, if any, is applied before storage;

• how null, absence values, and Missing interact with a write target;

• how temporal precision, timezone offsets, and named zones are preserved or normalized;

• whether structural writes replace, merge, insert, delete, or reindex;

• how tuple arity, object member constraints, list element constraints, node child constraints, and node attribute constraints are enforced.

SANSA.Mutate, AEOS, Tonics, and storage adapters should not define separate compatibility behavior for the same AEON value family.

For example:

set $.invoice.dueDate:date = 2026-07-24

SANSA.Mutate identifies the target and operation. AEON Core parses the represented value. Shared Value Semantics decides whether the represented value is compatible with date and what normalization, if any, is required. The host or schema authority decides whether the mutation is authorized.

For structural values, Shared Value Semantics supplies compatibility concepts and equality behavior, while schema/profile authority decides the permitted mutation shape. For example, a tuple mutation may require exact arity compatibility, a list mutation may permit insertion and reindexing, an object mutation may permit member creation, and a node mutation may restrict child tags or attribute sets. Those policies must not be inferred from a document-local datatype claim alone.

7.11 Consumer Handoff

Consumers own where an operation appears and what diagnostic context is produced.

Shared Value Semantics owns what the operation means.

For example:

where .age > 18

SANSA.Query owns where, candidate filtering, Binding Set handling, and query diagnostics. Shared Value Semantics owns numeric comparison.

For example:

age minimum 18

AEOS owns the schema rule and validation diagnostic. Shared Value Semantics owns numeric comparison.

8. CTS Ownership

Shared Value Semantics should have its own conformance coverage once individual contracts become normative.

The proposal-stage CTS scaffold is:

aeonite-cts/cts/value-semantics/v1/value-semantics-cts.v1.json
aeonite-cts/cts/value-semantics/v1/suites/01-minimum-consumer-contract.json

Shared CTS cases can then be reused by consumers:

This keeps conformance behavior aligned across implementations without duplicating normative definitions.

9. Non-Goals

This proposal does not yet define:

• the complete numeric comparison contract;

• the final canonical string collation algorithm beyond the codepoint candidate;

• final locale profile identifiers;

• final temporal profile identifiers or timezone database authority;

• conversion syntax in any consumer;

• arithmetic operators;

• consumer-specific authorization;

• runtime APIs.

Those belong in focused follow-up proposals or contract documents.

10. Relationship to SANSA.Query

SANSA.Query is the first AEON-family consumer that exercises a broad portion of shared value behavior.

SANSA.Query should reference Shared AEON Value Semantics for:

• scalar equality;

• relational comparison;

• string ordering;

• case mapping;

• conversion functions;

• measurement functions;

• future arithmetic or aggregation.

SANSA.Query still owns query syntax, Binding Set evaluation, candidate filtering, projection, result construction, diagnostics, and resolver integration.

11. Relationship to AEOS

AEOS consumes Shared Value Semantics when validating value relationships.

For example, an AEOS rule may require:

age > 18

AEOS owns the validation rule and diagnostic context. Shared Value Semantics owns what numeric comparison means.

12. Relationship to Tonics

Tonics consume Shared Value Semantics when materializing values into runtime environments.

Tonics may expose runtime-specific APIs, but the behavior of shared conversions, comparisons, measurements, and ordering must remain aligned with the shared contracts unless a profile explicitly defines a different accepted surface.

13. Design Philosophy

AEON Core defines representation.

Shared AEON Value Semantics defines deterministic behavior.

Consumers apply that behavior to their own domains.

This keeps representation, validation, evaluation, materialization, and future computation separated while preserving one semantic contract for every value family.