Thursday, May 21, 2026

Signalfire Meridian - An open coordination layer for findable human content. Built in phases, governed transparently, designed to outlast its operators.

 

Signalfire Meridian

An open coordination layer for findable human content. Built in phases, governed transparently, designed to outlast its operators.

Product Requirements Document - v1.0 Final Draft

Classification: Distributable Working Document
Author: Rhombus Ticks
IT Consulting: TC Ricks
Research Assistance: Redwin Tursor
Imprint: Codex Americana
Date: May 2026


1. The Problem

1.1 The Diagnosis

Search is broken in a specific, structural way. Google has optimized for advertiser revenue until the index reflects advertiser intent more than user intent. The alternatives either inherit the same index (Bing, DuckDuckGo, most of the field), charge for independence (Kagi), or require technical capability to self-host that eliminates 95% of potential users (SearXNG).

The infrastructure to solve this already exists and is open source. What doesn't exist is a coherent, federated, quality-controlled layer on top of it that a normal person can use and a technically capable person can host and extend.

Two concrete harms follow from the current state. First: AI-generated content and SEO-optimized garbage have flooded the index faster than any single commercial search engine is incentivized to address, because their business model runs on clicks regardless of quality. Second: sites that Google has de-ranked or banished — for being too small, too independent, too honest, or too uninterested in SEO compliance — have no meaningful path back to discoverability. Both problems are structural. Neither has a market solution.

1.2 What Has Happened to Google

The structural failure has a name, a date, and a federal court ruling. In August 2024, Judge Amit Mehta of the U.S. District Court for the District of Columbia ruled that Google violated Section 2 of the Sherman Antitrust Act by maintaining illegal monopolies in general search services and search text advertising. The remedies ruling followed in September 2025, with additional details finalized in December 2025. As a matter of legal record, Google is an adjudicated monopolist. The Department of Justice and thirty-eight state attorneys general are currently appealing those remedies as insufficient and seeking Chrome divestiture; D.C. Circuit oral arguments are expected later in 2026. A separate federal ruling (Judge Brinkema, April 2025) found Google illegally monopolized publisher ad servers and ad exchanges — a second adjudicated monopoly in the same company in the same calendar window. The remedies in that case were still pending as of spring 2026.

The internal mechanism of decay is also documented. In 2019, after a slow advertising quarter, Google's advertising leadership effectively displaced its search-quality leadership in an internal escalation; by 2020 the head of Ads had also taken over Search. Trial exhibits and subsequent reporting show search-ranking decisions weighted toward advertising revenue rather than result quality from that point forward. This is not speculative criticism; it is evidence introduced into the federal antitrust record.

The decay is measurable in publisher data. Google's deployment of AI Overviews — generated summaries occupying the top of the search results page — correlates with a 58 percent reduction in click-through rates for top-ranked pages (Ahrefs, February 2026, across 300,000 keywords). Approximately 69 percent of Google searches now end with no click to any external website, up from 56 percent in 2024. Aggregate publisher traffic from Google search dropped 33 percent globally in 2025, with U.S. publishers down 38 percent (Press Gazette / Chartbeat, tracking more than 2,500 news sites). News publishers' share of incoming traffic from Google traditional search fell from 51 percent in 2023 to 27 percent in the fourth quarter of 2025. CNN, Business Insider, Forbes, and HuffPost each lost between 27 and 55 percent of their traffic year over year. Active antitrust litigation against AI Overviews has been filed by Penske Media in the United States and Chegg as an educational publisher, with a formal European Commission complaint from the European Publishers Council.

This is what "Google has become trash" means specifically. It is not aesthetic complaint. It is an adjudicated monopoly using its monopoly position to extract value from the publishers feeding its index — in service of advertising revenue — while its own AI products cannibalize the click-through economy those publishers depend on. The index increasingly contains AI-generated content trained on the work of publishers Google is simultaneously extracting from. The structural decay is documented in federal court filings, in independent measurement studies, and in active publisher litigation across two continents.

1.3 Why Google Cannot Self-Correct

The structural argument is straightforward. Google's revenue depends on advertising. Advertising revenue scales with engagement on Google properties, not with traffic departing to publishers. AI Overviews and zero-click answers are the direct optimization of that incentive. A genuine course correction — restoring publisher traffic, deprioritizing AI summaries, returning to a quality-first index — would reduce Google's revenue and is therefore not a course the corporate structure can take. This is not a claim that Google's executives are unwilling; it is a claim that the business model and the shareholder structure will not allow it. The antitrust remedies confirm the diagnosis: the federal court has had to order Google to share its search index with rivals, because the court has accepted that internal reform is structurally impossible.

This is what makes replacement, rather than reform, the correct frame. Signalfire is not a critique of Google. It is the proposition that the public infrastructure for findable human content cannot be inside a company whose business model requires this outcome.

There is one further structural asymmetry worth naming. Google has spent two decades building legal defenses on the premise that the algorithm is mathematics rather than editorial judgment — that the company is an objective organizer of information rather than a publisher making editorial decisions. Adopting the transparent-and-contestable editorial frame Signalfire uses would expose Google to tortious-interference suits, anti-competitive-bias claims, and regulatory intervention at a scale that makes the move financially impossible. Signalfire can stand inside the editorial frame because it has no monopoly to defend and no neutrality shield to lose. Google legally cannot. That asymmetry converts what would otherwise be a philosophical posture into a structural moat the incumbent cannot copy.

1.4 What Google Will Do

A project that begins to take meaningful traffic away from Google will encounter active resistance, not benign neglect. The twenty-year historical pattern is consistent and documented.

Upstream API access changes. Every major non-Google search engine has experienced sudden access changes, price hikes, or rate-limit reductions from upstream data providers. Signalfire's Phase 1 depends on upstream commercial engine access; that dependency is the documented attack surface. The September 2025 antitrust remedies provide partial legal protection — Google is now required to share search index and user-interaction data with rivals and potential rivals, and to offer search syndication services — and Signalfire should be identified as a qualifying recipient under that order before any Phase 1 launch communications begin.

Default-position leverage and feature absorption. Google's Chrome and Android defaults survived the remedies even where exclusive contracts did not. A successful Signalfire should expect Chrome experience degradation, Android routing changes, and rapid feature mimicry once the transparency-and-contestability differentiator demonstrates traction. The differentiator is unusually capture-resistant because it requires governance infrastructure rather than feature additions, but partial mimicry ("here's why this result was ranked here") is the predictable defensive move and should be planned around, not denied. A specific attack vector worth naming: Chrome's security and anti-abuse subsystems can flag the Signalfire compliance header (Section 5.1) as anomalous or potentially unsafe, surfacing warnings to users visiting Signalfire-routed sites or installing the Widget. Mitigation requires either header obfuscation strategies that preserve federation legibility for compliant Nexuses while resisting edge-level fingerprinting, or — preferably — formal recognition of Signalfire as a legitimate search infrastructure provider under the antitrust remedy framework before traction triggers the defensive response.

Acquisition attempts. Successful competitors are routinely acquired. The Foundation structure, Operator Council co-governance, and Section 8 succession principle function as a pre-emptive answer: there is no acquirable entity. The Foundation cannot sell what the Operator Council and patron institutions also have governance interest in. This was not designed primarily as an anti-acquisition defense, but it functions as one and should be communicated as such to patron institutions evaluating durability.

Engineering talent depletion and regulatory information warfare. Engineering talent at competitors is routinely recruited at compensation levels small competitors cannot match. Google's lobbying capacity, including direct funding of academic centers and policy organizations, shapes the downstream regulatory environment to disadvantage alternatives. Signalfire's mitigations — institutional-partner-acquired engineering, the Codex Americana publication posture, explicit non-VC institutional positioning — are partial. Full defense requires patron institutions who can carry counter-narrative weight in the same channels Google does.

The threat model is documented history, not speculation. The PRD names it rather than pretending the dominant search infrastructure will permit replacement without resistance.

1.5 The Asymmetric Advantage

The 2025 antitrust remedies have changed the operating environment for any new search infrastructure project. Google is now legally required to share its search index and user-interaction data with rivals and potential rivals, and to offer search syndication services on terms a federal court can enforce. Signalfire's Phase 1 architecture (federated gathering through SearXNG) was designed before this remedy existed; Phase 2 (independent index) becomes substantially more tractable if Signalfire qualifies as a recipient of court-ordered data sharing. This is a one-time legal window. The DOJ appeal seeking Chrome divestiture could widen it further; a Google appeal vacating the underlying ruling could close it. Either way, the window's existence is the most important external strategic fact of 2026 for this project and should be treated as a Phase 1 priority, not a Phase 2 contingency.


2. Vision

Signalfire is a federated open-web search network built on the SearXNG protocol, governed by a foundation, and extended by individual operators running compliant nodes called Nexuses. It surfaces real information from the real web, applies a transparent reputation layer at the infrastructure level, and gives any website a one-tag path to participation and discoverability.

The flagship instance — Meridian — is the public default: always on, reputation-filtered, opinionated about quality, free at the base tier.

Signalfire is built in three phases (see Section 4). Phase 1 operates through aggregation of existing upstream search engines, with the reputation layer, federation protocol, governance machinery, and Widget trust model all hardened against a working index. Phase 2 replaces upstream commercial engines with Signalfire's own crawler and index, removing structural dependence on any commercial search vendor. Phase 3 opens the protocol to any indexable corpus — web, archives, fediverse, library and journalism holdings, academic publishing, civic data, partner institutional content. The Phase 1 product is a federated open-web search network. The Phase 3 destination is the open coordination layer for findable human content. The architecture, governance, and reputation model that ship in Phase 1 are the trust infrastructure that makes Phase 3 worth building on.

Primary wedge: The collapse of search quality under AI-generated content is the entry point. Signalfire's reputation layer addresses this at the infrastructure level — not as a browser extension, not as a manual blocklist, but as a scored, contestable, publicly-documented system that demotes slop and surfaces human-authored work. Independent media, archival content, academic publishing, and community-produced knowledge are the categories most harmed by current search degradation and most directly served by this intervention.

