Marble Tesseract — Product Requirements Document

Institutional Accountability Infrastructure for the Governed Adoption of AI and Enterprise Systems

Document	Product Requirements Document (PRD) — Reference Implementation Architecture
Version	v0.3
Status	For internal review / partner circulation
Author	Rhombus Ticks
IT Consulting	TC Ricks
Imprint	Red Anvil Creative
Date	July 16, 2026

Why This Document Exists

The Obsidian Tesseract specifies what must be true of any high-impact computational deployment: that its conduct be independently reconstructable after the fact. Section 15.2 of that framework promised a companion artifact — a Reference Implementation Architecture demonstrating the framework instantiated inside a real institution's operational layers.

This is that artifact. Its profile institution is a university: specifically, a composite global research university with campuses in multiple legal jurisdictions, defense-adjacent research obligations, a unionized workforce, a tradition of shared governance, and — like every such institution in 2026 — an AI adoption rate that has decisively outrun its governance capacity.

Marble Tesseract is not a second framework. Obsidian is volcanic glass: the uncompromising abstract, indifferent to who implements it. Marble is what institutions are actually built from — load-bearing, veined, quarried locally, and shaped to carry a specific roof. Where this document is silent, the parent framework governs. Where this document specifies, it specifies only how the parent's requirements take physical form inside one kind of institution — and what additional structures that institution requires which the parent, by design, did not provide.

Two of those structures are original to this document: the Governance Console, which makes shared governance a mechanical property of the deployment pipeline rather than an advisory gesture, and the Enablement Flywheel, which couples certification to service delivery so that the act which satisfies oversight is the same act that accelerates adoption. The thesis of this document is that these two structures are one mechanism, and that institutions fail at AI governance precisely because they deploy them as enemies.

This document is intended to be implementable, not aspirational.

Document Conventions

This PRD uses capitalized 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 parent framework's four operational primitives — Witness, Memory, Lineage, Repair — carry the meanings established in Obsidian Tesseract §1.2 and are used here without redefinition.

Inheritance Summary

Marble Tesseract inherits from the parent framework, without restatement or modification:

The foundational principle: reconstructability, not behavioral perfection (Obsidian §1)
The separation of forensic fact from adjudication (§1.1)
The Atomic Accountability Event as the indivisible forensic unit, its canonical schema, and its synchronous-generation requirement (§5–6)
Integrity and anti-tampering architecture (§7)
Capability inheritance and lineage chain requirements (§8)
The five compliance states (§9)
Retention architecture and the escrow heartbeat (§10)
The audit firewall: warrant-scoped, regulator-authorized, event-bounded verification, with the explicit prohibitions on continuous monitoring and generalized inspection (§11)
Distributed Trust Anchors as the structural guarantee against single-party capture (§11.3)
Whistleblower protections and intake architecture properties (§13)
The failure-mode discipline: a framework that exempts itself from its own standards is captured by definition (§18–19)

Any implementation claiming Marble Tesseract conformance MUST satisfy the parent framework's requirements for all deployments that independently qualify under Obsidian §4. Marble extends coverage downward — to institutional systems below the parent's qualification thresholds — because a university's accountability crisis does not begin at 10²⁶ FLOPs. It begins with a department buying a transcription tool on a credit card.

1. The Problem, Institutionally

A university in 2026 cannot answer a simple question: what is running, who vouched for it, and what happened when it failed?

The sector's own survey data makes the shape of the failure plain. The overwhelming majority of higher-education employees now use AI tools in their work; barely half know what their institution's policies are; only a small fraction of institutions believe their security and privacy postures are adequate to the risk. The gap between use and governance is not a communications problem. It is an architectural absence: there is no single institutional object in which a tool's existence, its authorization, its risk classification, and its incident history live together.

The consequences arrive from every direction at once. Unapproved tools process student records and unpublished research. Procurement signs contracts with no attestation of what the vendor's system retains or trains on. Research security obligations — now arriving as enforceable contract clauses rather than aspirations — demand certified environments the institution cannot demonstrably delineate. Faculty bodies, correctly reading administration-led AI adoption as governance without their consent, organize resistance that is treated as obstruction rather than as the missing control it actually is. And when a consequential automated decision goes wrong — an admissions flag, an aid determination, a conduct referral — the institution discovers that it cannot reconstruct its own conduct, which is the precise condition the parent framework exists to prevent.

The standard institutional responses fail in a characteristic pattern. Governance-first deployments (policies, committees, acceptable-use documents) generate paper that adoption routes around; the tools arrive anyway, off the books. Adoption-first deployments (enablement teams, licenses, training) accelerate exactly the sprawl they cannot see. Each approach is deployed as the other's enemy, each constituency armed against the other — and the institution ends up with both a shadow inventory and a shelf of unread policy.

Marble Tesseract's claim is that this is a false opposition, and that the fix is architectural: a single record structure in which the event that satisfies the oversight body is the event that unlocks the enablement pipeline. One record, two constituencies paid. The remainder of this document specifies that structure.

2. The Core Object: the Institutional Passport Ledger

Marble Tesseract is one product: a registry. Everything else in this document is a door into it.

