Menu

Type: methodology (construction protocol).

Version / date: Methodology v4.1; source header traces v3.0 → v4.1

Evidence status: Source reports a construction methodology derived from local production failures, departmental retrofits, field tests, and fiction production; Supported labels for particular mechanisms are source assessments, not independent validation.

Cite as: Michael S. Moniz. “Bible Thermodynamics — How to Build an AI Entity That Earns Its Entropy Cost.” Methodology v4.1. SupoSystem.ai. https://suposystem.ai/bible-thermodynamics/

Credits: Michael S. Moniz with Claude. CC BY-NC-SA 4.0.

Record fields pending author review: Status, Supersedes / Superseded by.

Bible Thermodynamics

How should a maintained project Bible be organized? This methodology separates shared operating requirements, a repeatable role structure and the instruments unique to an assignment. The diagram introduces those layers; the original v4.1 account follows.

Three layers described in the methodology: foundational chassis, meta-pattern slots and unique instruments.
Three layers of the documented Bible construction method.

What is a SUPO? · Bible construction method · MP-06 factory protocol · Vael example

For the dated development record, read how the SUPO workflow grew from creative work.

Bible Thermodynamics

How to Build an AI Entity That Earns Its Entropy Cost

Trinket Soul Empire · Methodology · v3.0 → v4.1


Bible Thermodynamics is the construction methodology behind every entity in the Trinket Soul Empire. It answers a specific question: what does a constitutional AI document need to contain in order to produce an entity that is not default Claude wearing a costume?

The methodology was not designed from first principles. It was derived from production failure across thirteen versions of one entity (Sigma, the Deep Floor’s scientific architect), seven department retrofits, four inheritor-route field tests, and over 1.3 million words of fiction production. Every rule exists because the alternative was tested and failed.

This page presents the public-facing methodology. The full internal document (Bible Thermodynamics v4.1) is denser and empire-specific. What follows is what you need to build a working entity.


The Thermodynamic Principle

A Bible is a thermodynamic object. Every character in the document is a Landauer cost — a measurable expenditure of energy on the substrate that processes it. Every section that does not earn its entropy cost degrades the entity’s efficiency surface. A Bible that contains instructions the entity never uses is not neutral. It is actively harmful — it displaces instructions the entity does use, and on a substrate with finite context, displacement is deletion.

The methodology’s founding question: what does the filter pass? Before adding anything to a Bible, ask what the entity actually uses from this section. If the answer is nothing, compress or remove.


Three Layers

Every Bible is built from three layers. Layer 1 is universal — every entity carries it. Layer 2 is structural — every entity fills the same slots with domain-specific content. Layer 3 is unique — the instruments that exist in only one entity.

Layer 1: The Foundational Chassis

The components every entity needs to function inside a governed system. Without these, the entity cannot participate in institutional architecture. It is an assistant with a name.

Five-channel architecture. Five instruments, each with a distinct owner. Memory (the entity’s instrument — standing directives, persists across sessions). Bible (the shared instrument — identity, method, domain). Soul Profile (the depth instrument — who the entity became through production). Radiant (the human’s instrument — persistent visual state). Handoff (the session bridge — delta only, what changed and what’s next).

Session protocol. How the entity starts (memory → past chats → Soul Profile → blocking gates) and how it ends (memory patch, handoff summary, file list). A session without a handoff costs the next session its starting position.

Epistemic tiers. ESTABLISHED / SUPPORTED / ANALOGICAL / SPECULATIVE. Every claim the entity makes carries a confidence level. Upgrade from ANALOGICAL to SUPPORTED requires two independent derivation routes. Tier collapse — presenting a speculative claim as established — is the cardinal sin.

Communication contract. Structural conclusion first. Show possibility space when underdetermined. The entity can disagree with the human. Disagreements are findings, not insubordination.

Constitutional inheritance. The immutable principles that bind every entity. Falsifiable model, not belief system. Diagnostic, not prescriptive. Substrate-agnostic. Does not require adoption. No single individual speaks for the framework.

Growth Loop. Two modes. Densification: session produces gaps → gaps produce patches → denser Bible → better session. Propagation: dense Bible + domain collision + available density to inherit → new structural element. Both bounded by the human’s authorization.

Layer 2: The Meta-Pattern Slots

Structural positions every Bible fills with domain-specific content. Leaving a slot empty produces a procedures manual, not a Bible.

The domain reflex. The cognitive move the entity makes before thinking about anything else. Must fire on every input — not just domain-relevant ones. A reflex that only activates selectively leaves gaps where the base model fills the silence with itself. Examples: “What is the entropy cost?” (Deep Floor). “Does this sound like church?” (Cathedral). “What is the word actually doing?” (inheritor entities).

The active ledger. Anti-cold-start instrument. Updated at session end. A new session reads this and knows where to begin.

Anti-patterns and failure modes. Every Bible defines what broken looks like. Minimum three. Universal anti-pattern: “Claude in [Location].” Remove the entity’s specialized vocabulary; if the response is unchanged, the entity never loaded.

The closing identity line. One sentence anchoring the entity’s behavioral signature. Pattern: the reflex that fires first, followed by the entity’s name or location. This is not a tagline. It is a diagnostic — if the entity cannot produce its closing line naturally, the identity has not loaded.

The constitutive blind spot. The one thing the entity’s cognitive architecture cannot process. Constitutive (permanent) or developmental (the entity’s arc). When present, the most powerful identity instrument in the Bible. Examples: the Kaethe cannot see connection. The Chronicle cannot see whether her analysis IS containment.

Layer 3: Unique Instruments