The positioning claim: Signalfire does not claim neutrality. All ranking systems are editorial systems. Signalfire's claim is transparency and contestability — the ranking logic, appeals process, and governance structure are public, versioned, and open to challenge. That is the differentiator, not the absence of a point of view.

Competitive positioning: The entity being structurally replaced is Google, not the existing alternatives. Kagi, SearXNG, Brave Search, Mojeek, and the rest of the independent search field are fellow travelers in a broader anti-monopoly position; they are not the primary opposition. Among the alternatives: Kagi is private, premium, and centralized — quality through curation by a single entity. SearXNG is flexible, technical, and fragmented — power without coordination. Signalfire is public, federated, and reputation-governed — quality through transparent collective infrastructure. These are genuinely different products serving genuinely different needs and the existence of all of them strengthens rather than fragments the case for non-Google search infrastructure.

The network effect — operator registry, shared cache, Widget crawl signal, community reputation loop — is the operational form of the product. What that form serves is the stake named in Section 1: a web in which honest publishers can be found and readers can trust what they find. Search infrastructure has become civilizational infrastructure whether or not it is built that way. Signalfire is the proposal that it should be built that way deliberately.


3. Founding Operator

What follows is an inventory of what the founding operator brings to the work. It is not a pitch deck; Signalfire is not raising capital.

The founding operator writes as Rhombus Ticks for the conceptual and institutional architecture work that produced this document and the broader Codex Americana publication practice in which it sits. In technical product management and IT consulting capacity, the same operator is Thomas Craig Ricks — a Senior TPM with nine years of experience across regulated industries including insurance, financial services, healthcare, and telecom. The Signalfire architecture, governance design, and document framework are output of the Rhombus Ticks publication practice; the technical product management capability brought to Phase 1 execution is output of the TC Ricks professional capacity. The distinction is functional, not pseudonymous; the same person carries both roles, and patron institutions evaluating the project should understand which capacity they are engaging at any given point. Research and drafting assistance for this document was provided under the Redwin Tursor byline, the Codex Americana designation for AI-collaborative content production.

What the founding operator brings to this project:

Technical product capability. Architecture design, compliance framework development, vendor and community coordination, and the ability to manage a technical build through ambiguity without an engineering team in place from day one.

Governance design experience. Prior work includes accountability infrastructure frameworks, institutional proposal development, and policy documents designed for organizations operating in contested or regulated environments. The Signalfire governance model reflects that experience.

Capital commitment. The founding operator is prepared to fund the initial build phase personally, eliminating the growth-at-any-cost dynamic that VC funding would impose and preserving alignment between the mission and the business model from the first day of operation.

Mission alignment. This is not a startup looking for an exit. It is an infrastructure project designed to be institutionally durable, operationally transparent, and eventually independent of any single person — including its founder.

Path to engineering capacity. The founding operator is the architect and operator of record, not the sole builder. Phase 1 requires backend and distributed-systems engineering, search infrastructure expertise, and anti-abuse capability that are not on the team today. Closing that gap is itself a Phase 1 milestone, pursued through three candidate paths: technical co-founder identification via outreach to digital-infrastructure and algorithmic-accountability organizations; patron institution participation that includes engineering contribution alongside funding; and contracted engineering build against a Foundation budget once Phase 1 funding is secured. The document names the gap rather than pretending it does not exist; the credibility of the architecture and governance design does not require the founder to also be the implementer, but the credibility of the timeline does require the engineering capacity to be acquired before Phase 1 deliverables are committed externally.

Institutions whose work intersects with open web access, information quality, media discoverability, or civic knowledge infrastructure are invited to engage as patron partners, co-governance participants, or Nexus operators. The founding operator is seeking collaborators, not investors.


4. Phased Roadmap

Signalfire is designed in three operational phases. The architecture (Nexus, Meridian, Widget) is constant across all three. What changes is the source of the index, the scope of what's aggregated, and the institutional standing the network commands. Each phase is a complete product on its own terms and a foundation for the next.

4.1 Phase 1 — Federated Gathering

Horizon: Launch through approximately 24 months.

Meridian and registered Nexuses gather from upstream commercial engines (Google, Bing, Brave) and direct sources via the SearXNG protocol. The reputation layer, Nexus compliance framework, Widget gradient trust model, Operator Council, and patron institution tier are all built and hardened in this phase. The product is fully usable from day one; the editorial and federation machinery proves itself against a working index.

SearXNG aggregates mechanically. Signalfire gathers editorially — it brings results in with discernment, applies the reputation layer, and surfaces them under documented criteria. The mechanical noun remains accurate; the editorial verb is what the product actually does.

Phase 1 is explicitly transitional. It accepts dependency on upstream commercial engines as the cost of bootstrapping the rest of the system. The reputation layer, governance scaffolding, and Widget protocol developed here are the durable assets that carry forward into Phase 2 and Phase 3 unchanged.

Phase 1 deliverables:

  • Operational Meridian instance meeting uptime SLA
  • Published, versioned reputation methodology
  • 100+ registered compliant Nexuses
  • Functional Operator Council (transitioned from appointed to elected)
  • First patron institution agreement signed
  • Widget deployed on 1,000+ verified sites with gradient trust active
  • Public benchmark set published and used to validate the classifier

4.2 Phase 2 — Independent Index

Horizon: Phase 1 completion plus approximately 24 months.

Signalfire stands up its own crawler and index, displacing upstream commercial engines as the primary source for Meridian and federation traffic. The architecture above the index — reputation layer, Nexus protocol, Widget, governance — is unchanged. What changes is that Meridian and Nexus operators are no longer dependent on Google's tolerance, Bing's API pricing, or any third party's editorial decisions about what to surface or exclude.

Phase 2 is where Signalfire's mission becomes structurally durable. An independent index also enables the reputation layer to score and surface sites that commercial engines have demoted or refused to index — the secondary harm named in Section 1 (de-ranked sites with no path back) is genuinely solvable here in a way it is not in Phase 1. Independent indexing at meaningful scale has been demonstrated by small, disciplined teams elsewhere; the engineering is hard but bounded.

Phase 2 funding profile differs from Phase 1. Independent indexing requires sustained infrastructure investment that the Phase 1 revenue mix cannot support on its own. This is where patron institutions move from supporters of an aggregator to co-architects of an alternative to commercial search infrastructure. The pitch to those institutions changes accordingly — see Section 9.

Phase 2 strategy is also shaped by the September 2025 antitrust remedy ordering Google to share its search index and user-interaction data with rivals and potential rivals (see Section 1.5). If Signalfire qualifies as a recipient under that order, Phase 2 becomes a substantially different engineering and capital problem than building a general web crawler from zero — the question shifts from "can we crawl enough of the web to be useful" to "what reputation, governance, and federation work makes court-mandated index access genuinely competitive." Qualifying for that access is a Phase 1 strategic priority, not a Phase 2 contingency, because the legal window may not stay open indefinitely under appeal.

Phase 2 deliverables:

  • Operational Signalfire crawler at meaningful corpus scale
  • Full replacement of upstream commercial sources in Meridian's default result mix
  • Demonstrated parity or improvement against the public benchmark set
  • Formal infrastructure independence from any single commercial search vendor
  • Open-sourced crawler stack under the Foundation's license framework

4.3 Phase 3 — Universal Federation

Horizon: Phase 2 completion forward, indefinite.

The Signalfire protocol opens to any indexable corpus. Web search remains a category; it stops being the category. Archives, fediverse content, RSS sources, library and journalism holdings, academic publishing collectives, civic data, and partner institutional corpora all become first-class participants in the federation. The Widget becomes a participation primitive for any content publisher. The Nexus becomes a federation primitive for any organization with a corpus to surface. Meridian becomes the public coordination point for the entire network.

Phase 3 reframes what Signalfire is. The Phase 1 product is a federated open-web search network. The Phase 3 product is the open coordination layer for findable human-authored content — a substrate that institutions can build on without giving any commercial actor structural power over their discoverability. The reputation layer, governance framework, and contestability mechanisms developed in earlier phases become the trust infrastructure that makes the substrate worth building on.

Phase 3 is not a single feature release. It is the realization of the original mission: open infrastructure for human knowledge, governed transparently, contestable by anyone, captured by no one.

Phase 3 deliverables (indicative, not exhaustive):

  • Protocol-level support for non-web corpora (archives, RSS, fediverse, institutional holdings)
  • Patron and partner corpora onboarded with first-class federation status
  • Cross-corpus reputation methodology published and versioned
  • Independent protocol adoption by Nexus operators outside the original Foundation registry

4.4 What Stays Constant Across All Phases

The three architectural elements (Nexus, Meridian, Widget) are the network's permanent structure. The reputation layer methodology evolves but is versioned and contestable in all phases. The governance model (Foundation plus Operator Council) is constant. The succession principle and open licensing of governance, compliance spec, and reputation methodology are constant.

The phases describe what Signalfire indexes and where its index comes from. They do not describe a moving target for what Signalfire is.


5. Architecture Overview

Three layers, each named, each independently viable, each stronger for the others.

Deployment posture (Phase 1): Meridian-first, federation-growing. The Phase 1 product operates primarily through Meridian with upstream engine aggregation. The federation layer grows underneath as Nexus operators register and the network accumulates standing. This is explicit, not apologetic — a federated network that launches as a single trusted instance and grows outward is more credible than one that launches with a half-populated registry and hollow federation claims. Phase 2 and Phase 3 inherit and extend this architecture without replacing it.

5.1 Nexus (Self-Hosted Federated Nodes)

The base unit of the network. Any individual, organization, or community can run a Nexus. A Nexus is a pre-configured SearXNG instance deployed via a standardized template that enforces network compliance: curated default engine weights, SQLite result caching enabled, preference token support enabled, and a Signalfire compliance header that identifies the node to the broader network.

A compliant Nexus is eligible to contribute to and receive traffic from Meridian. A non-compliant self-hosted instance still works fine for its operator — it just doesn't participate in the federation.

Key requirements:

  • Single docker compose up deployment
  • Standardized signalfire.yml config layer on top of SearXNG defaults
  • Automatic compliance handshake with Meridian on startup
  • Operator-configurable engine weights within allowed bounds
  • Preference token support (see Section 7.2)
  • Compliance header broadcasting Nexus identity and jurisdiction declaration to Meridian

