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.

Primitive	Function
Witness	Independent observation of consequential actions by parties without operational stake
Memory	Persistent, tamper-evident retention of actions in their original ordering and context
Lineage	End-to-end provenance of the system that took the action, across providers and modifications
Repair	Reintegration 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:

Sector	Rationale
Insurance	Existing audit culture; litigation-driven accountability; mature actuarial discipline
Utilities	Critical infrastructure exposure; existing FERC/NERC reliability frameworks
Healthcare Administration	Regulated decision chains; HIPAA-adjacent provenance requirements
Financial Risk Systems	Existing 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 Category	Trigger
Training Compute	≥10²⁶ FLOPs equivalent
Derivative Capability	Fine-tune materially expands dangerous capability (defined in §4.1)
Deployment Reach	≥10 million monthly active users or affected parties
Critical Sector Use	Insurance, 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 Class	Purpose
Deployment	Production activation of a regulated system or version
Transition	Weight, routing, prompt, or configuration modification affecting output
Escalation	Restricted-output severity event (forensic fact only, not judgment)
Autonomous Action	External action initiation without human-in-the-loop checkpoint
Override	Safety, policy, or human suppression of system default behavior
Anomaly Detection	Internal monitoring metric (uncertainty quantification, distribution-shift score, confidence interval, or equivalent) crosses a pre-declared threshold while output is produced
Incident	Internal anomaly declaration
Audit Invocation	Regulator or auditor access event
Retention Modification	Logging policy change
Compliance Transition	State 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

State	Meaning
Certified	Independently attested as fully compliant
Conditional	Compliant with documented remediation in progress
Restricted	Limited deployment authority pending resolution
Escalated	Under formal regulator review
Decertified	Ineligible 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 Type	Minimum Retention
Routine operations	90 days
Deployment lineage	7 years
Audit events	10 years
Safety escalations	Permanent
Catastrophic incidents	Permanent

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 Type	Role	Operational Source
Accredited Independent Auditors	Annual external verification, randomized sampling, completeness validation	§11
Witness Consortia	Independent attestation of AAE streams; participation in critical event classes	§7, §11
Public-Interest Governance Seats	Minimum 30% of governance composition; statutory independence from operators and funders	§14
Whistleblower Reporting Infrastructure	Protected channels for affected personnel and third parties	§13
Escrow Publication Targets	Receivers 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:

Trigger	Threshold
Verified telemetry suppression	≥3 incidents within 24 months
Concealed deployment fork	Verified material concealment
Catastrophic incident	Human, financial, or infrastructure harm above defined thresholds
Retention destruction	Intentional deletion of regulated events
Audit obstruction	Failure to comply with certified audit
Evidence gap	>0.5% of regulated actions missing a corresponding signed AAE in any 30-day window
Output drift	Validated internal monitoring shows model output distribution deviated >3σ from certified baseline without a corresponding Transition AAE
Escrow heartbeat failure	Failure 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.

Phase	Timeline
Core Logging Module	0–6 months
Lineage & Retention Layer	6–12 months
Full Compliance Certification	12 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 Framework	Relationship
NIST AI Risk Management Framework	Tesseract 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 42001	Tesseract compliance maps to ISO 42001 §8 operational controls
SOC 2 Type II	Tesseract extends SOC 2 audit logging into AI-specific event classes
NAIC Model Bulletin on AI	Tesseract operationalizes the bulletin's auditability expectations
State AI insurance regulations	Tesseract 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:

Proposal — published draft with rationale, open for minimum 90-day public comment.
Technical Review — review by an implementation working group of certified auditors and operators.
Public Interest Review — review by the independent public-interest seats of the governance body (§14).
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

Friday, May 15, 2026