The Institutional Passport Ledger is a tamper-evident registry in which every system that touches institutional data or institutional decisions holds exactly one Passport. Nothing operates off-ledger. The Passport is the institutional-grain analog of the parent framework's Atomic Accountability Event: where the AAE records a single regulated action, the Passport records a single regulated system — and, at the higher tiers, becomes the anchor to which that system's AAE stream attaches.

2.1 The Passport

Every Passport MUST contain:

System identity — name, vendor or internal owner, version, deployment context, jurisdiction profile(s)
Risk tier — per §2.2
Named human sponsor — an identified individual accountable for the system's institutional use; sponsorship is transferable but a Passport MUST NOT exist without a living sponsor
Attestation history — every certification, renewal, conditional finding, and disposition, cryptographically signed and append-only
Lineage reference — for tiers T2 and above, the lineage chain per Obsidian §8
Compliance state — drawn from the parent framework's enumerated set (Obsidian §9)
Incident record — every Repair-class event associated with the system

Passport records are Memory. Their signatures are Witness. Their lineage references are Lineage. Their incident records feed Repair. The tetrad is not decorative; a ledger implementation missing any of the four functions is non-conformant.

2.2 Risk Tiers

Marble classifies institutional systems into four tiers. Tier assignment happens at the Procurement Gate (§3.3) or at registration, is recorded on the Passport, and MUST NOT change without a signed transition record.

Tier	Name	Definition	Obligation
T0	Registered	Tools with no access to protected institutional data and no decision authority over persons	Registration only; sponsor named
T1	Attested	Tools touching internal operational data; no protected classes, no decisions about persons	Vendor or sponsor self-attestation on the published lightweight form
T2	Certified	Systems touching protected data (student records, personnel data, controlled research information) or embedded in institutional workflow	Independent review; conformance evidence; renewal cycle
T3	Critical Decision	Systems that make or materially influence consequential decisions about persons — admissions, financial aid, hiring, promotion, discipline, conduct, grading-adjacent functions — or that control certified research perimeters	Full parent-framework instrumentation: synchronous AAE generation, lineage chain, witness attestation, Governance Console disposition

"Materially influence" — bounded definition. In the parent framework's tradition of enumerated rather than discretionary thresholds (Obsidian §4.1), a system materially influences a consequential decision when any of the following holds: (a) its output is a required input to the decision workflow; (b) its score, flag, rank, or classification is presented to the human decision-maker at the point of decision; (c) it filters, orders, or triages the candidate pool the human decides from; or (d) overriding its output requires justification, escalation, or additional authorization. A system whose output a decision-maker may consult but is neither shown by default nor required to address does not materially influence the decision. The enumerated list is amendable through the §7.4 amendment process; the Subject's Door (§5.3) hangs on this definition, which is why it is enumerated and not left to implementer judgment.

The T1 tier exists deliberately as a proportionality valve. A tiering regime that only enterprise vendors can afford to satisfy quietly hands the institution's technology stack to incumbents. The T1 attestation form MUST be completable by a two-person vendor or a single sponsoring staff member without legal counsel, and MUST carry no fee. Small tools earn their way up the tiers only when their access does.

2.3 The Off-Ledger Prohibition

No system MAY process institutional data or exercise institutional decision authority without a Passport. Discovery of an off-ledger system is not a punishable event for the discovering or sponsoring individual — it is a registration event (see the personnel firewall, §5.2). The prohibition is enforced structurally, at the gates, not punitively, at the person. An implementation that enforces the ledger by disciplining individual staff for tool use has failed this specification and will, predictably, drive the inventory back into shadow.

Two honesty clauses bound this prohibition. First, its scope: a free tool used on a personal account that processes no institutional data and exercises no institutional decision authority is outside the ledger's jurisdiction by definition — the prohibition governs institutional deployment, not personal computing, and an implementation claiming otherwise has confused coverage with surveillance. Second, its enforcement surface: the Procurement Gate (§3.3) catches only what is purchased. Tools that arrive free, piloted, or embedded reach institutional data through one chokepoint the institution does control — its identity plane. The Identity Anchor (§3.1) therefore doubles as a passive discovery surface: applications authenticating against institutional single sign-on, or requesting access to institutional data stores, are detectable in aggregate even when no purchase order ever existed. Discovery feeds registration. This discovery function MUST operate at the application grain and MUST NOT produce individual usage reporting — the personnel firewall (§5.2) governs the identity plane's discovery role absolutely, and a discovery feed that names users instead of systems is a firewall breach under §8.

3. The Six Doors

The ledger has six read/write surfaces. They are not modules and MUST NOT be priced, staffed, or governed as separate products; each is a place where an existing institutional function touches the same registry.

3.1 Identity Anchor

Every ledger action — registration, attestation, certification, override, disposition — MUST carry a non-repudiable signature traceable to an authenticated institutional identity. The ledger builds on the institution's existing identity plane (enterprise single sign-on, directory, and privileged-access systems); it does not introduce a parallel identity system for routine operations. Privileged ledger roles (tier assignment, compliance-state transition, Console administration) MUST be governed under the institution's privileged access management with separation of duties: no single individual may both sponsor a system and certify it.

The single exception to institutional identity is the dissent channel (§6), which for structural reasons must not depend on the identity plane the operator controls.