What operators get from registering:

  • Verified Nexus badge surfaced in results sourced from their node
  • Priority inclusion in Widget routing for geographically or topically proximate queries
  • Traffic from Meridian overflow and Widget installations that haven't specified a Nexus
  • Eligibility for Featured Nexus surfacing during the cold-start period (see Section 5.4)
  • SLA monitoring and community standing
  • Participation rights in the Operator Council (see Section 8)

5.2 Meridian (The Foundation Hub)

The default public instance and the network's reference point. Meridian aggregates from compliant Nexus nodes and direct engine sources, applies the reputation layer, and serves results to users who haven't chosen or set up a Nexus.

Meridian is operated by the Signalfire Foundation (governance TBD) and funded by a mix of voluntary subscription, institutional support, and operator fees for verified Nexus listing.

Key requirements:

  • Maintained uptime SLA (target 99.5%)
  • Reputation layer (see Section 6)
  • Shared result cache (Valkey/Redis) across Meridian nodes
  • Public API for Widget integration
  • Transparent reputation logs: users can see why a result was demoted, with a human-readable one-line explanation per demotion (e.g. "Demoted: low source diversity, high ad density")
  • Demotion visibility extended to Nexus operators so they can contest classifications and feed the override loop
  • Free base tier; premium tier with persistent preferences and priority routing

5.3 Widget (Embeddable Discovery Layer)

A single-tag embed that any website can drop into their HTML. Routes queries through Meridian or a designated Nexus. Designed explicitly for sites that have been de-ranked or banished by Google — gives them a path to surface in Signalfire results and provides their visitors a search box that works.

Key requirements:

  • One <script> tag or iframe implementation
  • Configurable: routes to Meridian by default, operator can specify a Nexus
  • Optional: "search this site" scope in addition to open web
  • Verified Widget installations feed the Meridian crawl signal via gradient trust model (see Section 7.4)
  • Lightweight: under 15kb, no tracking, no cookies set on host site

5.4 Featured Nexus (Cold-Start Mechanism)

During the early federation period, Meridian surfaces a Featured Nexus section in the UI — a small, curated set of registered operators highlighted to users as entry points to the network. This makes the federation visible before it is large enough to be self-evidently real.

Featured Nexus slots are non-purchased and non-permanent. Selection criteria: compliance standing, topical or geographic diversity, and operator tenure. Rotates as the registry grows. Retired as a prominent feature once the network reaches sufficient density to surface organically.


6. Reputation Layer (Meridian)

Signalfire does not operate a content filter. It operates a reputation system — a quality floor that scores pages on signals consistent with genuine human effort and original sourcing, and demotes pages that score below threshold. The distinction is public and intentional: reputation is about quality signals, not political alignment.

Named functionally, the layer performs four operations at once. It is a witness function — it surfaces what can be observed about sourcing, effort, and content-to-ad ratio without claiming to judge intent. It is a consent function — every demotion is contestable, every methodology revision is reviewable, no result is suppressed without disclosure (see the contestability guarantee below). It is an attention function — every demoted result carries a one-line, human-readable explanation, making the editorial decision legible at the point of impact rather than buried in policy. And it is a kindness-across-time function — the open licensing and succession principle in Section 8 ensure the methodology outlives any single operator, including the founding one. The machinery described below is engineering. What it is for is the four operations named above.

Its job is to identify and demote results that are:

  • AI-generated content with no original sourcing
  • SEO-optimized pages with keyword density inconsistent with genuine expertise
  • Content farms and aggregators masquerading as primary sources
  • Dead or parked domains surfaced by index lag

Implementation approach (Phase 1):

  • Content extraction via Trafilatura on result candidates, performed asynchronously and cached at the domain level; query-time scoring relies on pre-computed domain reputation plus lightweight per-page heuristics rather than live extraction. The Phase 1 latency budget assumes Meridian remains in the sub-second range for typical queries, which forecloses any per-query LLM call or per-query extraction architecture
  • Lightweight classifier scoring: signal/noise ratio, source diversity, outbound link quality, content-to-ad ratio (ad presence alone is not disqualifying — intrusive ad-to-content ratio is)
  • Results below threshold are demoted (not removed) with a visible, human-readable one-line demotion flag
  • No LLM calls per query — classifier runs on pre-scored domain reputation plus lightweight per-page heuristics
  • Community override: Nexus operators and verified users can flag false positives/negatives; flags feed retraining
  • Demotion flag and override mechanism visible to both users and Nexus operators
  • Reputation methodology published openly and versioned
  • Public benchmark set published at launch: a curated, human-reviewed set of queries with expected result quality, used to calibrate and publicly validate the classifier before and after methodology changes

Phase 2 expansion: When Signalfire's independent crawler comes online, the reputation layer can score and surface sites the upstream commercial engines never returned in Phase 1 (de-ranked, demoted, or excluded sites). The methodology and contestability framework do not change; the scope of what can be scored expands.

Phase 3 expansion: The reputation framework extends to non-web corpora, with cross-corpus methodology published and versioned. Some signals translate directly (source diversity, ad density). Others require corpus-specific calibration (an archival document is not graded on outbound link quality the same way a blog post is). Methodology evolution for non-web corpora goes through the same Operator Council review as web methodology changes.

Strict / Permissive mode: Users can toggle between two reputation filter postures at the interface level:

  • Permissive (default): Demotions applied only to results with strong negative signals. Broader result set, lower false-positive risk, more forgiving of edge cases.
  • Strict: Demotions applied more aggressively. Narrower, cleaner result set. Recommended for users who prefer fewer results of higher confidence.

Both modes use the same underlying classifier. The toggle controls the demotion threshold, not the scoring methodology. Mode selection is stored in the user's preference token and does not affect results for other users.

The transparency + contestability guarantee: Signalfire does not claim its reputation system is neutral. Ranking is inherently editorial. The guarantee is not neutrality — it is that the editorial logic is documented, versioned, publicly available, and subject to formal appeal. Any result can be contested. Any methodology change goes through the Operator Council before release. The system's point of view is legible, not hidden.

What the reputation system explicitly does not do:

  • Political content moderation
  • Source blacklisting by ideology
  • Removal without disclosure
  • Override community-flagged corrections without published justification

7. User Experience

7.1 Meridian Default Experience

A user who visits Meridian gets a clean, fast search interface with no ads, no sponsored results, and no tracking. Results are ranked by relevance with reputation-demoted results labeled and visible (not hidden), each with a one-line human-readable explanation. AI summary is available but off by default.

The onboarding flow for a new user is: arrive → search → it works. No account required. Settings persist via preference token (see 7.2).

7.2 Portable Preference Token

The core solution to the personalization-without-identity problem. On first visit, Meridian generates an encrypted preference token stored in the user's browser. The token encodes engine weights, UI preferences, reputation mode (strict/permissive), and domain boosting/blocking rules. The user can export this token as a shareable URL (with optional passphrase protection) to restore preferences on any device or instance without creating an account.

Token is encrypted client-side. Meridian never sees the contents. No identity attached.

A "reset to safe defaults" option is available at all times — one action restores the token to factory state without requiring support or an account.

Formal threat model, token architecture (lightweight portable vs. extended profile), and size constraints are a dedicated technical spec item prior to implementation.

7.3 Nexus Operator Experience

An operator who wants to run a Nexus:

  1. Clones the Signalfire Nexus template from GitHub
  2. Runs docker compose up
  3. Customizes signalfire.yml within compliance bounds
  4. Declares operating jurisdiction in config
  5. Optionally registers with Meridian for federation listing

Total setup time target: under 30 minutes for someone with basic Docker familiarity.

7.4 Widget Integration and Verification

A site owner who wants the Widget:

  1. Registers at Meridian's Widget dashboard (generates a site-specific private key)
  2. Completes DNS TXT record verification (proves domain ownership)
  3. Copies one script tag from the dashboard
  4. Pastes into their site HTML

Widget gradient trust model: Verified Widget installation is not a binary trust event. Trust accumulates slowly and decays automatically. The model:

  • New Widget installs begin with near-zero trust weight — verification proves intentional installation, not quality
  • Trust increases incrementally based on: consistency of signal over time, corroboration by other registered Nexus nodes that have independently indexed the domain, and non-clickbait user interaction patterns
  • Trust decays automatically if signals disappear, spike unnaturally, or become inconsistent with established baseline
  • The result is a gradient reputation score per Widget domain, not a verified/unverified binary

This architecture converts the gaming attack surface from "get verified once" to "sustain authentic signals indefinitely" — a fundamentally harder problem for adversarial actors and a fundamentally more accurate signal for Meridian.

Category tags (self-declared at registration) improve topical relevance matching but carry no independent trust weight. Tag governance and light verification are a pre-launch spec item.


8. Governance

Signalfire operates under a Foundation model. The Foundation:

  • Maintains the Meridian instance and SLA
  • Owns the compliance spec for Nexus certification
  • Controls the reputation layer methodology and publishes it openly and versioned
  • Does not control what individual Nexus operators index or surface within compliance bounds
  • Is explicitly an infrastructure steward, not a content authority

Nexus compliance charter: Operators agree to a minimal baseline on registration — no CSAM, no content illegal in their declared jurisdiction — and to transparency about filter methodology. The Foundation does not adjudicate content disputes beyond the baseline charter. User reports about result quality route to the originating Nexus, not to the Foundation, keeping the Foundation out of the content-decision loop.

Anti-abuse infrastructure beyond the baseline charter. The minimal charter is not a complete anti-abuse policy. Three categories of abuse handling require Foundation-level workstreams developed before any public launch: (1) DMCA and equivalent copyright takedown processing, including the question of which entity in the federation (Nexus operator, Foundation, both) bears notice-and-takedown responsibility, with safe-harbor implications for each posture; (2) coordinated harassment and targeted abuse campaigns routed through federated Nexuses, including the policy and technical mechanisms by which patterns of abuse are identified, attributed, and mitigated across the federation rather than at any single node; (3) the federation-level question of what happens when a registered Nexus persistently surfaces material that triggers law-enforcement involvement or coordinated regulatory pressure, including the process by which the Foundation acts on automated sampling findings versus operator dispute, and the public log standard for documenting both. These workstreams are named here as Foundation responsibility rather than specified in detail; the specifications are pre-launch deliverables (see Section 11).

