SANSA v1
SANSA is the Semantic Address NameSpace Abstraction. It defines a common way for consumers to address, resolve, and query semantic information without depending on the physical implementation that stores or generates that information.
SANSA is independent within the Aeonite ecosystem. AEON, AEOS, AES, runtime object graphs, databases, services, and other systems may implement SANSA, but none of those systems owns the abstraction.
Each document declares its own lifecycle in AEON metadata. This overview groups the current documents by that metadata without encoding lifecycle in filenames or document links.
Draft Documents
SANSA Addressing v1 defines the SANSA address model and selector vocabulary.
SANSA Resolve v1 defines deterministic structural resolution over SANSA address expressions.
These documents are draft-stage because their foundation-layer behavior is implemented and exercised by AEON TypeScript and the standalone @altopelago/sansa implementation.
Proposal Documents
SANSA Query v1 defines the initial read-only semantic query pipeline built on SANSA.Resolve.
SANSA Conformance v1 defines capability names, conformance profiles, and extension advertisement.
SANSA Extensions v1 records candidate selector and query-helper extensions before they enter the core v1 conformance surface.
SANSA Meaning Validation Integration v1 defines the AEON, AEOS, SANSA, and meaning-validation responsibility boundaries.
SANSA Mutate v1 defines the conservative authority-bearing mutation-plan boundary and its growth path.
SANSA Instruction v1 defines a proposed human-authored source surface that combines Addressing, Query, and Mutate vocabulary.
Conceptual Stack
Relationships: Connection from Namespace to SANSA.Resolve; Connection from SANSA.Resolve to Binding Set; Connection from Binding Set to SANSA.Query; Connection from SANSA.Query to Result Set; Connection from Binding Set to SANSA.Mutate; Connection from SANSA.Mutate to Mutation Plan; Connection from Mutation Plan to Target Surface; Connection from Target Surface to Consumer Apply.
SANSA.Resolve discovers semantic structure. SANSA.Query evaluates semantic bindings without changing namespace state. SANSA.Mutate freezes exact targets and expresses change intent without owning authorization, transactions, orchestration, or physical storage behavior.
Target surfaces are host-format or adapter boundaries layered after mutation planning. They decide whether valid SANSA.Mutate intent can be represented by AEON, JSON-compatible output, ASP storage, or another consumer-selected target.
SANSA.Instruction is a proposed source-level composition layer. It is intended to lower into structured Query and Mutate behavior rather than replace those capabilities. Claimed source provenance in Instruction, such as reason or author text, is preserved for explanation but does not authorize the change or prove actor identity.
SANSA.Mutate reuses consumer-selected Aeonic Semantic Language for preconditions. Value legality remains the responsibility of the consumer, AEOS schema, or domain validator; a document being mutated cannot select its own mutation, validation, or authorization policy.
Mutation policy is a trusted consumer boundary layered after planning and before apply. It may authorize or deny planned intent, but it does not become SANSA Instruction source and does not rewrite the mutation plan.
Capability Families
The SANSA v1 specification family covers these conformance capabilities:
SANSA.AddressingSANSA.ResolveSANSA.Query
Implementations should advertise supported capabilities rather than claim unqualified support for "SANSA". For example, a parser may support SANSA.Addressing without supporting SANSA.Resolve, and a resolver may support SANSA.Resolve without supporting SANSA.Query.
Proposal-stage or future specifications may cover:
SANSA.MutateSANSA.InstructionSANSA.SubscribeSANSA.Historyself-description and capability discovery
Design Boundaries
SANSA separates semantic interaction from representation, validation, persistence, and runtime implementation.
AEON defines how meaning is represented.
AEOS defines how meaning is constrained.
AES defines the portable event representation of meaning.
SANSA defines how meaning is accessed and, through proposal-stage Mutate capability, how change intent is expressed.
Meaning validators define how domain rules are interpreted and reported.
Future mutation consumers define how accepted change intent is authorized, orchestrated, and applied.
SANSA does not require data to originate from AEON. It requires only that a conforming implementation expose a deterministic semantic namespace to consumers.