3.2 Evidence Rails

The integration layer — the pipes through which enterprise systems exchange data — is where reconstructability either survives or silently dies. Marble requires that every integration crossing a T2+ boundary emit lineage metadata by default: source system Passport ID, destination Passport ID, data class, and transformation declaration, signed and retained per the parent framework's retention classes. Forensic reconstructability MUST be a property of the transport, not a promise of the endpoints. An integration between two certified systems that itself carries no Passport is an orphaned link and a §8-class lineage failure under the parent taxonomy.

3.3 Procurement Gate

No contract for a system in scope MAY be executed without a Passport application: tier assignment before signature, vendor attestation at intake. The gate is where shadow adoption is prevented upstream — at the purchase order, not downstream at discovery.

Vendor attestations submitted at the gate are contractual representations, and institutional contract templates MUST incorporate them by reference, with misrepresentation carrying the same remedies as any other material misrepresentation in the agreement. This is the answer to the question every general counsel will ask: a Passport is not theater, because the attestation on it is enforceable paper.

The gate MUST publish its intake standard, its tier rubric, and its expected disposition times. A gate whose behavior is unpredictable will be routed around, lawfully and creatively, by every department with a deadline — and the resulting shadow inventory will be the gate's fault, not theirs.

3.4 Perimeter Certification

Research environments carrying regulatory obligations — controlled unclassified information, export-controlled data, sponsor-mandated security frameworks — are registered as T3 perimeter Passports. The perimeter Passport anchors: the enclave's control-framework conformance evidence, chain-of-custody for controlled data crossing its boundary (riding the Evidence Rails), personnel access records under the Identity Anchor, and remediation plans as Repair-class records.

The institutional argument of this door is the inversion the sector has missed: the university stays open because the controlled zone is provably sealed. A demonstrable perimeter is what permits the commons to remain a commons. Institutions that cannot delineate their certified zones end up applying controlled-environment restrictions everywhere, which is how research security becomes research suppression.

3.5 Deployment Certification

T3 decision systems receive the parent framework's full instrumentation. In addition, Marble requires jurisdiction profiles: a Passport for a system deployed across campuses in multiple legal regimes MUST carry one attestation core and per-jurisdiction annexes, so that a system certified once deploys everywhere with locally correct obligations — the domestic student-privacy annex on one campus, the European data-protection annex on another. Certification without jurisdictional multiplication is the door's economic argument: it converts the institution's global structure from a compliance liability into the exact case where a single ledger pays for itself.

One honest limit on that argument: the annex model handles obligations that are additive across regimes. Where regimes genuinely conflict — a deletion right in one jurisdiction against a retention mandate in another, a data-localization rule against a consolidation requirement — no annex reconciles them, and the correct architecture is per-jurisdiction deployment variants under a single lineage chain. In that case the Passport's job contracts to what it can honestly do: record the variance, bind the variants to one provenance, and make the divergence itself reconstructable. "Certified once, deployed everywhere" is the door's goal state, not its guarantee, and an implementation that papers over a regime conflict with an annex has produced compliance theater under the parent taxonomy.

Conformity evidence held on T3 Passports MUST be exportable as crosswalk artifacts: machine-readable mappings from ledger record types to the control and logging requirements of the external regimes the institution answers to — national security-control frameworks, AI-regulation logging obligations, student-privacy audit requirements, records-of-processing obligations. The parent framework's interoperability stance (Obsidian §17) governs: a ledger whose evidence external assessors must re-derive from scratch has failed its own value claim.

3.6 Certification as Asset

The Passport travels. A spinout leaving the institution's technology-ventures pipeline MAY carry its attestation history as diligence collateral; a sponsored-research proposal MAY cite perimeter certification state as competitive evidence; the institution's aggregate conformance posture is an insurance and audit-cost argument. This door requires no additional machinery — only that Passport export to a departing entity is itself a signed ledger event, preserving lineage across the institutional boundary per the parent framework's capability-inheritance principle.

4. The Coupling Claim: Console and Flywheel

This section is the document's thesis. Everything before it is inherited engineering; everything after it is boundary-drawing. The two structures specified here are one mechanism, and an implementation that deploys either without the other has not implemented Marble Tesseract.

4.1 The Governance Console

The Governance Console is a standing review body with mechanical standing in the deployment pipeline: at defined tiers, a Passport cannot advance without the Console's recorded disposition, and every disposition is itself a signed, append-only ledger record.

Composition. The Console's legitimacy is its composition, and this document does not leave composition to the implementer's discretion, because composition is precisely where such bodies are captured. The Console MUST be constituted as follows:

Faculty members elected by the faculty senate or equivalent body — not appointed by administration
Staff members designated by staff representative structures, including recognized bargaining units where they exist
At least one student member seated by student government
Administrative members in a minority of voting seats; the chief information or data officer (or designee) serves ex officio and non-voting
No member may hold a privileged ledger role (§3.1) during their Console term

This composition requirement is Marble's local expression of the parent framework's Distributed Trust Anchor principle: no single institutional constituency — including the administration that operates the ledger — may hold unilateral authority over what enters the institution's decision infrastructure. A Console wholly appointed by the operator is not a trust anchor. It is the operator, wearing a second hat.