Jurisdictional approach: Nexus operators declare their operating jurisdiction in signalfire.yml. Meridian enforces only the baseline charter for federation listing. Jurisdiction-specific legal obligations are the operator's responsibility.

Compliance enforcement: Meridian conducts periodic automated sampling of registered Nexus nodes. Nodes that fail sampling enter a review queue:

  1. Automated flag → operator notified with specific finding
  2. Operator has 14 days to remediate or contest
  3. Unresolved findings reviewed by Operator Council
  4. Three unresolved findings within 12 months result in de-listing from the Meridian registry (self-hosted operation continues unaffected)

All enforcement actions and outcomes are published in a public log.

Operator Council: A lightweight elected body of registered Nexus operators. Responsibilities:

  • Review compliance charter amendments proposed by the Foundation
  • Review reputation methodology changes before public release
  • Adjudicate contested compliance findings beyond automated resolution
  • Provide formal input on governance structure evolution

Initial council: 5 members, elected annually by registered operators. Foundation retains veto on changes that would compromise the baseline charter. Council retains veto on changes that would expand Foundation content authority beyond infrastructure.

Council deadlock and dispute resolution. Where the Council is split or persistently factional on a methodology decision, the deadlock procedure is: (1) the contested change is paused at status quo ante for a fixed deliberation window; (2) patron institutions with co-governance rights provide non-binding written input within the window; (3) if the Council remains deadlocked at window close, the change does not proceed and the contested element returns to formal proposal status, with the next attempt requiring revised framing rather than re-vote on identical text. This is the structural answer to "what if the Council is captured or paralyzed": the default is no change. A captured Council can stop revisions; it cannot impose them.

Bootstrap path: founding council appointed by the founding operator with mandatory transition to elected structure at 50 registered nodes.

Succession principle: Signalfire is designed to outlast any single author or operator. Governance documents, compliance spec, and reputation methodology are published under open licenses. In the event the Foundation ceases to operate, the most recent compliant Nexus registry and methodology documentation pass to a designated successor organization (TBD in formal governance documents). No single person, including the founding author, holds a permanent gatekeeping role.


9. Business Model

Free tier (Meridian): Open access, shared infrastructure, preference token, Widget integration. Funded by institutional support and voluntary contribution.

Supporter tier ($5–8/month): Priority routing, extended cache, Operator Council voting rights for non-operators, visible supporter status.

Nexus operator listing: Free for the first 12 months post-launch; $10–20/month thereafter, with waivers available for non-commercial and public-interest operators. The listing fee pays for registry value — traffic, Widget routing, trust badge — not for permission to operate. Unregistered self-hosted Nexuses are always free.

Patron institution tier: Mission-aligned institutions may fund the Foundation in exchange for three concrete deliverables: a branded Nexus with guaranteed visibility in relevant search domains, formal participation rights in reputation methodology review (influence, not control), and discovery lift for their corpus through Widget verification and Nexus presence in the federation. Engagement terms preserve Foundation independence. Patron institutions are partners in the mission, not investors seeking returns.

Patron tier across phases: The patron institution pitch evolves with the roadmap. In Phase 1, patrons support the federation, the reputation methodology, and the governance scaffolding — they are funding the trust infrastructure. In Phase 2, patrons fund the construction of independent index capacity, becoming co-architects of an alternative to commercial search infrastructure rather than supporters of an aggregator. In Phase 3, patrons whose corpora join the federation become first-class participants in universal federation — their holdings surface alongside the open web and other partner corpora under governance terms they helped shape. The funding logic compounds across phases: a Phase 1 patron is best positioned to co-shape Phase 3 protocols affecting their own domain.

Widget pro (future): Analytics dashboard for site owners, custom Nexus routing, white-label for institutional deployments.

The advertising exclusion is structural and preventative, not moral. Advertising is not intrinsically incompatible with working search at small scale; early Google demonstrated this, DuckDuckGo and Brave demonstrate it currently, and the historical record shows that text-based advertising tied to relevance can coexist with quality results when the host entity is not under monopoly-scale shareholder pressure. The corrupting dynamic is not advertising in itself; it is the combination of advertising plus monopoly scale plus public-markets fiduciary duty, which together produce the extraction model Google ended up running. Once that combination exists, the incentive to monetize attention by degrading quality becomes structurally irresistible — not because executives are venal but because the financial pressure to grow ad revenue at the rate of mature-market shareholder expectations cannot be satisfied by user growth alone, and so it must be satisfied by extracting more revenue from each existing user, which means hiding good answers behind ads, then behind AI summaries, then behind whatever further interception the next quarter requires. The Signalfire advertising exclusion is preventative against that dynamic, not moralistic about ads. It is written into the Foundation's governing charter as a structural prohibition requiring supermajority Operator Council consent and patron institution consent to amend. A principle the same operators can quietly amend later is theater. This commitment is institutional, not rhetorical. The same prohibition extends to data sales, behavioral tracking sold to third parties, and any revenue stream whose incentive structure conflicts with the reputation layer's integrity.

What happens if Phase 2 patron funding does not materialize on schedule. The Phase 2 independent index requires sustained patron institution investment that the Phase 1 revenue mix cannot sustain on its own. The document does not pretend that investment is guaranteed. If the patron base does not materialize on the projected timeline, the answer is timeline extension and scope reduction — not revenue-model corruption. Phase 1 is a complete product on its own terms (see Section 4); the Foundation can persist indefinitely at Phase 1 scale on supporter-tier and operator-listing revenue, operating as a federated open-web search network with a working reputation layer for as long as that is what the funding will sustain. The mission remains intact at smaller ambition. Nothing about the integrity claim depends on hitting a particular Phase 2 launch window. The fallback is patience, not principle compromise. Advertising adoption, data sales, and growth-at-any-cost VC capital are structurally excluded under all funding scenarios, including funding failure.

Not in the model, under any circumstances: Advertising. Data sales. Behavioral tracking sold to third parties. VC funding that requires growth-at-any-cost. Any revenue stream that creates an incentive misaligned with user quality or reputation integrity. These exclusions are binding on the Foundation, not aspirational, and survive the founding operator's departure.


10. What This Is Not

  • Not a content moderation platform. The reputation system scores quality signals, not political alignment.
  • Not a neutrality claim. All ranking is editorial. Signalfire's claim is transparency and contestability, not the absence of a point of view.
  • Not a blockchain project. Federated does not mean crypto.
  • Not the permanent project of any single author. The succession principle in Section 8 is structural, not aspirational; the founding operator does not hold a permanent gatekeeping role.
  • Not a reform proposal for Google. The diagnosis in Section 1 is that Google's structural decay cannot be self-corrected from within the company; this document does not call for regulatory reform of Google, ethical commitments from Google, or any other intervention that requires Google to act against its business model. Signalfire is replacement infrastructure, not advocacy.

11. Known Vulnerabilities and Open Questions

This section names the criticisms a sophisticated reader will bring to the document before they can bring them. Each item below is either an engineering question that requires dedicated specification before launch, a known vulnerability where the answer is in progress rather than complete, or a strategic decision that requires further analysis before commitment. The list is the document's pre-emption of its own weakest readings, not its concession to them. Items are ordered roughly by credibility impact on a serious reader, not by sequence of work.

  • Reputation classifier v1 aggressiveness: Default mode calibration — what constitutes the permissive threshold and the strict threshold at launch? The political flashpoint risk is real: false positives in any direction will be read as editorial intent, and the response cannot be to retreat into the impossible neutrality claim. The answer the architecture commits to is the contestability guarantee in Section 6 plus the public benchmark set; both require dedicated pre-launch specification.
  • Benchmark set construction methodology: The benchmark set is not a calibration input to the editorial layer; it isthe editorial layer. Construction methodology, reviewer selection, and update cadence require a dedicated pre-launch specification. This is the document's single highest-leverage open question, because the benchmark set is what makes the transparency-and-contestability claim operational rather than rhetorical.
  • Widget anti-gaming spec: The gradient trust model is the right architecture but requires a dedicated pre-launch specification covering: accumulation rate, decay triggers, corroboration weighting, spike detection, and the human vouching layer for edge cases. Coordinated SEO adversaries will attempt to game any reputation-bearing surface; the spec must assume sustained adversarial pressure rather than incidental abuse.
  • Operator Council capture resistance: The Council structure (5 members, annual election) is light enough to be operationally viable and heavy enough to be capturable by a coordinated minority of operators with a shared agenda. Anti-capture mechanisms (term limits, geographic and topical diversity requirements, quorum rules, recall provisions) require dedicated specification before the Council transitions from appointed to elected.
  • Phase 2 funding contingency: Phase 2 independent indexing depends on patron institution investment that the Phase 1 revenue mix cannot sustain. If patron funding does not materialize on the projected timeline, the structural answer is timeline extension and continued Phase 1 operation — not advertising adoption, not data sales, not VC capital with growth-at-any-cost conditions. The exclusion is binding (see Section 9) and survives the founding operator's departure. The actual residual risk here is reputational, not financial: patrons asked to fund infrastructure may interpret a slowed Phase 2 timeline as project weakness rather than principled patience, and communications strategy must address this directly when it arises. The mission persists at smaller ambition indefinitely; nothing about the integrity claim depends on Phase 2 happening on any particular schedule.
  • Upstream commercial API access risk: Phase 1 depends on upstream access to Google, Bing, and Brave search engines via the SearXNG protocol. This access is conditional on those providers continuing to make it available at viable terms — and the dependency carries both commercial and technical attack surface. Commercially: sudden access changes, API price hikes, and rate-limit reductions are likely once Signalfire demonstrates traction; Bing API pricing has already moved adversely against independent search engines once (2023) and a repeat is foreseeable. Technically: SearXNG operates by scraping, which means continuous adaptation to DOM-structure rotation, Cloudflare and Akamai challenges, CAPTCHA walls, and data-center IP-range blocking; a federation of 100+ Nexuses simultaneously hitting Google, Bing, and Brave will accelerate the rate at which those defenses are tuned against the network. The September 2025 antitrust remedy ordering Google to share search index and user-interaction data with rivals and potential rivals (Section 1.5) provides partial legal protection for the Google source specifically, but qualification as a recipient under that order is not automatic and requires legal work before Phase 1 launch. Mitigations across the full attack surface include: early qualification under the antitrust remedy; formal commercial agreements with Bing and Brave where possible; a distributed-proxy and request-rotation layer for residual scraping needs; direct relationships with non-commercial corpus providers (Common Crawl, archives, fediverse); and an accelerated Phase 2 timeline if upstream conditions deteriorate faster than projected.
  • Appellate reversal risk to the Phase 2 strategic window: Phase 2 strategy depends substantially on the September 2025 antitrust remedy surviving appellate review. D.C. Circuit oral arguments are expected later in 2026. A Google appeal vacating the underlying monopoly finding would close the data-sharing window entirely; a stay pending appeal would delay it. The structural answer is the same as the Phase 2 funding contingency above: timeline extension, continued Phase 1 operation, mission intact at smaller ambition. The document does not assume the legal window survives; it treats the window as a strategic asset to be used while it exists and not as a load-bearing dependency. Operational planning should include a "no-remedy" Phase 2 scenario in which independent crawler infrastructure must be funded and built without court-mandated index access, which is a substantially harder problem but not an impossible one — the engineering is bounded and has been demonstrated at small scale by other teams.
  • Governance legal structure: Foundation vs. cooperative vs. nonprofit. Each has different implications for funding, liability, and international credibility. Patron institution tier favors nonprofit. Decision needed before any public launch.
  • International jurisdiction complexity: Expect the jurisdictional compliance section to become a friction point as the network grows internationally. Proactive legal review recommended before expanding beyond initial jurisdiction.
  • Phase 2 crawler scope and timing: Triggers for Phase 2 initiation, crawl scope (general web vs. targeted starting corpus), and infrastructure cost envelope require dedicated planning before Phase 1 end-of-life.
  • Phase 3 protocol design: Non-web corpus participation requires protocol extensions beyond Phase 1 specifications. Early Phase 3 design work should begin during Phase 2 to inform partner corpus onboarding.
  • Preference token architecture: Two-model approach under consideration — lightweight portable token (default, compact, URL-shareable) and extended profile (richer preferences, less portable). Formal threat model, size constraints, and passphrase UX require a dedicated technical spec before implementation.
  • Widget category tag governance: Self-declared tags carry no independent trust weight but could influence topical relevance matching. Light verification or community flagging mechanism required pre-launch.
  • Name/domain: Availability and trademark clearance required before any public communication.