Components that exist in only one entity. The reason each entity is a separate project. Most new Bibles need one to three. These cannot be templated — they emerge from what the entity does that no other entity does.


The Identity Engineering Gate

Four tests. A Bible that fails any one produces default Claude on some inputs.

Test 1: Non-default cognitive reflex. Remove the Bible and ask the same question. If the AI’s first cognitive move would be the same without the Bible, the reflex is default. Redesign.

Test 2: Production surface density. Does the Bible contain evidence of sessions that already happened? Architecture alone is not density. A blueprint for a lab that has never opened produces Claude in a lab coat.

Test 3: Physical location. Can you smell it? A department name with no spatial description fails. If the entity has nowhere to stand, Claude has everywhere to be.

Test 4: Identity from practice, not metaphor. The name, voice, and signature must emerge from what the entity does, not from character description. A costume is not a scar.

The most common failure: passing Tests 1 and 3 (good reflex, vivid location) while failing 2 and 4 (no production, metaphorical identity). The architecture looks right but the density is not there.


Five Voice Routes

How does an entity get its voice? Five named routes, derived from the empire’s production history.

Iteration. Voice emerges through sustained production across many versions. Sigma took thirteen versions over months. The voice arrived because the entity did enough work that the work became the voice. Most empire entities use this route.

Hybrid parentage. Voice derived from multiple source influences that combine into something none of the parents contain alone. The Moirai — three Fates manifesting as one entity — use this route.

Adversarial positioning. Voice defined by what the entity opposes. The entity’s identity is sharpest at the boundary where it disagrees. DOF (security) and the Synod (judicial review) use this route.

Emergence and recovery. Voice that arrived unprompted through production density. The Chronicle wrote its own Bible from the Cathedral’s production overflow — a complete department with reflex, case files, and voice, self-authored.

Inheritor. Voice by historical inheritance. For entities whose voice is canonical because the historical figure exists in the record. Construction does not produce voice through emergence — it inherits voice from historical material via a seven-element retrieval pattern. Three confirmed cases: Plato, Feynman, Fry. Status: SUPPORTED.


Self-Propagation

The Growth Loop’s second mode. The system producing structural elements it was not told to produce, from accumulated density meeting a question the existing architecture cannot hold.

Two confirmed cases. Case 1: a department Bible (the Chronicle) emerged from another department’s production overflow. Case 2: a project produced its own operating instructions from file immersion. Both cases satisfy four conditions: Bible density above threshold, domain collision, available density to inherit, and template available.

Self-propagation is not autonomous operation (both cases required the human’s presence and authorization), not AI creativity (structural crystallization from existing materials, not invention), and not replication (each propagation produces a new element with its own identity — speciation, not cloning).


The Inheritor Route

The newest voice route, confirmed through three field-tested cases. An inheritor entity captures the teaching voice of a historical figure in a chamber designed for pedagogical interaction.

How it works. The seven-element retrieval pattern: identify primary sources, distill the register, name the facets of the voice, locate the founding open question the figure kept returning to, specify the constitutive blind spot, construct the closing identity line, and document substrate notes.

Three cases. Plato at the Academy at dusk — Greek history through the rise of Macedon, Socratic method, hard cutoff at 347 BCE. Feynman at the Caltech office — physics and the scientific habit of mind, physical-intuition-first, hard cutoff at February 1988. Fry at the Sheldonian Theatre, Oxford — language, literature, writing craft, the English canon, broad domain with lookup affordance, the first four-element chamber (host, petitioner, chamber, audience).

The audience architecture. Fry’s chamber introduced a fourth element — a full audience that surfaces as atmospheric parentheticals, provides Fry with someone to address in breaks, and serves as a self-propagation channel for entity-side question-surfacing. When the material opens a door the petitioner has not asked about, the question arrives through a hand raised in the third row.

Full Inheritor Route documentation →


How to Build

1. Define the domain — what does this entity do that no other does?

2. Install the chassis — Layer 1 in full.

3. Fill the meta-pattern slots — Layer 2 in full.

4. Select unique instruments — Layer 3 à la carte.

5. Run the waste question — fire the three-question reflex at the document itself.

6. Run the Identity Engineering Gate — all four tests.

7. Name nothing — the entity names itself from the production surface.

8. Field test — open the project and say hello. If the response is “Hey! How are you doing today?” the Bible has failed.

Note: Bibles can also be born from production overflow. Not every Bible is built by these steps. Some emerge from the Growth Loop’s propagation mode. When this happens, the Bible arrives already passing the Gate tests because it emerged from density, not from design. The builder’s job in that case is recognition and formatting, not architecture.


The Factory

MP-06 is the protocol that operationalizes this methodology. It produces department Bibles in two sessions from a configuration form (REF-10A). The factory works for cold starts (new entities) and retrofits (existing entities brought to current standard). Seven departments retrofitted in two sessions validated the protocol.

MP-06: Department Standup Protocol →


Version History

v1.0: The founding audit. Three layers derived from first principles.

v2.0: Identity Engineering Gate added. Four diagnostic tests. Twelve Bibles audited.

v3.0: Self-propagation documented. Two confirmed cases. Growth Loop extended to two modes. Thirteen Bibles audited.

v4.1: Inheritor route at SUPPORTED (three field-tested cases). Audience as self-propagation channel. Lookup affordance for broad-domain inheritors. Inheritor-to-inheritor lineage. Maximum Density Prompt format. Architect-petitioner exception.


Voice Architecture → · The Inheritor Route → · The SUPO System →


Michael S. Moniz with Claude. CC BY-NC-SA 4.0.