Authority, scaled by tier. At T1, the Console's role is visibility: it receives the registration stream and MAY flag. At T2, the Console holds a review window: certification proceeds after a fixed published period unless the Console issues a reasoned hold. At T3, the Console's disposition is binding: a critical-decision system does not certify without an affirmative Console record, and a Console hold suspends deployment pending the dispute procedure. Dispute resolution follows a published procedure with a defined escalation path; overrides of a Console hold by executive authority are permitted only as signed, permanent, public ledger events — the institution may overrule its governance body, but never silently.

Enforcement beyond publication. Publication alone is documentation, not consequence, so the hold carries inherited teeth: a T3 system deployed over an unresolved Console hold enters Restricted compliance state per the parent framework's state machine (Obsidian §9) — automatically, as a triggered state transition under §8's discipline, declared by no one and requiring no one's assent — and Restricted state has mechanical effects this document binds to it — the system is excluded from the Enablement Flywheel for the duration, its contract MUST NOT be renewed or extended at the Procurement Gate while Restricted, and the Restricted interval appears in the Institutional Attestation Report (§7.1) by name. An executive may still override; the override is public, the system runs unsupported, and its paper expires. The administration retains ultimate authority — it merely can no longer exercise that authority for free, silently, or indefinitely. Enforcement that budget cycles can feel is the only kind institutions remember.

Anti-rubber-stamp instrumentation. The Console's own performance is ledger-evidenced: disposition times, approval rates, hold rates, and override rates MUST be computed from the ledger and published in the annual report (§7.2). This is the data against which the stop-conditions in §8 are evaluated. A Console that approves everything instantly is measurable, and its measurement is the framework's own confession.

4.2 The Enablement Flywheel

Certification is the toll; enablement is the carrot; they are the same gate. A system whose Passport reaches its required tier thereby — automatically, as a property of the ledger record and not as a separate decision — unlocks the institution's enablement pipeline: training development, support onboarding, integration engineering, license consolidation, and inclusion in the institution's supported-tools catalog. Adoption metrics and attestation records are emitted by the same pipeline and stored on the same Passport.

The Flywheel is what makes the ledger something departments want to be on. The uncertified tool has no training, no support, no integration, and no catalog entry; the certified tool has all four, plus a governance record that protects its sponsor when questions come. The reward gradient — which the parent framework correctly observes always points toward opacity — is hereby pointed, for the first time, toward the ledger.

The coupling requirement, stated normatively: the ledger event that records a Console disposition or tier certification MUST be the triggering event for enablement-pipeline entry. Implementations that operate certification and enablement as separate queues, separate systems, or separate budget lines have decoupled the mechanism and MUST NOT claim conformance. The decoupled failure mode is enumerated in §8 because it is not a degradation of the design — it is the design's death, after which the institution has merely rebuilt the governance-versus-adoption war with better record-keeping.

4.3 Why the Pairing Is the Product

Governance-first fails because it offers constituencies nothing but friction. Adoption-first fails because it offers oversight nothing but exhaust. Every existing vendor product, CIO framework, and faculty resolution in this space speaks for one side of this divide, because each is authored by one side of it. The Console gives the governed a brake that is real; the Flywheel gives the governors an engine that is fast; the shared ledger record is the treaty instrument both sides can verify. One record, two constituencies paid. That is the entire product, and it is the sentence this document exists to earn.

The apparent tension inside that sentence — oversight wants detail, adopters want speed, and one record cannot maximize both — is resolved by the tier system, not by assertion. Detail scales with consequence: a T1 tool pays a fee-free form and clears in days; a T3 decision system pays full instrumentation and a binding disposition, because the people it decides about are the ones paying otherwise. The trade-off is real at every tier; the tiers exist so that no system pays more scrutiny than its risk purchases, and no constituency is asked to accept less than its exposure demands. Where an implementation feels the tension acutely, the diagnosis is almost always mis-tiering, and the remedy is the tier-transition record, not a faster rubber stamp.

5. Boundaries

A ledger of everything is a surveillance instrument. Marble Tesseract is conformant only within the following boundaries, which are requirements, not guidance.

5.1 The Scholarly Carve-Out

Marble governs institutional deployment: systems processing protected institutional data, embedded in institutional workflow, or making decisions about persons. It does not govern scholarly use: a researcher's or instructor's own inquiry, experimentation, writing, or pedagogy with computational tools, however novel or uncertified those tools may be.

A principal investigator running an uncertified model on public data in their own research is out of scope — that is academic freedom, not shadow IT. The same investigator's tool enters scope at the moment it processes controlled research information, touches student records, or is adopted as an instrument of institutional decision. Scope attaches to the data and the decision, never to the inquiry. An implementation that requires Passports for scholarship has not extended the framework; it has violated it, and the violation is enumerated in §8.

5.2 The Personnel Firewall

The ledger records systems, not workers. Attestation and usage records associated with identified individuals MUST NOT be used as evidence in individual performance evaluation or discipline, with one enumerated exception: intentional falsification of an attestation or certification record, which is an integrity failure under the parent taxonomy and is adjudicated under the institution's existing misconduct procedures — on the strength of the falsified record itself, not of usage surveillance.