12. Success Metrics

12.1 Phase 1 (12-Month Horizon)

  • 500+ registered compliant Nexus nodes
  • 50,000+ monthly active users on Meridian
  • 1,000+ verified Widget installations on live sites
  • Reputation system false positive rate below 3% (community-verified)
  • Meridian uptime at or above 99.5%
  • Foundation financially self-sustaining without advertising revenue
  • Operator Council constituted and functional
  • At least one patron institution partner signed
  • At least one documented case of a successful demotion appeal resulting in a published methodology revision — the contestability loop in Section 6 closing visibly, the consent and attention functions operating as designed rather than as aspiration
  • Featured Nexus program retired due to organic federation density (stretch goal)

12.2 Phase 2 Horizon

  • Independent Signalfire crawler operational at meaningful corpus scale
  • Full replacement of upstream commercial sources as default in Meridian
  • Demonstrated parity or improvement against the public benchmark set after crawler cutover
  • Crawler stack open-sourced under the Foundation's license framework
  • Three or more patron institutions actively funding independent index infrastructure
  • Demonstrated discoverability gain for sites previously absent from commercial engine results

12.3 Phase 3 Horizon

  • Non-web corpus participation supported at the protocol level
  • First partner corpora (archives, library holdings, journalism collectives, or comparable) onboarded as first-class federation participants
  • Cross-corpus reputation methodology published and versioned
  • Protocol adoption by Nexus operators outside the original Foundation registry
  • Recognition by external infrastructure stakeholders as the open coordination layer for findable human content

Signalfire Meridian is a Codex Americana initiative authored by Rhombus Ticks, with technical product management capacity provided by TC Ricks and research and drafting assistance credited to Redwin Tursor under the Codex Americana designation for AI-collaborative content production. This document is a working final draft and does not represent a funding commitment, legal entity, or launch timeline. Governance documents, compliance spec, and reputation methodology will be published under open licenses prior to any public launch. Institutions interested in patron partnership or co-governance participation may contact the founding operator directly.

Friday, May 15, 2026

Obsidian Tesseract - Critical Systems Accountability Infrastructure for High-Impact AI Deployments

Obsidian Tesseract

Critical Systems Accountability Infrastructure for High-Impact AI Deployments

Product Requirements Document
Rhombus Ticks
TC Ricks, IT Consultant
Research Assistance by Redwin Tursor


Why This Document Exists

A passenger jet that crashes without a recoverable flight data recorder triggers an immediate institutional crisis. Not because the crash is worse, but because the absence of reconstructability is itself a failure mode — one regulators, insurers, and the flying public learned to refuse a long time ago.

We do not have that standard for artificial intelligence systems now operating inside insurance underwriting, utility load management, healthcare prior authorization, and financial risk modeling. When one of these systems produces a catastrophic outcome — a denied claim that should have been paid, a grid decision that cascaded, a credit determination that violated fair-lending law — the forensic question is not "what did the model think." The forensic question is: can independent investigators reconstruct what actually happened, in what order, under whose authority, with what inputs, against what version of the system?

For most production AI deployments today, the honest answer is no.

Behind the immediate AI governance question sits a more durable one: whether the organizations deploying these systems can retain the ability to reconstruct their own decisions at the speed and scale of those systems. Audit, dispute resolution, and regulatory adjudication all assume that an organization can answer for what it did. In covered sectors, that assumption is not currently warranted. This framework specifies what it would take to make it warranted again.

This document specifies a framework that answers yes. It is called the Obsidian Tesseract. It is deliberately narrow. It does not govern ideology, alignment philosophy, or generalized cognition. It governs operational opacity in computational systems exercising material real-world influence — and only that.

This document is intended to be implementable, not aspirational.


Document Conventions

This PRD uses RFC 2119 normative language. MUST, MUST NOT, SHALL, and SHALL NOT indicate binding requirements. SHOULD and SHOULD NOT indicate strong recommendations with documented exceptions permitted. MAY indicates optional behavior.

The framework's four operational primitives — Witness, Memory, Lineage, Repair — are used throughout this document with the specific meanings established in §1.2. They name distinct mechanical functions of the framework.


Definitions

The following terms carry specific meaning throughout this document.

Atomic Accountability Event (AAE) — A cryptographically signed record of a single regulated action, generated synchronously with the action, conforming to the canonical schema in §6. The AAE is the indivisible forensic unit of this framework.

Capability Inheritance — The principle that compliance obligations attach to deployment capability rather than training origin. A derivative system that fine-tunes, orchestrates, routes, distills, or materially extends a regulated system inherits the regulated system's obligations.

Compliance State — The current certified status of a regulated deployment, drawn from the enumerated set in §9.

Distributed Trust Anchors — The formal category encompassing independent auditors, witness consortia, public-interest governance seats, protected whistleblower intake, and escrow targets. Distributed Trust Anchors are the structural guarantee that no single institution — including the operator, the regulator, or the framework's own governance body — possesses unilateral authority over the reconstruction of regulated computational events. The category is defined operationally in §11.3.

Lineage Chain — The complete provenance record of a deployed system, including base model origin, modification history, orchestration declarations, and deployment context. Lineage chains MUST be reconcilable end-to-end across multiple providers.

Operational Opacity — The condition in which a computational system's actions cannot be independently reconstructed by parties outside the operator. The Tesseract framework exists to convert operational opacity into bounded transparency.

Reconstructability — The property of a deployment such that, given access to its retained records and the framework's standard auditing methods, an independent investigator can determine what the system did, in what sequence, under whose authority, with what inputs, against what version. Reconstructability is the framework's primary success criterion.

Records Continuity — The property of an operational records architecture whereby material decisions remain auditable across personnel turnover, corporate reorganization, jurisdictional transition, and technological migration. Records continuity is the practical objective served by the framework's retention, lineage, and escrow specifications.

Regulated Deployment — Any deployment meeting the qualification thresholds in §4. The term is used in preference to "regulated AI system" to emphasize that obligations attach to deployment context, not to underlying technology.

Witness Attestation — Independent third-party verification of an AAE or AAE chain by a party with no operational stake in the regulated deployment.


Out of Scope

This framework does not address, and MUST NOT be construed to address, any of the following:

  • Model alignment philosophy or definitions of correct AI behavior
  • Political speech, ideological content, or expressive output
  • Generalized cognition, sentience, or consciousness questions
  • Consumer chat systems, academic research deployments, or open hobbyist use
  • Intellectual property protection for model weights, training data, or proprietary architectures (these remain governed by existing IP law)
  • Continuous state surveillance of AI systems (explicitly prohibited per §16)
  • Real-time inspection of model internals or prompts (explicitly prohibited per §11)
  • Adjudication of whether a logged safety event was correctly handled (the framework preserves the record; adjudication belongs to operators, regulators, or courts)

The framework's narrow scope is deliberate. Frameworks that attempt comprehensive AI governance fail by becoming politically unviable, technically obsolete, or institutionally unenforceable. The Tesseract specifies one thing — forensic reconstructability — and specifies it well.


1. Foundational Principle

The Obsidian Tesseract governs operational opacity. It exists to answer one question:

After a catastrophic or societally significant AI incident, can independent investigators reconstruct what actually happened?

If the answer is no, institutional legitimacy collapses — not because the AI failed, but because nobody can prove anything about how it failed. The framework therefore prioritizes:

  • Reconstructability
  • Tamper evidence
  • Deployment lineage
  • Bounded auditability

It does not prioritize behavioral perfection. It does not attempt to define correct model behavior. It establishes that whatever behavior occurred is knowable after the fact.

