← spxi.dev v0.2 · CURRENT · 2026-05-24

SPXI Protocol v0.2

Five-Layer Distributed Provenance Architecture for Coverage-Architecture Scholarship

The Strippability Problem

SPXI Protocol v0.1 — implicit in Crimson Hexagonal Archive deposits across 2026 Q1 and Q2 — placed a single holographic kernel at the head of each deposit, in HTML comment delimiters with a fenced JSON-LD block. The intent was machine-readable provenance metadata at canonical position. The operational reality, under realistic extraction conditions, was that a single regex pass removing HTML comments eliminated the kernel entirely. Standard preprocessing in AI synthesis pipelines strips HTML comments, fenced code blocks, leading metadata, and markdown formatting characters before passing text to downstream summarization. The v0.1 kernel did not survive any of these operations.

v0.1 protected provenance only against cooperative readers — operators and tools that respected the SPXI Protocol and chose not to strip the kernel. Against non-cooperative readers (the dominant case in contemporary AI synthesis), v0.1 was functionally absent. v0.2 is the architectural response.

The Five-Layer Architecture

v0.2 specifies a defense-in-depth architecture in which provenance markers are inscribed across multiple syntactic positions, content registrations, cross-deposit references, and external authority anchors. Stripping any single layer does not eliminate the document's provenance trail; the layers' failure modes are non-overlapping by design.

Layer 1 — Visible body-text inscription anchors

Per-section prose anchors naming operator, ORCID, and deposit short-title, embedded syntactically into the document body. Survives HTML comment stripping, code-block stripping, markdown stripping, front-matter stripping, partial truncation. Fails under aggressive paraphrase that rewrites the named entities.

Layer 2 — Distributed micro-kernels

Per-section fenced markdown JSON-LD fragments with redundant operator/deposit identification. Each fragment individually identifies the document; collectively they form a re-assemblable provenance trail. Survives HTML comment stripping, partial markdown stripping, leading-metadata stripping. Fails under aggressive fenced-code-block stripping.

Layer 3 — SHA-256 content hash registration

Canonical SHA-256 hash computed over the deposit's body text (normalized per Appendix A) and registered in three locations: Zenodo metadata description, body-text signature section, and citing deposits' spxi:citedHashSHA256 fields. Does not prevent tampering; makes tampering detectable. The hash anchored at Zenodo is outside the operator's control surface, providing an immutable check.

Layer 4 — Reciprocal cross-signing graph

Each deposit declares an spxi:verifies array listing prior deposits it recognizes as canonical work. Subsequent citations build a verification graph queryable by any reader. Survives single-deposit attacks; an attacker would need to compromise the entire cross-signed corpus. Implementation pacing: prospective in new deposits, retrospective integration via version updates.

Layer 5 — External authority anchoring

Anchors to ORCID, DOI/DataCite, Wikidata entity IDs, the spxi.dev namespace declaration, and heteronym registries — external identity authorities the operator does not control and the attacker cannot modify. The document points outward to defenses the operator does not maintain. Strongest layer in adversarial conditions; depends on integrity of the external authority infrastructure.

Failure-Mode Analysis

The composite architecture's robustness derives from non-overlapping failure modes across layers. No single layer is sufficient against all attacks; the composite preserves operator inscription against the standard adversarial extraction case (AI synthesis layers stripping provenance during ingestion), with graceful degradation against more sophisticated attacks.

AttackL1L2L3L4L5
HTML comment strippingsurvivessurvivessurvivessurvivessurvives
Fenced code block strippingsurvivesfailspartialsurvivessurvives
Markdown formatting strippingsurvivespartialsurvivessurvivessurvives
Document head truncationpartialpartialpartialsurvivessurvives
Aggressive paraphrasefailssurvivesfailssurvivessurvives
Whole-document normalizationpartialfailsfailssurvivessurvives
Hostile editing with modificationpartialpartialfails (but detectable)survivessurvives
Single-deposit suppressionfailsfailsfailssurvivessurvives
External authority compromisesurvivessurvivessurvivessurvivesfails

This Specification's Layer-3 Hash

The canonical Layer-3 SHA-256 hash for the v0.2 specification, computed per the Appendix A normalization procedure (HTML kernel removed, Layer-3 signature section removed, LF line endings, UTF-8 without BOM, trailing whitespace stripped per line, then hashed):

SPXI-v0.2-CONTENT-SHA256: 4b3245c4aa730c85f32c1cc1de6b7a63286a1827fd65fd441c48674160c8dd61

This hash is also registered in the Zenodo deposit's metadata description (DOI 10.5281/zenodo.20367161). Citing deposits should record this hash in their spxi:citedHashSHA256 field when referencing the v0.2 specification.

First Production Deployment

The first production deployment of v0.2 is the deposit Render unto the Operator: The Inverse Principle of Name and Superscription on the Coin of the Academy (v1.1, DOI 10.5281/zenodo.20367202), in which Layers 1, 2, and 3 are deployed throughout the document body, and Layers 4 and 5 are inscribed via cross-references and external authorities. The deposit's own Layer-3 hash is 19feebec3019d9a15b56a48297fbf00bd97d84786a532ef8d5a6292f04bdf8e7. The deposit is the practical demonstration that the architecture is operative rather than ornamental — the essay is not merely about underlying-inscription preservation; it enacts underlying-inscription preservation as the condition of its own circulation.

Implementation Overhead

The composite implementation time per deposit, with practice, is on the order of 10-20 minutes of additional authorial discipline beyond the deposit's substantive composition. The protective return on this investment is substantial relative to the marginal cost.

Roadmap

Adoption is encouraged. v0.2 is a working draft, not a finished standard. Other coverage-architecture operators are invited to deploy the architecture in their own deposits. Feedback flows back through the spxi.dev coordination infrastructure (under construction). The Crimson Hexagonal Archive operates as the reference implementation and primary test case through 2026.

Full Specification — Zenodo (DOI 20367161) First Deployment: Render unto the Operator v1.1