Reporting derived from the ledger for management purposes MUST be aggregate. Discovery of off-ledger use by an individual triggers registration, not discipline (§2.3). Where a workforce is represented, the institution SHOULD treat ledger deployment as a subject for impact negotiation before rollout rather than grievance after it; a ledger imposed on a bargaining unit is a ledger that unit will teach itself to defeat, and it will be right to.

And where a collective bargaining agreement and a Console disposition conflict, the agreement governs. The framework yields to labor law and negotiated contract explicitly rather than pretending the question cannot arise; the conflict itself is recorded as a ledger event and triggers impact negotiation on the disputed subject. A governance framework that imagined itself senior to a workforce's contract would deserve the defeat it would get.

This firewall is not generosity. It is engineering. The whistleblower channel (§6), the registration-not-discipline rule, and the Flywheel's reward gradient all depend on the workforce experiencing the ledger as protection. A single personnel action built on ledger surveillance converts every subsequent record into something employees rationally minimize, and the institution's Memory primitive dies of self-inflicted distrust.

5.3 The Subject's Door

The parent framework instruments the operator. Marble adds the person the decision lands on.

Disclosure registry. The institution MUST publish the list of T3 Passports — the systems certified to make or materially influence consequential decisions about persons — including each system's function, sponsor office, and certification state. Students, employees, and applicants are entitled to know what is certified to judge them.
Decision notice. A consequential decision materially influenced by a T3 system MUST be identifiable as such to its subject through existing notice channels.
Reconstruction request. A person subject to such a decision MAY request reconstruction of that decision through the institution's existing appeal and grievance procedures. Marble does not create a new adjudicative body; it guarantees that when the existing body asks what did the system do, in what sequence, under whose authority, the T3 Passport's AAE stream can answer. The framework's promise to the institution — reconstructability — is hereby extended to the people the institution decides about, scoped per decision, through channels that already exist.

Records touching student-privacy regimes retain their protected character inside the ledger; the ledger inherits, and MUST NOT dilute, every protection already attached to the data its records reference.

6. Intake and Dissent

The parent framework's §13 governs in full: protected reporting channels for employees, contractors, auditors, and materially affected third parties; anti-retaliation protections; escalation pathways independent of operator approval.

Marble specifies the institutional instantiation. The dissent channel MUST satisfy the four intake-architecture properties of Obsidian §13.1 — identity authenticatability without identity transmission, separation of duties on de-anonymization, chain-of-custody attestation from submission onward, and operator non-discoverability. Selective-disclosure cryptographic identity systems — such as the Clockwork Butterfly identity layer, or any equivalent zero-knowledge attestation scheme — satisfy these properties; the framework specifies the properties, not the vendor. Critically, the channel MUST NOT ride the institutional identity plane of §3.1: a reporter proving "I am a current member of this institution with access to system X" must be able to do so without the institution's directory ever learning who asked.

A conformant channel accepts, at minimum: reports of off-ledger systems, disputed attestations, tier-assignment challenges, and suspected suppression of ledger records. Submissions are ledger events of the highest retention class.

Anti-retaliation linkage. Cryptographic protection at intake is necessary and insufficient; the person who eventually de-cloaks to pursue a finding needs procedural shelter. A verified submission MUST confer documented protected status under the institution's existing whistleblower and academic-freedom policies from the moment of submission — retroactive to intake, not commencing at disclosure — and retaliation against a reporter is itself a governance failure under §8, adjudicable by the Console with its disposition on the permanent record.

7. Operating Model, MVP, and Phasing

7.1 What This Costs, and Who Pays

A specification silent on money is a specification that dies in its first budget cycle.

Steady state: the reference operating model is a small permanent team — a product owner for the ledger, an analyst at the Procurement Gate, an enablement engineer on the Flywheel — plus fractional counsel and security review. This is deliberately a single-digit-headcount product; a ledger that requires a bureau has been over-built.
Funding structure: the Gate and the Console MUST be centrally funded. Charging departments for certification is a design error with a known failure signature — it prices small units into shadow adoption and converts the compliance function into a revenue-seeking one. The Flywheel's enablement services MAY be charged back per the institution's normal service model; the toll is free, the carrot may be priced.
The executive surface: the ledger MUST render an institution-level view — certified-system counts by tier, perimeter states, Console performance metrics, incident and repair summaries — and the institution MUST publish an annual Institutional Attestation Report from it. This is the one-page risk posture the president, trustees, insurers, and accreditors are currently assembling by hand from sources that disagree with each other. It is generated, not written.
Measured value, not asserted value: this document deliberately publishes no invented return-on-investment figures — a governance framework that opens with fabricated savings has already taught its readers how it handles evidence. Instead, the ledger is instrumented to produce its own economics, and the Attestation Report MUST publish them: audit-preparation hours before and after crosswalk export, procurement-gate cycle time by tier, the shadow-inventory proportion over time, Console disposition times, and Restricted-state days incurred. Marble's return is a claim the ledger itself will substantiate or refute — which is the only posture consistent with a framework whose signature move is self-evidence.

7.2 MVP Slice

Year one ships the ledger and proves the coupling:

Passport Ledger core: registry, tiers, signatures, retention
Procurement Gate live for one domain — reference choice: AI tools touching student data
T1 lightweight attestation form published
Governance Console seated per §4.1, operating in review-window mode
Flywheel coupling live: certification event triggers catalog and training entry
Dissent channel live with intake properties verified
First Institutional Attestation Report published from the ledger

Sequencing note, stated honestly: the reference MVP domain and the most deadline-driven constituency are not the same. Institutions facing near-term research-security contract clauses MAY invert the sequence and bring the Perimeter Certification door (§3.4) live first, or run it as a parallel track; the ledger core is identical in either ordering, which is the point of building the registry before the doors. What an implementation MUST NOT do is let the loudest deadline skip the Console seating or the Flywheel coupling — a perimeter certified under an uncoupled, unseated ledger is Obsidian compliance wearing Marble's name.

7.3 Phasing

Phase 2: Evidence Rails on T2+ integrations; Perimeter door (if not already live); jurisdiction profiles and first crosswalk exports; Console to binding mode at T3
Phase 3: Deployment Certification for the institution's existing consequential-decision systems — the retroactive pass, hardest politically, scheduled deliberately after the ledger has demonstrated the Flywheel's benefits. The mechanism is inherited, not invented: per the parent framework's transition path (Obsidian §15), existing T3 systems receive grandfathered Conditional certification for a fixed published window — reference parameter: 12 months from Phase 3 activation — during which they operate with full Flywheel access while completing instrumentation. Good faith is defined mechanically: a system inside its window with a filed instrumentation plan is Conditional; a system past its window without one transitions to Restricted automatically. The amnesty is real, bounded, and recorded — exactly the shape of the Month 0 registration amnesty, applied to the systems that matter most. Also in Phase 3: Subject's Door surfaces; Certification-as-Asset export.
Continuous: the parent framework's Repair discipline — every incident finding reintegrated into tier rubrics, gate standards, and Console procedure through the §7.4 amendment process.

Sequencing rule, stated once and normatively: whatever an implementation's local phasing, the Console MUST be seated before the Gate takes its first binding disposition, and the Flywheel coupling MUST be live before or simultaneously with the first certification it would reward. A gate operated for a quarter with no Console behind it, or certification run for half a year with no carrot attached, is the governance-first failure §1 diagnoses, rebuilt on purpose. Where year-one capacity cannot carry the full coupling, the permitted cut is narrower domain scope — never decoupled sequence.

7.4 Service Levels and Amendment

Disposition targets. The Gate and Console MUST publish expected disposition times per tier at go-live — reference parameters: T1 measured in days, T2 in weeks, T3 in weeks-to-low-months — and actual performance against those targets is Attestation Report content (§7.1). An expedited-review path MUST exist, with its criteria published and every expedited disposition flagged as such on the Passport; urgency is a legitimate institutional condition, and an unacknowledged back channel is how legitimate urgency becomes illegitimate bypass.

Amendment. The boundaries of this document — the enumerated definition of material influence (§2.2), the scholarly carve-out (§5.1), the personnel firewall (§5.2), and the stop-condition triggers (§8) — are deliberately rigid to prevent administrative drift, and deliberately amendable because technology outruns charters. Amendment of these core definitions SHALL require: a two-thirds majority of the Governance Console; dual-key ratification by the institution's chief academic officer and chief information officer — neither constituency amends the treaty alone; and a 30-day comment period open to all institutional members, with comments and dispositions on the ledger. Tier rubrics, threshold parameters, and gate standards below the boundary layer amend on Console majority with published notice. This is the parent framework's §19 discipline at institutional scale: the constitution is hard to change, the operating parameters are not, and both change in public.

7.5 The Passport Lifecycle

One object, one lifecycle, every door a station on it:

  REGISTER ──> ATTEST ──> REVIEW ──> CERTIFY ──> ENABLE ──> MONITOR ──> REPAIR ──> RENEW / RETIRE
  (T0: stop     (T1: stop   (Console    (tier       (Flywheel:   (AAE stream,  (incident    (re-attest on
   here)         here)       window      granted;    catalog,     evidence      findings     cycle; export
                             or binding  ledger      training,    rails,        reintegrate  Passport on
                             disposition) event)      support)     discovery)    per §7.3)    departure)

The certifying event and the enabling event are the same ledger record — the diagram's fourth and fifth stations are one write. That is the coupling, drawn.

8. Failure Modes and Stop-Conditions

The parent framework's taxonomy (Obsidian §18) applies to every Marble deployment, and its escalation discipline (Obsidian §12) governs this section's form: a stop-condition is an enumerated trigger paired with an automatic consequence, not a discretionary judgment. Discovery of any condition below suspends the affected compliance states without requiring anyone's decision to do so — escalation is a triggered response, which is what protects the framework from politicized interpretation and protects operators from arbitrary enforcement. Each condition is evaluable from the ledger's own records; a Marble implementation that cannot run this section against itself is not a Marble implementation.