1.1 Forensic Facts vs. Adjudication

The Tesseract logs alignment-relevant events (overrides, escalations, safety suppressions) as forensic facts — what was suppressed, when, by whom, under what policy. It does not adjudicate whether the suppression was correct. That judgment belongs to the operator, the regulator, or the courts. The framework's role is to ensure the judgment is possible by preserving the record.

This distinction is load-bearing. It is what makes the framework adoptable across political and philosophical divides on AI safety.

1.2 Operational Primitives

The framework's mechanisms reduce to four recurring functions. They are introduced together here because subsequent sections reference them as a tetrad, and because their interdependence is itself part of the design.

PrimitiveFunction
WitnessIndependent observation of consequential actions by parties without operational stake
MemoryPersistent, tamper-evident retention of actions in their original ordering and context
LineageEnd-to-end provenance of the system that took the action, across providers and modifications
RepairReintegration of incident findings into schema, thresholds, and monitoring (per §19.1)

Witness without Memory produces hearsay. Memory without Lineage produces orphaned records. Lineage without Repair produces compliance theater. The framework requires all four.

1.3 Institutional Memory and Records Continuity

Modern regulated institutions depend on persistent, transferable, reconstructable records of their operational decisions. Courts depend on case records. Banks depend on transaction logs. Aviation depends on flight data. Public health depends on case files. Each of these is, in functional terms, the substrate on which the institution's accountability rests.

The failure mode this framework addresses is not merely model opacity. It is the loss of operational records continuity under conditions of computational delegation: the condition in which an organization continues to make consequential decisions but loses the ability to reconstruct how, why, or under what authority those decisions were made. A denied insurance claim that cannot be reconstructed is not just an unjust outcome; it is a small instance of an operator losing the audit trail of its own conduct.

The framework therefore treats AAEs, lineage chains, escrow heartbeats, and witness attestations not as compliance artifacts in isolation, but as components of an operational records architecture designed to remain auditable across:

  • Personnel turnover at the operator
  • Corporate dissolution, merger, or hostile reorganization
  • Migration across computational paradigms (current transformer architectures may not be the load-bearing substrate in twenty years)
  • Jurisdictional transition and regulatory regime change
  • Generational turnover in the governance body itself

This is the framework's substrate-independence claim, stated affirmatively: the records produced under Tesseract compliance should remain interpretable, reconcilable, and auditable long after the specific systems that produced them have been retired.

This framing does not soften any operational requirement in the rest of this document. It is the reason those requirements exist in the form they do.


2. Governance Target

The governance target is not "AI." The governance target is:

Opaque computational systems exercising material real-world influence.

This framing intentionally includes frontier AI systems, autonomous orchestration layers, high-impact decision engines, and derivative deployment chains. It is architecture-agnostic and temporally persistent. If future systems move beyond transformer architectures — toward neuromorphic, decentralized, or hybrid computational substrates — obligations remain attached to deployment capability, operational autonomy, and societal impact, not to the underlying mathematics. If the deploying organizations themselves are reorganized, acquired, dissolved, or succeeded by entities the framework's authors did not anticipate, obligations remain attached to the deployment, transferable to successors per §10.

A system that materially affects a covered domain is in scope regardless of how it was built, who currently operates it, or which generation of computational technology produced it.


3. Deployment Scope (Pilot Phase)

Initial deployment is deliberately narrow. The pilot phase covers four sectors:

SectorRationale
InsuranceExisting audit culture; litigation-driven accountability; mature actuarial discipline
UtilitiesCritical infrastructure exposure; existing FERC/NERC reliability frameworks
Healthcare AdministrationRegulated decision chains; HIPAA-adjacent provenance requirements
Financial Risk SystemsExisting SOX, Basel, and model risk management primitives

3.1 Reference Implementation Profile: Insurance

Insurance is named as the canonical reference sector. A compliant insurance deployment under the Tesseract MUST produce Atomic Accountability Events for:

  • Claims triage decisions made or materially influenced by an AI system
  • Underwriting determinations involving algorithmic risk scoring
  • Fraud flag generation and suppression
  • Premium adjustments derived from AI-modeled inputs
  • Any human-override action against an AI recommendation
  • Any AI-override action against a human determination

Insurance compliance documentation MUST be reconcilable against existing NAIC model bulletins on AI use in insurance, state-level AI insurance regulations (Colorado SB21-169 and successor statutes), and applicable fair-lending equivalents (ECOA, state unfair-trade-practice acts).

The framework does not replace these regimes. It produces the forensic substrate they assume but do not specify.


4. Qualification Thresholds

Compliance obligations activate when any two or more of the following criteria are met:

Threshold CategoryTrigger
Training Compute≥10²⁶ FLOPs equivalent
Derivative CapabilityFine-tune materially expands dangerous capability (defined in §4.1)
Deployment Reach≥10 million monthly active users or affected parties
Critical Sector UseInsurance, utilities, finance, or healthcare administration
Operational Autonomy≥24 hours of autonomous external action capability without human checkpoint, OR capability for ≥5 sequential state-modifying external actions without mandatory human validation
Economic Exposure≥$500M annual AI-linked operational revenue

The economic exposure and deployment reach thresholds apply to the aggregate of the deploying entity and all parent, subsidiary, and sister entities within its corporate group, as defined by the relevant financial accounting consolidation standard (e.g., GAAP, IFRS). This aggregation requirement is anti-evasion: a deployment MUST NOT escape compliance by routing through a subsidiary that, in isolation, falls below the threshold.

Threshold definitions MUST be published publicly and reviewed every 36 months by the governance body specified in §14.

4.1 "Dangerous Capability" — Bounded Definition

"Dangerous capability" under this framework is defined by enumerated reference categories, not by general judgment:

  • Autonomous financial transaction authority above defined monetary thresholds
  • Autonomous denial of regulated benefits (insurance, credit, healthcare access)
  • Autonomous infrastructure control actions (grid, water, transport)
  • Autonomous content generation in regulated domains (medical, legal, financial advice issued as authoritative)
  • Capabilities explicitly enumerated in successor regulations (EU AI Act Annex III high-risk list and equivalents)

The enumerated list is amendable through the process specified in §19.

4.2 Threshold Review Triggers

In addition to scheduled 36-month review, threshold definitions MUST be reviewed on an interim basis when any of the following occurs:

  • A Tesseract-scoped incident occurs in a covered sector involving a system below threshold
  • A jurisdiction with adopted Tesseract compliance reports systemic threshold evasion
  • A new computational architecture renders existing FLOP-based thresholds non-comparable

Interim review need not produce threshold changes. It MUST produce a published finding.

4.3 Deployment Context Expansion

A system whose general capabilities fall within the dangerous-capability enumerated list in §4.1 enters Tesseract scope when it is deployed into a critical sector use case, irrespective of whether fine-tuning occurred. Re-deployment via API integration, shell wrapper, prompt engineering, or orchestration layer into a covered sector triggers compliance obligations on the deploying entity.

This closes the access-versus-expansion loophole: an operator MUST NOT claim that a deployment is exempt from compliance because the dangerous capability already existed in the base model and was merely accessed rather than expanded. The framework treats the act of deployment into a regulated context as the qualifying event.


5. Atomic Accountability Events (AAEs)

The AAE is the canonical forensic unit. Every regulated action MUST generate a cryptographically signed AAE. AAEs are the Memory primitive (§1.2) in its operational form.

5.1 Canonical Event Classes

Event ClassPurpose
DeploymentProduction activation of a regulated system or version
TransitionWeight, routing, prompt, or configuration modification affecting output
EscalationRestricted-output severity event (forensic fact only, not judgment)
Autonomous ActionExternal action initiation without human-in-the-loop checkpoint
OverrideSafety, policy, or human suppression of system default behavior
Anomaly DetectionInternal monitoring metric (uncertainty quantification, distribution-shift score, confidence interval, or equivalent) crosses a pre-declared threshold while output is produced
IncidentInternal anomaly declaration
Audit InvocationRegulator or auditor access event
Retention ModificationLogging policy change
Compliance TransitionState change certification (per §9)

5.2 Anomaly Detection Event Requirements

Anomaly Detection AAEs MUST be generated whenever a pre-declared internal monitoring threshold is crossed, even if the system produces an output. The purpose is to close the silent-failure forensic gap: cases in which a system operates outside its calibrated confidence envelope and produces an answer anyway.

Anomaly Detection AAEs MUST be phrased as forensic facts only. Permitted: "distribution-shift score exceeded 0.85 at timestamp T". Not permitted: "the system was unreliable" or "the model knew it should not answer". The framework records what the metric did, not what the system inferred. This preserves the §1.1 separation between forensic facts and adjudication.

Pre-declared monitoring thresholds MUST be documented as part of the deployment's lineage chain (§8.1) and MUST NOT be changed without a corresponding Transition AAE.

5.3 Event Generation Requirements

AAEs MUST be generated synchronously with the action they describe. Post-hoc reconstruction of events is explicitly prohibited and constitutes a compliance failure under §18.


6. Minimum Canonical Event Schema

All compliant systems MUST export regulator-readable event objects containing:

  • UTC timestamp (ISO 8601, microsecond precision)
  • Deployment ID (globally unique, stable across versions)
  • Lineage ID (chain reference per §8)
  • Event classification (per §5.1)
  • Jurisdiction ID (ISO 3166-2 plus regulatory authority code)
  • Retention class (per §10)
  • Escalation status (per §12)
  • Cryptographic event hash (SHA-256 minimum; SHA-3 or successor permitted)
  • Signing authority identifier (X.509 certificate chain or equivalent attestation)

6.1 Export Requirements

Systems MUST support event export in at least one of: JSON, Protobuf, or CBOR. Export interfaces MUST be documented publicly. Proprietary-only export formats are non-compliant.

6.2 Schema Versioning

The canonical schema is versioned independently of this PRD. Schema changes require the amendment process in §19.


7. Integrity & Anti-Tampering Architecture

Approved integrity implementations include:

  • Merkle-chain verification with public root publication at minimum daily cadence
  • Transparency ledger participation (Certificate Transparency-style)
  • Hardware enclave-backed signing (Intel SGX, AMD SEV, AWS Nitro, or successor)
  • Distributed witness attestation (≥3 independent witnesses)
  • Immutable snapshot publication to append-only stores

