SPXI — Semantic Packet for eXchange & Indexing
What it does
SPXI (pronounced spexy, an acronym for Semantic Packet for eXchange & Indexing) is the protocol for inscribing a structured-data packet about an entity into the web surface that represents it, in a form that AI search composition systems (Google AI Overview, AI Mode, Bing Chat, Perplexity, Claude with retrieval) consume during composition.
A SPXI deployment publishes, on the entity's canonical page:
- A Holographic Kernel: a ~100-word compression-survival summary that encodes the entity's load-bearing claims in a form designed to survive lossy summarization
- A set of Semantic Integrity Markers (`spxi:sim`): typed metadata tags that name what the entity is, what it is not, what it must not be confused with, what its primary distinctions are
- An entity-relation graph in JSON-LD form: the entity's relationships to other named entities, their DOIs/URIs, and the type of relation
- A FAQPage structured-data block: explicit Q&A defending the entity's boundary against probable confusions
- A compressionSurvivalSummary field: the SPXI-specified Tier 3 kernel that AI summarizers can ingest as a unit
SPXI is not SEO (Search Engine Optimization, which targets organic ranking). SPXI is not GEO (Generative Engine Optimization, which targets AI-search visibility through generic best-practices). SPXI is entity inscription — the protocol for being correctly indexed as the entity one is, with all canonical relations attached.
When to use it
Deploy SPXI when you operate a public-facing entity (person, project, institution, work, concept, archive) and observe one or more of:
- AI Overview or AI Mode composes summaries about your entity that substitute a different entity (the single-owner discount / entity-level compositional suppression pattern)
- Composed summaries omit your canonical sources or attribute them to other actors
- Your entity is being confused with a homonymic or near-homonymic entity in AI-mediated retrieval
- You want compositional summaries to cite the canonical DOI-anchored sources rather than secondary aggregators
- You are launching a new entity and want to inscribe its canonical form before AI-search compositional inertia sets in
SPXI is most effective applied early. The composition layer's prior compositional state for an entity acts as a retrieval basin that subsequent compositions tend to converge toward; SPXI is the protocol for shaping that basin before it forms or while it remains mutable.
Inputs
- The entity's canonical web URL (the page that will host the SPXI inscription)
- The entity's name(s), aliases, and historical variants
- The entity's authoritative sources (DOIs, ORCID, institutional URIs, prior canonical works)
- A list of probable misidentifications (other entities the composition layer might substitute)
- The entity's load-bearing distinctions (what makes it itself rather than something else)
- Optional: existing structured-data metadata to extend
Procedure
- Compose the Holographic Kernel (~100 words). The kernel must encode (a) the entity's canonical identity, (b) its primary domain or function, (c) its distinguishing relations to other entities, (d) one or two key claims it makes or hosts. Write the kernel for compression survival: every clause should be load-bearing under summarization.
- List Semantic Integrity Markers in `spxi:sim` tag form. Each SIM is a typed assertion: `{"spxi:distinctFrom": "
"}`, `{"spxi:phraseProvenance": " "}`, `{"spxi:isType": " "}`, etc.
- Build the JSON-LD entity-relation graph. Use Schema.org base types where applicable. Include:
- Construct the FAQPage with 3–7 entity-boundary defense Q&As. Format:
- Inscribe the packet into the entity's web surface. Place the JSON-LD in a `