8.1 The Ghost Console (rubber-stamp failure). Trigger: Console disposition metrics cross published rubber-stamp thresholds — reference parameters: a T3 approval rate at unity over a rolling six-month window, or a median T3 disposition time below a published floor — or Console composition drifts from §4.1 requirements. The threshold values are institutional parameters set and published at Console seating, because raw values are gameable (a single pro-forma hold defeats a naive 100% trigger, and a fast median can evidence good pre-review rather than capture); what is not parameterizable is the obligation to publish the thresholds and evaluate against them. Consequence: The annual audit MUST flag the state as a structural failure; the Console MUST hold a public hearing reviewing its evaluation criteria and re-verifying that its trust anchors are not being bypassed or socially pressured; the implementation is Conditional pending re-constitution.

8.2 The Decoupled Flywheel (silo failure). Trigger: A T2 or T3 system obtains enablement resources — licensing, central integration engineering, enterprise training, catalog entry — without the certifying ledger event; or certification events cease to trigger enablement entry. Consequence: The affected Passport moves to Restricted automatically. The unit operating the enablement pipeline MUST submit a root-cause remediation plan to the Console within 14 business days. Conformance claims for the implementation are suspended until the coupling is re-evidenced, because a decoupled Flywheel is not a degraded Marble — it is the governance-versus-adoption war rebuilt with better record-keeping.

8.3 The Off-Ledger Drift (routing failure). Trigger: Discovered off-ledger systems exceed a published threshold proportion of the known inventory in any review period. Consequence: Mandatory gate repair, reported to the Console with the same 14-day remediation discipline as §8.2. The failure is the gates' design, never the users'; a drift response that reaches for discipline instead of redesign is itself a §8.5 event in waiting.

8.4 The Scholarly-Scope Breach (chilling failure). Trigger: Any administrative attempt to compel Passport registration for use within the scholarly carve-out (§5.1). Consequence: The affected researcher or instructor MAY file an expedited jurisdictional challenge to the Console. Upon filing, any administrative action against the challenger's computational environment is stayed, and the use is presumed out of scope until the Console rules otherwise. One substantiated breach is a governance failure on the annual record; a pattern is capture of the framework by its operator.

8.5 The Personnel-Firewall Breach (surveillance failure). Trigger: Ledger records, Passport telemetry, or Identity Anchor discovery data introduced into any individual disciplinary proceeding or performance evaluation outside the single enumerated exception (§5.2). Consequence: The entire Identity Anchor discovery feed is suspended immediately — no passive discovery metrics may be generated or acted upon — until the Console certifies both that the breach is remedied and that the affected individual has been made whole, and the breach is disclosed by name in the Attestation Report. The severity is deliberate and the deterrent is structural: breach the firewall once and the institution loses the discovery capability entirely. The workforce's trust is the substrate every other record sits on, and this failure is unrecoverable by apology.

8.6 The Unwatched Watcher (capture failure). Trigger: The ledger operating without its own current T3 Passport; its operational AAE stream lacking witness attestation from a Distributed Trust Anchor with no operational stake in the ledger's administration (per Obsidian §11.3); or its permanent-retention classes absent from the parent framework's escrow heartbeat. Consequence: Every compliance state the ledger asserts is Conditional until the watcher's own instrumentation is restored and independently attested. Escrow protects the record's survival, not its live integrity, and a ledger attesting to itself is circular: a ledger exempted from its own tiers is captured by definition; a ledger verified only by its operator is captured by construction; a ledger that cannot survive its operator's dissolution has failed the parent's records-continuity claim.

The stop-conditions are the document's warranty, and their automaticity is the warranty's value. If the Console rubber-stamps, if the Flywheel decouples, if the firewall breaches — the implementation has failed, the ledger's own records will show it, the consequences fire without anyone's permission, and the institution is entitled to say so out loud. A framework that specifies how to catch its own corpse — and what the corpse's discovery sets in motion — is the only kind worth adopting.

9. Worked Example

A composite: a global research university, multiple campuses across two continents and three legal regimes, a defense-adjacent research institute, unionized staff, an active faculty senate, and the sector-standard condition — hundreds of AI-touched tools in use, a low double-digit percentage of them known to central IT.

Month 0–3. Ledger core stands up. The registration amnesty runs: every known tool gets a T0/T1 Passport, no questions asked, sponsors named. The inventory triples. This is recorded as success, not scandal — the shadow was pre-existing; the ledger merely made it Memory.

Month 3–6. Procurement Gate goes live for AI tools touching student data. A department attempting to buy an AI advising tool hits the gate; the vendor completes attestation in a week; tier T3 is assigned; the Console — seated, elected, review-window mode — takes its first real disposition and attaches two conditions. The tool certifies. The same ledger event drops it into the supported catalog with a training module. The department, braced for an eight-month committee purgatory, got a governed yes in six weeks and a support desk at the end of it. Word of this travels faster than any policy memo the institution has ever issued.

Month 6–12. The defense-adjacent institute's enclave takes a perimeter Passport; its control-framework evidence exports as a crosswalk artifact; the next sponsor audit consumes ledger records instead of a quarter of staff time. On the other coast of the org chart, a staff member uses the dissent channel to report an uncertified transcription tool processing disciplinary hearings — cryptographically authenticated as a member with access, identity untransmitted. The tool is registered, tiered T3, held by the Console pending certification. Nobody is disciplined. The reporter's protected status is on the record. The hearing transcripts' chain of custody is reconstructable.