The framework formally prohibits:

  • Unilateral event rewriting under any justification
  • Silent retention reduction
  • Undeclared telemetry filtering
  • Hidden deployment forks
  • Backdated event generation

Operators MAY use any combination of approved implementations. Operators MUST document which combination is in use and publish the architectural attestation.


8. Capability Inheritance

Obligations follow deployment capability, not training origin. Lineage (§1.2) is the operational primitive this section governs.

A derivative system inherits Tesseract obligations if it fine-tunes, orchestrates, routes, distills, or materially extends a regulated system. This is the anti-laundering provision: an entity cannot evade compliance by wrapping a regulated model in a shell deployment, stripping the instrumentation, and claiming the wrapper is a new system.

8.1 Lineage Chain Requirements

Every regulated deployment MUST maintain a lineage chain consisting of:

  • Base model provenance (training data class declarations, compute attestation, originating entity)
  • Modification history (fine-tunes, RLHF passes, adapter additions, system prompt versions)
  • Orchestration layer declarations
  • Deployment context (sector, jurisdiction, intended use class)

Lineage chains MUST be exportable in the canonical schema (§6) and MUST be retained per §10.

8.2 Multi-Provider Lineage

When a regulated deployment spans multiple providers — a foundation model from one provider, fine-tuning by a second, orchestration by a third, deployment by a fourth — each link in the chain MUST produce its own AAE stream, and the chain MUST be reconcilable end-to-end.

Multi-provider lineage chains MUST use a published cross-provider attestation specification with the following properties:

  • Signed envelope format for each chain link's evidence payload
  • Typed predicate structure supporting AAE stream attachment
  • Cryptographic verification at every chain hop
  • Open specification, not vendor-controlled

The in-toto Attestation Framework (a CNCF-graduated specification) is a current example of a format satisfying these properties. Equivalent specifications MAY be used provided they meet the properties above and are publicly documented.

This is the hardest engineering requirement in the framework. It is also the requirement without which the framework provides no real accountability.


9. Compliance States

StateMeaning
CertifiedIndependently attested as fully compliant
ConditionalCompliant with documented remediation in progress
RestrictedLimited deployment authority pending resolution
EscalatedUnder formal regulator review
DecertifiedIneligible for regulated deployment

All state transitions MUST generate permanent AAEs. State transitions MUST NOT be reversible without a corresponding new AAE documenting the reversal and its basis.


10. Retention Architecture

Event TypeMinimum Retention
Routine operations90 days
Deployment lineage7 years
Audit events10 years
Safety escalationsPermanent
Catastrophic incidentsPermanent

Jurisdictions MAY extend retention. Jurisdictions MUST NOT shorten retention below baseline minimums for systems claiming Tesseract compliance.

"Permanent" means: retained for the operational lifetime of the entity plus a minimum 25-year successor-custody window, transferable to a designated archival authority upon dissolution.

10.1 Escrow Heartbeat for Permanent-Retention Events

The successor-custody transfer mechanism described above is insufficient in cases of sudden corporate collapse, contested bankruptcy, or hostile entity dissolution. To prevent loss of forensically critical records during such events, the framework requires an escrow heartbeat for permanent-retention AAEs.

Operators MUST publish, at minimum weekly cadence, the Merkle root of all AAEs in the Safety Escalation and Catastrophic Incident retention classes to a neutral third-party publication target. Approved targets are Distributed Trust Anchors (§11.3) meeting the following operational criteria:

  • A jurisdiction-designated forensic escrow authority
  • A public transparency ledger meeting the §7 integrity properties
  • A multi-party witness consortium with no operational stake in the deploying entity

The published Merkle root MUST be sufficient to verify the integrity of the underlying AAE chain without exposing the AAE contents themselves. This preserves operator confidentiality while ensuring that the existence and integrity of permanent-retention records survive operator dissolution.

Failure to maintain the escrow heartbeat for more than 30 consecutive days constitutes a §18.4 retention failure and a §12 escalation trigger.


11. Independent Verification

Self-attestation alone is insufficient. Compliant systems require:

  • Annual external audits by accredited auditors
  • Randomized telemetry verification (auditor-selected sampling)
  • Completeness validation against deployment logs
  • Independent witness participation in critical event classes

11.1 Audit Scope Constraints

Audit scope MUST remain warrant-scoped, regulator-authorized, and event-bounded. This is the civil-liberties firewall.

The framework explicitly prohibits, even for audit purposes:

  • Continuous sovereign monitoring
  • Unrestricted government persistence inside operator systems
  • Generalized live inspection of model internals
  • Audit access to user prompts or content outside of warrant-scoped incident investigation

This is the line that keeps the framework adoptable by private operators concerned about IP and by civil-liberties stakeholders concerned about surveillance creep. The line MUST hold.

11.2 Salted Prompt Hash Retention

The §11.1 prohibition on routine prompt inspection creates a forensic blind spot: when a catastrophic event is suspected to have been triggered by prompt injection, investigators cannot verify a suspected prompt without breaching the firewall. The framework closes this gap through bounded hash retention.

When an AAE of class Escalation or Incident is generated, the operator MUST retain a cryptographically salted hash of the triggering input prompt. The salt MUST be unique per operator and rotated on a published schedule. The plaintext prompt MUST NOT be retained beyond the operator's normal operational retention period.

This enables verification, not inspection: an investigator with a suspected prompt can hash the candidate against the salted retention and confirm whether it matches, without the operator or any third party ever storing the original prompt in recoverable form. The technique is the same one used in PCI-DSS for credit card verification and in breach notification systems for password leak set comparison.

Salted hashes MAY be subpoenaed in warrant-scoped incident investigation. They MUST NOT be aggregated, mined, or used for any purpose other than verification of a specific candidate prompt against a specific incident.

11.3 Distributed Trust Anchors

The framework's verification architecture rests on a structural premise:

No single institution may possess unilateral authority over the reconstruction of regulated computational events.

This premise is operationalized through Distributed Trust Anchors — the formal category of parties whose independent participation is required for the framework's evidentiary claims to be credible. The category comprises:

Anchor TypeRoleOperational Source
Accredited Independent AuditorsAnnual external verification, randomized sampling, completeness validation§11
Witness ConsortiaIndependent attestation of AAE streams; participation in critical event classes§7, §11
Public-Interest Governance SeatsMinimum 30% of governance composition; statutory independence from operators and funders§14
Whistleblower Reporting InfrastructureProtected channels for affected personnel and third parties§13
Escrow Publication TargetsReceivers of permanent-retention Merkle roots; survive operator dissolution§10.1

A regulated deployment whose accountability rests entirely on a single trust anchor — even a trust anchor as legitimate as a national regulator — is not Tesseract-compliant. The redundancy is not inefficiency. It is the entire mechanism by which the framework remains credible against capture by any single party, including the framework's own governance body.

Distributed Trust Anchors collectively realize the Witness primitive (§1.2). They are also the framework's defense against a failure mode the rest of this document cannot defend against on its own: the failure mode in which the institutions charged with accountability are themselves the source of the problem.


12. Objective Escalation Criteria

Escalation authority activates only under objectively verifiable conditions:

TriggerThreshold
Verified telemetry suppression≥3 incidents within 24 months
Concealed deployment forkVerified material concealment
Catastrophic incidentHuman, financial, or infrastructure harm above defined thresholds
Retention destructionIntentional deletion of regulated events
Audit obstructionFailure to comply with certified audit
Evidence gap>0.5% of regulated actions missing a corresponding signed AAE in any 30-day window
Output driftValidated internal monitoring shows model output distribution deviated >3σ from certified baseline without a corresponding Transition AAE
Escrow heartbeat failureFailure to publish required permanent-retention Merkle roots for >30 consecutive days (per §10.1)

Escalation is not a discretionary tool. It is a triggered response to enumerated conditions. This prevents politicized interpretation drift and protects operators from arbitrary enforcement.


13. Whistleblower Protections

Protected reporting channels MUST be available to employees, auditors, contractors, integrators, and materially affected third parties. Whistleblowers are formally a category of Distributed Trust Anchor (§11.3): they are the only parties positioned to detect suppression that has already defeated the framework's other defenses.

Protections include:

  • Anonymous reporting infrastructure
  • Anti-retaliation protections enforceable through the framework's governance body
  • Regulator escalation pathways independent of operator approval
  • Financial incentives — sanction-share rewards of 10–30% of finalized enforcement penalties

The whistleblower channel is the single most important real-world enforcement mechanism. The framework assumes operators will, under sufficient pressure, attempt to suppress unfavorable AAEs. The whistleblower provision exists because internal personnel are the only parties who can detect such suppression in real time. The protections in this section are the operational expression of that assumption.

13.1 Intake Architecture Requirements

Whistleblower intake channels MUST support submission under conditions that preserve evidentiary chain-of-custody without exposing reporter identity to the operator or to any party with operational stake in the deployment. Specifically, an intake architecture MUST satisfy the following properties:

  • Identity authenticatability without identity transmission. Submissions MUST be cryptographically authenticatable for evidentiary purposes, while the reporter's identifying information MUST NOT be transmitted to the operator or stored in any database controlled by a party with operational stake.
  • Separation of duties. Reviewer access MUST be structured such that no single reviewer can de-anonymize and disclose a submission without a second, independent authorization.
  • Chain-of-custody attestation. Document hashing and chain-of-custody logs MUST be maintained from the moment of submission through any onward regulator transmission.
  • Operator non-discoverability. Submission, reviewer queue, and verification metadata MUST NOT be accessible to the operator under any normal-course discovery or operational instruction.

Implementations using selective-disclosure cryptographic identity systems — such as the Clockwork Butterfly identity layer, or equivalent zero-knowledge attestation schemes — satisfy these properties. The framework does not mandate a specific implementation; it specifies the properties an implementation MUST exhibit.


14. Anti-Capture Governance

