# 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](./sansa-v1-addressing.md) defines the SANSA address model and selector vocabulary. - [SANSA Resolve v1](./sansa-v1-resolve.md) 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](./sansa-v1-query.md) defines the initial read-only semantic query pipeline built on SANSA.Resolve. - [SANSA Conformance v1](./sansa-v1-conformance.md) defines capability names, conformance profiles, and extension advertisement. - [SANSA Extensions v1](./sansa-v1-extensions.md) records candidate selector and query-helper extensions before they enter the core v1 conformance surface. - [SANSA Meaning Validation Integration v1](./sansa-v1-meaning-validation-integration.md) defines the AEON, AEOS, SANSA, and meaning-validation responsibility boundaries. - [SANSA Mutate v1](./sansa-v1-mutate.md) defines the conservative authority-bearing mutation-plan boundary and its growth path. - [SANSA Instruction v1](./sansa-v1-instruction.md) defines a proposed human-authored source surface that combines Addressing, Query, and Mutate vocabulary. ## Conceptual Stack ```text Namespace | v SANSA.Resolve | v Binding Set | +--> SANSA.Query --> Result Set | +--> SANSA.Mutate --> Mutation Plan --> Target Surface --> Consumer Apply ``` *Figure 1: SANSA conceptual stack* 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.Addressing` - `SANSA.Resolve` - `SANSA.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.Mutate` - `SANSA.Instruction` - `SANSA.Subscribe` - `SANSA.History` - self-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. --- ## Related documents - [SANSA v1 Addressing](./sansa-v1-addressing.md) - [SANSA.Resolve v1](./sansa-v1-resolve.md) - [SANSA.Query v1](./sansa-v1-query.md) - [SANSA v1 Conformance and Capabilities](./sansa-v1-conformance.md) - [SANSA v1 Extension Candidates](./sansa-v1-extensions.md) - [SANSA v1 AEON, AEOS, and Meaning Validation Integration](./sansa-v1-meaning-validation-integration.md) - [SANSA.Mutate v1](./sansa-v1-mutate.md) - [SANSA Instruction v1](./sansa-v1-instruction.md)