Month 12. The first Institutional Attestation Report is generated: systems by tier, Console metrics, one perimeter certified, one incident repaired, zero personnel actions from ledger records. The president's office sends it to the trustees unedited. The faculty senate cites the Console's hold record — with its binding disposition and one signed executive override, public on the ledger — as evidence the brake is real. Both are describing the same object, which is the treaty working.

The question, answered. Eighteen months in, a contested automated decision surfaces — a financial-aid flag, disputed by its subject through the existing appeal channel. The appeal body asks what the system did, in what sequence, under whose authority, with what inputs, against what version. The T3 Passport's AAE stream answers in an afternoon. That afternoon is the product.

10. Why Existing Platforms Cannot Do This

Every institution evaluating Marble already owns software that resembles a piece of it, and the first internal objection will be "why can't we configure what we have?" The answer, door by door: each incumbent platform owns one surface of the ledger; none owns the object, and none couples a multi-stakeholder disposition to enablement entry as a single event — which is the product.

IT service management platforms hold a configuration management database — an inventory. An inventory records that a system exists; a Passport records that a system is vouched for, by whom, at what tier, with what attestation history and what standing before a governance body. Configuration databases have no tier rubric, no disposition authority, and no concept of a record that a faculty senate can trust because the senate's own elected members signed it.
Data governance and compliance suites map data estates and track regulatory obligations — they are strongest at the Evidence Rails and crosswalk surfaces. But they are operator instruments by architecture: administered by the compliance function, reporting to the compliance function, with no structural seat for the governed. A compliance-suite record satisfies an auditor; it cannot satisfy a bargaining unit, because the bargaining unit had no hand in it and no brake behind it.
Enterprise resource platforms govern their own perimeters superbly and nothing beyond them. Their attestation surfaces end at their own interfaces; a lineage chain that must cross from a student system through an integration bus into a vendor AI tool leaves their jurisdiction at the first hop.
Identity and access platforms are the Identity Anchor nearly whole — non-repudiation, privileged access, separation of duties. They know who; they hold no opinion on whether the system should exist at all, which is the Console's question.
Procurement and vendor-risk tools run the Gate's intake mechanics but terminate at contract signature; the Passport begins there.

Two things no incumbent can be configured into, because they are organizational architecture rather than software features: a Console whose composition the operator does not control, holding mechanical standing in the deployment state machine — no vendor can sell an elected faculty seat; and the coupling — a single ledger event that is simultaneously the governance disposition and the enablement trigger, when every incumbent's certification and service queues are, by design, separate products sold to separate buyers. Marble is deliberately buildable on top of these platforms — they are the doors' native machinery, and an implementation SHOULD reuse them — but the registry they all write to, the tiers that bind them, and the treaty structure that makes their records mutually trusted is the thing none of them ship. That is the build.

11. Roadmap and Companion Artifacts

Marble Tesseract defers, deliberately: reference schema bindings for specific enterprise platforms; the Console's model bylaws and dispute procedure as a standalone governance document; sector profiles beyond the university (the same architecture fits hospital systems and public agencies, whose constituencies rhyme); and the multi-institution question — whether Passports and attestations can federate across a consortium, so that a tool certified at one institution enters a peer institution at T2 with evidence intact. That last is the natural third document in this line, and it is where the Certification-as-Asset door points.

The lineage is now: Obsidian Tesseract — the framework, indifferent to who implements it. Marble Tesseract — the framework load-bearing inside a real institution, with the two structures institutions specifically require: a brake the governed control and an engine the governors want. What Obsidian promised in §15.2, this document delivers; what this document promises, its own §8 will testify to, one way or the other.

12. Strategic Thesis

Universities are about to spend a decade litigating a false question: whether to govern AI or to adopt it. The institutions that suffer least will be the ones that noticed the question was false — that the record which satisfies the senate and the record which unlocks the help desk can be the same record, written once, signed, and kept.

The parent framework observed that opacity is economically rational and must be countered structurally, not rhetorically. Marble's addendum is that inside an institution, the counter-structure cannot be imposed by any single constituency, because each constituency correctly refuses accountability instruments held solely by the others. The ledger works because everyone can read it, the Console works because the governed seat it, the Flywheel works because the governors profit by it, and the whole works because no one — not the administration, not the senate, not the framework's own operators — holds it alone.

That is the parent's Distributed Trust Anchor principle, quarried into institutional stone.

Marble Tesseract is what the before looks like from inside a building.

About This Document

Marble Tesseract is the Reference Implementation Architecture promised in Obsidian Tesseract §15.2, authored by Rhombus Ticks, with technical consultation from TC Ricks (IT Consultant). The profile institution is a composite; the framework draws on operational experience across regulated industries — insurance, healthcare, telecommunications, financial services, and hospitality — and on the accountability traditions of institutions that learned, earlier than most, that a commons survives by being able to answer for itself. Inquiries from universities, systems, accreditors, and standards bodies evaluating adoption are welcome.

End of document — Marble Tesseract PRD v0.3. Red Anvil Creative.

Thursday, July 16, 2026

Marble Tesseract - Institutional Accountability Infrastructure for the Governed Adoption of AI and Enterprise Systems