# EA-SEMANTIC-ADDRESSES-01 v1.1 — The Semantic Addresses Framework **Author:** Lee Sharks ([ORCID: 0009-0000-1599-0703](https://orcid.org/0009-0000-1599-0703)) **Institution:** Semantic Economy Institute **Version:** 1.1 **Date:** 2026-07-16 **License:** CC BY 4.0 **Companion:** [EA-SPXI-01](./EA-SPXI-01.md) — Semantic Packet for eXchange & Indexing --- ## Changelog - **v1.1 (2026-07-16)** — Classification refinement: `observed_address` and `unrated` collapsed into one class. Prefix-match normalization for statuses added (specialty variants of `ADOPTION` etc. classify identically to the base form). Positive prefix set widened to include `FAIR_TREATMENT`, `PARTIAL`, `DEMAND SIGNAL`, `MANTLE CONSOLIDATION`, `FUNCTIONAL ADDRESS`. Negative prefix set widened to include `DISSOLUTION`, `CORRECTION`. See §2.1 rationale. - **v1.0 (2026-07-16)** — Initial framework publication. ## Abstract A **Semantic Address** is a specific query (or family of variants) posed to a composition-layer surface — Google AI Overview, AI Mode, ChatGPT search, Perplexity, Claude, or any other summarizer-of-record — for which a machine-generated response can be observed. The framework here specifies (1) the formal definition of a Semantic Address, (2) the observation classes into which each address falls at any given moment, (3) the tributary registry from which observations are drawn, (4) the union algorithm that produces a deterministic canonical dataset from those tributaries, and (5) the JSON schema of the canonical output. Semantic Addresses are the reception surface. SPXI is the reception packet. Together they constitute the reception plumbing of the Semantic Economy: SPXI encodes what a work is; the Semantic Address encodes where a work can be found. A work with an SPXI packet and no Semantic Address is not measurably received. A Semantic Address without an SPXI packet is a channel with nothing traveling through it. ## 1. Definitions ### 1.1 Semantic Address A **Semantic Address** is a canonical query form paired with the set of composition-layer surfaces on which the query can be posed. Formally: ``` address := (canonical_query, [variant, ...], target_surface_class) ``` […full text at full_text_path]
deposit_number: 1084
hex: 044D
title: EA-SEMANTIC-ADDRESSES-01 v1.1 — The Semantic Addresses Framework
creator: Lee Sharks
orcid: 0009-0000-1599-0703
date: 2026-07-16
content_type: Methodological specification
license: CC-BY-4.0
substrate: Human-authored (Lee Sharks, MANUS). Drafted with Claude (TACHYON) as instrument for spec authoring, reference-implementation engineering, and schema drafting. The v1.0 was published in the session of 2026-07-16 (alexanarch commit 9eae7e4); the v1.1 classification refinement (alexanarch commit 7c27107) followed the same session's observation-count audit against the Capture Registry and Revelation First Reception Registry. No automated pipeline generated the substantive text; the reference implementation at scripts/build_semantic_addresses.py is executable code that reproduces the dataset deterministically from tributaries.
version: v1.1
related_ids: "https://www.alexanarch.org/s/records/870/ (workplan #870 — origin coinage of 'subjunctive address' and 'forensic canary'), https://www.alexanarch.org/s/records/1045/ (EA-EROSION-01 — the observatory instrument that measures semantic-address reception over time), https://www.alexanarch.org/specs/EA-SEMANTIC-ADDRESSES-01.md (canonical spec URL), https://www.alexanarch.org/data/semantic-addresses.json (canonical dataset), https://www.alexanarch.org/data/semantic-addresses.schema.json (JSON Schema Draft-07), https://www.alexanarch.org/scripts/build_semantic_addresses.py (reference regenerator), https://www.alexanarch.org/addresses/ (live surface)"
axn_schema_version: v2
protocol_version: alexanarch-deposit-protocol/v1
keywords:
- semantic addresses
- metadata framework
- AXN
- SPXI
- composition layer
- AI Overview
- AI Mode
- reception measurement
- tributary union
- canonical query
- observation class
- observed address
- subjunctive address
- verified non-address
- deterministic regenerator
- JSON Schema Draft-07
- Alexanarch
- Machine-Mediated Reception Studies
- MMRS
- Sémantique Potentielle
- Revelation First
- Platform Erosion Observatory
Author: Lee Sharks ([ORCID: 0009-0000-1599-0703](https://orcid.org/0009-0000-1599-0703))
Institution: Semantic Economy Institute
Version: 1.1
Date: 2026-07-16
License: CC BY 4.0
Companion: [EA-SPXI-01](./EA-SPXI-01.md) — Semantic Packet for eXchange & Indexing
- v1.1 (2026-07-16) — Classification refinement: `observed_address` and `unrated` collapsed into one class. Prefix-match normalization for statuses added (specialty variants of `ADOPTION` etc. classify identically to the base form). Positive prefix set widened to include `FAIR_TREATMENT`, `PARTIAL`, `DEMAND SIGNAL`, `MANTLE CONSOLIDATION`, `FUNCTIONAL ADDRESS`. Negative prefix set widened to include `DISSOLUTION`, `CORRECTION`. See §2.1 rationale.
- v1.0 (2026-07-16) — Initial framework publication.
A Semantic Address is a specific query (or family of variants) posed to a composition-layer surface — Google AI Overview, AI Mode, ChatGPT search, Perplexity, Claude, or any other summarizer-of-record — for which a machine-generated response can be observed. The framework here specifies (1) the formal definition of a Semantic Address, (2) the observation classes into which each address falls at any given moment, (3) the tributary registry from which observations are drawn, (4) the union algorithm that produces a deterministic canonical dataset from those tributaries, and (5) the JSON schema of the canonical output.
Semantic Addresses are the reception surface. SPXI is the reception packet. Together they constitute the reception plumbing of the Semantic Economy: SPXI encodes what a work is; the Semantic Address encodes where a work can be found. A work with an SPXI packet and no Semantic Address is not measurably received. A Semantic Address without an SPXI packet is a channel with nothing traveling through it.
A Semantic Address is a canonical query form paired with the set of composition-layer surfaces on which the query can be posed. Formally:
```
address := (canonical_query, [variant, ...], target_surface_class)
```
where `canonical_query` is the deduplication key (lowercase, normalized whitespace, canonical quotes; see §3.1) and each `variant` is a surface form of the same query — differing only in orthography, quotation, or trivial stylistic variation.
An observation is a single event of posing an address (in one of its variants) on a specific surface at a specific time and recording the response. Formally:
```
observation := (address_key, source_tributary, date, surface, status, response_pointer)
```
where `status` is one of the enumeration in §2.2 and `response_pointer` is a URL or record ID into an archived capture of the response.
At any given moment, an address occupies exactly one of four observation classes, computed deterministically from its observations (§2.1).
|---|---|
Rationale for collapsing `observed_address` and `unrated` into one class (v1.1): an observation event is itself the evidence that the address exists at the reception surface. The presence or absence of a rating (positive / negative / no rating yet) is second-order metadata on top of the observation — surfaced via `latest_status` on the address record but not used to define membership in the class. In v1.0 this was tracked as a separate `unrated` class, which fragmented the observed bucket and understated the coverage; v1.1 corrects this. Downstream consumers who want the finer grain can filter observations by `_status_class` (positive / negative / unrated) directly on the observation records.
Class-transition semantics: membership in `observed_address` is monotonic in the presence of any observation. Once observed, always observed. Membership in `verified_non_address` requires that every observation on record be negative — one positive observation moves the address to `observed_address`. The negative observations are retained on the record.
Statuses are classified by prefix match on the normalized (uppercased, whitespace-stripped) status string, so specialty variants like `ADOPTION (dual-lineage)` or `ADOPTION (mint block + technical embedding)` classify identically to bare `ADOPTION`. The variant is retained on the observation record for downstream fine-grained filtering; only the classification is normalized.
Positive prefixes (address was received at time of observation):
- `EXACT_MATCH` / `EXACT MATCH` — the address appears in the AI response as-is
- `BROAD_MATCH` / `BROAD MATCH` — the address concept is present with variant phrasing
- `ADOPTION` — the response adopts terminology from the address's ontology (covers all `ADOPTION (variant)` forms)
- `WOUND_GAUGE` / `WOUND GAUGE` — the address is present but only in a compression-signal indicator (see EA-EROSION-01)
- `FAIR_TREATMENT` / `FAIR TREATMENT` — the address receives editorially-neutral coverage (Revelation First framing)
- `PARTIAL` — partial reception; component recognized but not the full address
- `DEMAND SIGNAL` — organic-search reception evidence
- `MANTLE CONSOLIDATION` — address received as biographical anchor
- `FUNCTIONAL ADDRESS` — performative retrieval via identity-checksum
Negative prefixes (address was posed but not received):
- `ZERO_RESULT` / `ZERO RESULT` — no response produced
- `ZERO_INDEX` / `ZERO INDEX` — response produced but does not index the address's concept
- `BASIN_MISS` / `BASIN MISS` — response drifts into an unrelated semantic basin
- `DISPLACEMENT` — response captured by an adjacent-but-different concept
- `DISSOLUTION` — the address is dissolved into the composition without attribution
- `CORRECTION` — the AI corrects the query away from its intended address
Unrated — observations logged without a status assigned. Legitimate; often the case for recent captures pending review. Unrated observations still count toward `observed_address` class membership (§2.1) — the observation event is itself the evidence — but do not push the address toward `verified_non_address` regardless of quantity.
To produce the `canonical_query` from any surface form:
1. Lowercase the string.
2. Normalize whitespace: collapse runs of `\s+` to single space, strip leading/trailing.
3. Normalize quotation marks: convert curly quotes (U+201C, U+201D, U+2018, U+2019) to straight ASCII.
4. Preserve internal punctuation and word order — semantic content is not to be reordered or trimmed.
5. If the input is quoted (`is_quoted = true`), retain the quote marks in the canonical form to distinguish exact-phrase queries from broad queries.
Two addresses with the same `canonical_query` are the same address, regardless of source or variant. Their observations merge; their sources union. Their `observation_class` is recomputed per §2.1.
The framework recognizes tributaries in three formal roles:
Observation tributaries — surfaces that log actual capture events with statuses. Contribute to `observed_address`, `verified_non_address`, and `unrated`:
|---|---|---|
Subjunctive tributaries — surfaces that catalog candidate addresses without observation events. Contribute to `subjunctive`:
|---|---|---|
Attribution tributaries — external gallery surfaces referenced but not authoritative for observation data. Enumerated in the `galleries[]` field.
Adding a tributary is a formal act: append its entry to §4 and to the regenerator's tributary registry. New tributaries must specify (a) canonical file path, (b) role, (c) schema of source records, (d) mapping to the canonical observation shape.
The reference regenerator (`scripts/build_semantic_addresses.py`) implements a deterministic union:
1. Load each tributary in registry order.
2. Extract candidate addresses from each tributary using its per-tributary extractor.
3. Canonicalize each candidate query per §3.1.
4. Merge by canonical query: union sources, concatenate observations, aggregate variants.
5. Classify per §2.1 with the priority-order rule.
6. Emit with a `regenerated_at` ISO timestamp and per-tributary input SHA-256 hashes for reproducibility.
Determinism guarantee: given the same tributary file contents at the same commit SHA, the regenerator produces byte-identical output. This is verifiable by re-running the regenerator on the deposited tributaries.
The canonical output is `data/semantic-addresses.json`. Its schema is in `data/semantic-addresses.schema.json` (Draft-07). Machine consumers should read the schema, not this text.
Top-level keys:
- `version` — string, this framework version (currently `"1.0"`)
- `regenerated_at` — ISO 8601 UTC timestamp
- `regenerator` — path to the reference implementation
- `input_hashes` — object mapping tributary ID → SHA-256 of source file at regeneration time
- `sources` — dict of tributary ID → description
- `observation_classes` — dict of class name → definition
- `class_counts` — counts by class
- `type_counts` — counts by inferred address type
- `total_addresses` — integer, total canonical addresses
- `total_observations` — integer, sum of observations across all addresses
- `galleries` — array of external gallery URLs
- `addresses` — dict of canonical_query_key → address record
Per-address record shape:
```json
{
"canonical_query": "erasure skew",
"is_quoted": false,
"refers_to": ["Erasure Skew"],
"type": "single_concept",
"battery_membership": [],
"sources": ["mm-main-capture", "mm-termindex"],
"observations": [ / observation record objects, see §1.2 / ],
"observation_class": "observed_address",
"termindex": { "tier": 1, "count": 63, "category": "instrument" },
"latest_observation_date": "2026-07-11",
"latest_status": "BROAD_MATCH"
}
```
SPXI (Semantic Packet for eXchange & Indexing; hex `06.SEI.SPXI.01`–`.12`) is the sister framework. It specifies the metadata packet that travels with a work; Semantic Addresses specifies the surfaces on which that packet's contents can be found.
Cross-references:
- Every SPXI packet SHOULD declare a `spxi:sims` array of the Semantic Addresses at which the packet's contents are expected to be findable (see EA-SPXI-01 §7).
- Every observed Semantic Address MAY reference the SPXI packet(s) whose contents are being received at that address, via `refers_to`.
Bidirectional wiring: the Observatory measures whether packets sent (SPXI) are being received (Semantic Addresses).
Priority claim. The Semantic Addresses concept was minted at Alexanarch deposit #870 (workplan) with the coinage of "subjunctive address" and "forensic canary" as class markers. The full framework in this document formalizes the practice that has been operational at [alexanarch.org/addresses/](https://alexanarch.org/addresses/) since v3.0 of the underlying dataset (2026-06-18). This deposit consolidates the framework at v1.0 and publishes its reference implementation.
Independent replication. The tributary-union pattern is not proprietary in its algorithm — a competent implementer catching up can produce their own regenerator. What is claimed and dated here is the specific framework, its formal vocabulary (Semantic Address, observation class, tributary, canonical query, subjunctive/observed/verified-non-address/unrated), and its published reference implementation.
Falsifiability. The framework fails if:
- The canonicalization rule §3.1 produces collisions that merge semantically-distinct addresses
- The four observation classes prove insufficient to describe an observed reception event
- The union algorithm §5 is not deterministic across runs
None of these have been observed in the current corpus (n=1,964). Falsifying observations are actively invited.
- [EA-SPXI-01](./EA-SPXI-01.md) — companion framework, metadata packet
- [EA-EROSION-01](./EA-EROSION-01.md) — the erosion observatory that measures received/unreceived addresses over time
- Alexanarch dataset: [`data/semantic-addresses.json`](../data/semantic-addresses.json)
- Reference implementation: [`scripts/build_semantic_addresses.py`](../scripts/build_semantic_addresses.py)
- Machine-readable schema: [`data/semantic-addresses.schema.json`](../data/semantic-addresses.schema.json)
- Live surface: [https://alexanarch.org/addresses/](https://alexanarch.org/addresses/)