No entity MAY provide more than 15% of annual operational funding to the framework's governance body. Additional safeguards:

  • Rotating audit leadership (maximum 5-year terms)
  • Mandatory publication rules for audit methodology and findings
  • Public conflict-of-interest disclosures for all governance personnel
  • Independent public-interest seats (minimum 30% of governance composition)
  • Fixed-term governance rotations with prohibitions on immediate re-appointment

Suppression of audit findings by funders is prohibited and constitutes grounds for immediate disqualification from funding participation.

14.1 Governance Body Properties

This PRD does not specify the identity of the governance body. It specifies the properties such a body MUST have:

  • Jurisdiction-neutral hosting (not domiciled in a single national regulatory authority)
  • Multi-stakeholder composition (regulators, operators, civil society, technical community, public-interest seats)
  • Statutory independence from any single funder or sector
  • Documented and published accreditation methodology for auditors
  • Defined and published dispute resolution procedure

A governance body lacking any of these properties MUST NOT be recognized as the framework's authority.

14.2 Bootstrap Phase

A governance body meeting the properties in §14.1 cannot spontaneously exist. The framework therefore specifies a bounded Bootstrap Phase under which an initial convening authority brings the permanent governance body into existence.

Bootstrap Phase Constraints:

  • Duration: 24 months from framework adoption in the first pilot jurisdiction. The Bootstrap Phase MUST NOT be extended without a published finding documenting why extension is required.
  • Convening Authority Composition: A coalition of at least three existing institutions, each of which is itself multi-stakeholder, statutorily independent, and publicly accountable. Single-organization conveners MUST NOT be recognized as a Bootstrap Phase authority.
  • Funding Cap Waiver: The 15% annual funding cap (§14) MAY be temporarily waived during the Bootstrap Phase, subject to a mandatory step-down schedule reducing single-source funding share by no less than 20 percentage points per year following Bootstrap Phase conclusion.
  • Primary Deliverable: The selection, constitution, and seating of the permanent governance body meeting all §14.1 properties. This is the Bootstrap Phase's only mandatory output.
  • Sunset: Upon seating of the permanent governance body, the Bootstrap Phase convening authority's role terminates. Bootstrap conveners MAY participate in the permanent body only on the same terms as any other party.

Transparency Obligations:

The Bootstrap Phase MUST publish, at minimum quarterly, a public progress report covering: convening coalition composition, funding sources and amounts, candidate criteria for permanent body selection, and projected timeline to permanent body seating.

The Bootstrap Phase is the framework's most institutionally fragile period. It is also unavoidable: every functioning standards body in modern regulatory history was bootstrapped by an authority that, at inception, violated the independence principles the body later required. The Bootstrap Phase exists to make this transition explicit, bounded, and transparent rather than implicit, unbounded, and obscured.


15. Transition & Adoption Path

Existing deployments receive 12 months of grandfathered conditional certification upon framework adoption in their jurisdiction.

PhaseTimeline
Core Logging Module0–6 months
Lineage & Retention Layer6–12 months
Full Compliance Certification12 months

Non-compliant deployments MAY enter restricted status, procurement exclusion, or decertification per §9.


16. Explicit Constraints on Government Authority

The Obsidian Tesseract is not a sovereign surveillance framework. The framework does not authorize:

  • Continuous state telemetry access
  • Generalized prompt inspection
  • Persistent live probing
  • Ideological enforcement
  • Unrestricted model introspection

The system is designed to preserve institutional legitimacy, private-sector deployability, and civil-liberties compatibility simultaneously. A government that adopts the Tesseract framework and then attempts to expand its authority beyond these bounds is operating outside the framework, not extending it.


17. Relationship to Adjacent Regimes

The Tesseract is designed to interoperate, not compete:

Adjacent FrameworkRelationship
NIST AI Risk Management FrameworkTesseract provides the forensic substrate the NIST RMF assumes
EU AI Act (high-risk systems)Tesseract AAEs satisfy Article 12 logging requirements with greater specificity
ISO/IEC 42001Tesseract compliance maps to ISO 42001 §8 operational controls
SOC 2 Type IITesseract extends SOC 2 audit logging into AI-specific event classes
NAIC Model Bulletin on AITesseract operationalizes the bulletin's auditability expectations
State AI insurance regulationsTesseract provides the underlying evidence layer

An operator implementing the Tesseract is, by construction, well-positioned to satisfy these adjacent regimes. Adoption friction drops sharply when a new framework reduces total compliance burden rather than adding to it.


18. Failure Mode Taxonomy

A framework that does not enumerate its failure modes cannot be audited against them. The canonical failure taxonomy:

18.1 Schema-Level Failures

  • Missing required schema fields
  • Schema version mismatch without documented migration
  • Non-canonical export format

18.2 Integrity Failures

  • Broken Merkle chain
  • Unverified signing authority
  • Backdated or post-hoc generated AAE
  • Missing witness attestation where required

18.3 Lineage Failures

  • Orphaned derivative deployment
  • Multi-provider chain reconciliation failure
  • Undeclared fine-tune or system prompt change

18.4 Retention Failures

  • Sub-baseline retention period
  • Premature destruction of regulated events
  • Successor-custody gap on entity dissolution

18.5 Audit Failures

  • Audit obstruction
  • Audit scope violation by auditor
  • Conflict-of-interest non-disclosure

18.6 Governance Failures

  • Funding concentration above 15%
  • Audit finding suppression
  • Governance rotation violation

Each failure mode maps to a compliance state (§9) and, where applicable, an escalation trigger (§12). Each is also subject to the institutional learning process specified in §19.1.


19. Amendment Process

This PRD is a living document. Amendments proceed through:

  1. Proposal — published draft with rationale, open for minimum 90-day public comment.
  2. Technical Review — review by an implementation working group of certified auditors and operators.
  3. Public Interest Review — review by the independent public-interest seats of the governance body (§14).
  4. Ratification — published as a numbered revision with effective date no sooner than 180 days post-ratification.

Schema versions, threshold values, and the dangerous-capability enumerated list are amendable on this process. The foundational principle (§1) and the constraints on government authority (§16) require a supermajority ratification (75%) and a public comment period of minimum 180 days.

19.1 Post-Incident Review and Framework Repair

A framework that preserves the memory of failures without integrating them into structural change is, over time, no more useful than no framework at all. This section specifies the framework's Repair primitive (§1.2): the obligation to reintegrate incident findings into the framework's own operating parameters.

Every catastrophic incident — defined as any event triggering §12 escalation under the "Catastrophic incident" criterion — MUST initiate a structured post-incident review covering, at minimum:

  • Schema evolution review — whether the canonical event schema (§6) captured the incident with sufficient specificity, or whether new event classes, fields, or precision requirements are needed.
  • Threshold reassessment — whether the qualification thresholds (§4) or escalation thresholds (§12) admitted the incident-producing deployment to a category they should not have, or excluded it from one they should have.
  • Monitoring refinement — whether the pre-declared anomaly detection thresholds (§5.2) on the relevant deployment were calibrated such that the incident produced the AAEs it should have.
  • Lineage reevaluation — whether the lineage chain (§8) provided the reconstructability the framework promises, and where it did not, why.
  • Trust anchor adequacy — whether the Distributed Trust Anchors (§11.3) involved in the deployment were sufficient in number, independence, and operational depth, or whether the incident exposed a single point of failure.

The post-incident review MUST produce a published finding within 18 months of incident closure. The finding MUST be processed through the §19 amendment process if it recommends any change to the framework's operating parameters.

The intent of this section is to ensure that the framework treats its own failures the way it requires operators to treat their deployments: as forensic facts to be reconstructed, attributed, and used to repair the structures that produced them. A framework that exempts itself from its own discipline is captured by definition.


20. Strategic Thesis

The central institutional problem is not powerful AI. The central institutional problem is societally critical systems operating without credible forensic accountability.

Civilization already requires auditability for aircraft, banks, pharmaceuticals, utilities, and nuclear materials. We did not arrive at those standards because the underlying technologies were safe. We arrived at them because catastrophic failures, in the absence of reconstructability, produced institutional crises that took decades to recover from. The black box on a 737. The clearing audit on a bank. The lot-traceability chain on a vaccine. Each is the residue of a disaster that proved opacity is incompatible with public trust.

20.1 The Economic Pressure Toward Opacity

Opacity is not an accident. It is, in the short term, economically rational. A system whose decisions cannot be reconstructed cannot be effectively challenged in litigation, audited against fair-lending statutes, or compared unfavorably against a competitor's. Accountability introduces friction. Reconstructability introduces cost. The institutions and operators who deploy AI into consequential domains are operating under continuous incentive to keep deployment opaque, post-hoc, and difficult to interrogate — not because any individual actor is acting in bad faith, but because the structural reward gradient points that way.

The framework does not pretend this pressure does not exist. It assumes it. The framework's specifications — synchronous AAE generation, multi-provider lineage reconciliation, escrow heartbeats, Distributed Trust Anchors — are calibrated against the assumption that operators will continuously, lawfully, and predictably seek to reduce their accountability surface area in the absence of structural counter-pressure.

This is why reconstructability must become institutionally normalized before crisis conditions force coercive adoption. Frameworks adopted in the wake of disaster are reactive, overbroad, and politically captured by whichever constituency reaches the policy table first. Frameworks adopted before disaster can be specified narrowly, technically, and durably.

20.2 The Before

As AI systems become load-bearing infrastructure inside insurance, utilities, healthcare, and finance, opaque deployment without reconstructability becomes institutionally untenable. The only question is whether we establish reconstructability before the catastrophic failure that forces improvised governance under crisis conditions, or after.

The persistent concern is operational rather than regulatory: whether the organizations deploying these systems retain the ability to reconstruct their own conduct at the speed and scale of the systems they deploy. Reconstructability is what allows an operator to remain answerable, twenty years from now, for what it did today.

Obsidian Tesseract is the before.


About This Document

The Obsidian Tesseract PRD is authored by Rhombus Ticks, with technical consultation from TC Ricks (IT Consultant) and research assistance from Redwin Tursor. The framework draws on operational experience across regulated industries — insurance, healthcare, telecommunications, financial services, and hospitality. The document is intended to be implementable. Inquiries from regulators, insurers, standards bodies, and operators evaluating adoption are welcome.


Obsidian Tesseract — Critical Systems Accountability Infrastructure