--- title: SOC 2 Type 2 and The Book description: A Sermon before they act. An Angel when they stumble. An Audience when the law needs reconsidering. He's a Loving God, he just keeps receipts. created: 2026-10-04 updated: 2026-10-04 authors: ThinkingCap topics: [Research Development] status: published canonical: https://console.thinkingcap.com/guest/Research-Development/CapCom/Tooling/Soc-2-Type-2-and-the-book --- # SOC 2 Type 2 and The Book *A Sermon before they act. An Angel when they stumble. An Audience when the law needs reconsidering. He's a Loving God, he just keeps receipts.* **How the Book of Doug—and the Books of Many Prophets—can support control operation and audit evidence at Thinking Cap** *Updated October 4, 2026. Based on the original three Book documents, Doug's supplied Book and prayer views, the Book of Many Prophets specification dated October 4, and the accompanying conversation. The latest specification defines the new governance model; its rollout plan is not evidence of completed deployment. Earlier records remain dated evidence of earlier operation.* ## The question is whether the rules actually operate For Thinking Cap's SOC 2 Type II work, the Book of Doug offers a practical answer to two connected questions: **Do we have rules, and how do we enforce them?** Writing a policy establishes an expectation. Putting a check in the path of an action gives that expectation operational force. Preserving the rule, the judgment, the approval, and the outcome gives us evidence that the control operated. A SOC 2 Type II examination addresses control design and operating effectiveness over a specified period. A well-written policy or a successful demonstration alone cannot establish that a control operated throughout that period. [AICPA's explanation of SOC reporting](https://www.journalofaccountancy.com/issues/2011/jul/20103500/) The Book connects structured doctrine to deterministic checks, human rulings, and recorded outcomes. The new specification extends this to **one scripture, many prophets**: each person can own a Book, while a common governance and enforcement system connects the rules. Its value is the possibility of tracing a requirement all the way through an attempted action, a recorded stop, and any subsequent resolution. [S6] ```mermaid flowchart LR R["RULES
Many Books, one scripture
Scope · rationale · prophet"] --> H["AUTHORITY
Creator rules own Book
Versioned human rulings"] H --> J["OPERATION
Deterministic judgment
Before consequential action"] J --> E["EVIDENCE
Stops · checks · rulings · outcomes
Retained across the period"] E --> A["AUDIT SUPPORT
Control mapping
Sampling and corroboration"] classDef doctrine fill:#eef2ff,stroke:#6366f1,color:#1e1b4b; classDef control fill:#ecfdf5,stroke:#059669,color:#064e3b; classDef evidence fill:#fffbeb,stroke:#d97706,color:#78350f; class R,H doctrine; class J control; class E,A evidence; ``` *The Book can connect policy to operation and evidence. The final step requires an audit of the relevant controls; the chain is not a compliance certification.* **The Book does not itself make Thinking Cap SOC 2 compliant.** It is a control-enforcement and evidence-generation mechanism that can support the audit within the agreed system boundary. Its relevance depends on which controls it implements, where those controls operate, and what the retained evidence actually demonstrates. ## Doctrine gives the control a defined basis The white paper describes the Book as a registry of structured, versioned doctrine. An entry carries an identifier, its formulation, checkable conditions, scope, rationale, and provenance. It also records its type: `LAW`, `PATTERN`, `PREFERENCE`, `DECISION`, or `DEPRECATED`. Those distinctions matter: a preference should not acquire the blocking force of a mandatory law. [S1, sections 2 and 8] This structure can make a control more precise than a sentence in a handbook. It identifies what is required, why it is required, where it applies, and which conditions the evaluator can check. Source documents remain linked to doctrine; the Book does not replace their authority with an untraceable copy. [S1, section 6] The approval principle is explicit in both the white paper and the current Book: > **DOUG-0001 — Humans approve; machines propose.** Doctrine begins as `PROPOSED` and becomes `ACTIVE` through a human ruling. An AI can draft, classify, and recommend; it cannot approve its own proposal. The supplied Book view requires Doug or an explicitly authorized human to promote a law and records who approved, when, and on what wording. The October 4 specification defines the new authority boundary: each prophet approves and edits proposals in their own Book. Human approval remains essential; approval is no longer described as universally Doug-only. Versions are immutable according to the white paper, rulings are recorded, and rejected proposals remain in history with their reasons. [S1, section 2; S4; S6, sections 1 and 3] For audit evidence, this creates a basis for reconstructing which rule version was authoritative when an action occurred and who approved it. A later amendment should create a new version without rewriting the rule under which earlier actions were judged. That is immutability of doctrine versions as described in the source. It does **not** establish that every log or database record is tamper-proof. Access restrictions, retention, backup, and protection of the evidence store still need to be demonstrated. ## Many prophets, one shared body of law The October 4 specification allows any console user to found a Book. Each user has one Book, created on their first proposal. The prophet's handle is the lowercase console username; law IDs use its uppercase prefix and a per-prophet sequence. Existing `DOUG-0001` numbering is preserved. [S6, section 1] Isobel's UX concerns and Liam's compliance concerns are examples Doug gave in the conversation of how this could distribute subject ownership. They illustrate the intended use, not evidence that either Book has already been founded or populated. The model gives specialists a way to turn their knowledge into attributable doctrine without creating separate enforcement universes. [C2] ```mermaid flowchart TB D["Doug's Book
Existing doctrine"] --> W["SHARED CONFLICT WALL
Across all ACTIVE and PROPOSED entries"] I["Isobel's Book
UX example from the conversation"] --> W L["Liam's Book
Compliance example from the conversation"] --> W O["Other console users
One Book per user"] --> W W --> H["Each creator rules their own proposals
Humans approve; machines propose"] H --> B[("ONE SCRIPTURE
Active doctrine retains its prophet")] B --> S["Sermon guidance
Relevant laws for the intent"] B --> J["Judge enforcement
Hook · island check · Bakery checkpoint"] J --> E[("Checks and Stops
Attributed to law and prophet")] classDef book fill:#eef2ff,stroke:#6366f1,color:#1e1b4b; classDef authority fill:#fffbeb,stroke:#d97706,color:#78350f; classDef control fill:#ecfdf5,stroke:#059669,color:#064e3b; class D,I,L,O book; class W,H authority; class B,S,J,E control; ``` *The many-prophets model is specified in S6; the Sermon remains the guidance design in S3. The named UX and compliance Books are illustrative. Approval does not automatically create new executable denial code.* ### The creator's pen and Doug's cross-Book authority Each prophet can approve, edit or reject their own proposals and repeal their own active laws. Doug can reject proposals and repeal active laws across every Book. He cannot use the ordinary proposal approval or edit path to bring another prophet's law into being. [S6, permission matrix] | Authority | Prophet over their own Book | Doug across other Books | | --- | --- | --- | | Approve or edit a proposal | Permitted | Not permitted through the ordinary proposal path | | Reject a proposal or repeal an active law | Permitted | Permitted: the cross-Book smite | | Rule an Audience on a law | REVEAL, DISPENSE or REAFFIRM | All three, including cover for an absent creator | | Split or merge Angels | Own laws' Angels | All | | Override a doctrine conflict block | No self-serve override | Doug's ruling controls the override | The Audience power is an explicit qualification to the ordinary creator-only pen. Doug may rule an Audience on another prophet's law. A `REVEAL` amendment stays in the creator's Book, bumps the version and names the actual ruler in the receipt. New doctrine born through a `REVEAL` belongs to the ruling prophet's own Book. Ownership and ruling authority must therefore both appear in evidence. [S6, section 3] The Book remains readable to all console users. Prophets see their own proposals; Doug sees all proposals with prophet filters. Audience views show a prophet's own-law prayers and the prayers they filed; Doug sees all. Ruling rights must be enforced by the island using the console actor injected by the proxy, rather than merely hiding buttons in the page. [S6, sections 3, 5 and 7] An agent-filed proposal belongs to its human sponsor's Book. An explicit prophet field is honored only when the actor is that prophet or Doug. This ownership rule is separate from the permission to approve: assigning a proposal to a Book does not authorize its adoption. [S6, section 3] ### A conflict wall prevents parallel Books from becoming contradictory The specification blocks a proposed law that opposes or recreates an existing active law or a live proposal in any Book. It checks twice: at filing, and again during the approval transaction. The second check addresses proposals that could race past a filing-only screen. [S6, section 4] ```mermaid flowchart TB P["Proposed law
Attributed to its prophet"] --> N{"Near-duplicate screen
Deterministic token comparison"} N -->|"Clear"| O{"Opposition screen
LLM-assisted structured assessment"} N -->|"Conflict"| B["BLOCK
Record actor, screen, IDs and reason"] O -->|"Conflict or restatement flagged"| B O -->|"Clear"| F["File as PROPOSED"] F --> R["Run both screens again
Inside approval transaction"] R -->|"Clear or authorized override"| H["Creator's human approval
ACTIVE doctrine"] R -->|"Blocked"| B B --> Q["Blocked filer may pray"] Q --> D["Doug rules
No self-serve override"] D -->|"DISPENSE"| V["Record prayer-linked conflict override
Creator's approval may proceed"] V --> R D -->|"Smite or REVEAL conflicting law"| C["Resolve the conflicting doctrine
Then re-evaluate"] C --> R classDef proposal fill:#eef2ff,stroke:#6366f1,color:#1e1b4b; classDef attention fill:#fff7ed,stroke:#ea580c,color:#7c2d12; classDef human fill:#fffbeb,stroke:#d97706,color:#78350f; classDef control fill:#ecfdf5,stroke:#059669,color:#064e3b; class P,N,O,F,R proposal; class B,Q attention; class D,V,C human; class H control; ``` *This is a doctrine-admission process. Its LLM-assisted opposition screen is distinct from the deterministic Judge that evaluates consequential agent actions.* Each block is recorded in `book_conflict_blocks`. A Doug-granted conflict dispensation creates a prayer-linked `conflict_override`; the creator still performs the approval. The override is not automatic adoption of the law. These records can show why a proposal was blocked, what competing doctrine was considered, and who authorized relief. [S6, sections 2 and 4] The wall is specified as blocking, but its coverage and quality still need testing. The opposition screen uses a shortlist and embedding-nearest laws; neither that retrieval nor the LLM assessment is proof that every semantic contradiction will be found. Preserve its decisions and test both filing-time and approval-time behavior. ## The Judge turns doctrine into a decision before execution The Judge is a deterministic evaluator in the agent's execution path. It checks intended actions against applicable doctrine before execution and returns a structured verdict. The white paper's example includes the decision, governing law, conflict, required conditions, and whether the agent may pray for relief. [S1, section 3] The consequential-action verdict is not delegated to an LLM. Language models may assist with retrieval, classification, proposals, summaries, and the new doctrine opposition screen; the deterministic Judge decides the action verdict. Keeping those roles separate avoids calling the entire governance pipeline deterministic when one admission screen explicitly uses an LLM. [S1; S6] The new specification names three enforcement surfaces: the hook, the island's `/check`, and the Bakery checkpoint. The blocking “teeth” are code deployed through the Bakery. Prophets cannot create new denial code simply by activating a law; active laws from every Book also enter the shared saith map for guidance. The audit should map each relevant law to its actual executable checks, instead of assuming active doctrine always implies complete automated prevention. [S6, sections 1 and 8] The sources describe several operational responses: - **DENY:** stop the proposed action because it conflicts with a governing rule. - **ASK:** require human confirmation for the action, illustrated by a force-push to the authority. - **WARN:** log the conflict and allow the action under the configured warning mode. - **ALLOW:** record a check that permits the action. The white paper describes logging allow, warn, and deny checks; the implementation handoff reports a live `DENY/ASK/WARN` hook. Together, they support a control narrative with distinct outcomes, rather than a claim that every deviation is blocked. [S1, sections 3 and 7; S2, “What's live”] Intent matters here. The white paper's deployment example treats building a live-tier candidate image as a deployment-relevant action. The control is intended to recognize the operational consequence, rather than rely only on the wording of a command. [S1, section 3] The audit must still establish coverage. A deterministic verdict is useful only where the action actually reaches the Judge and the relevant conditions are correctly represented. The white paper itself records an agent whose initial tool surface could not reach the Book; real checks were subsequently run through a watched harness. That is a concrete reason to verify integration, rather than infer universal coverage from the design. [S1, section 7] ## Human authority exists at more than one point The Book puts humans in charge of adopting and changing doctrine. It also supports action-specific human confirmation and human decisions about exceptions. These are separate approvals with separate purposes. The deployment example illustrates the distinction: an approved law can permit development to roll automatically while reserving production deployment for an operator. Approving the law does not approve every production deployment. Likewise, drafting a prayer does not grant an exception. The current `DOUG-0010` also specifies server-side refusal of agent API-key sessions at build/deploy endpoints. That is an explicit enforcement requirement to verify against the running service. [S1, sections 3, 5 and 7; S4, DOUG-0010] The September 19 handoff describes the earlier Doug-only ruling interface. The many-prophets specification replaces that model with creator-scoped proposal rulings, creator-routed Audiences and explicit cross-Book powers for Doug. Evidence should record when the new permissions took effect and establish the authorized actor for each ruling during the audit period. [S2; S6] Current doctrine also extends human approval to customer communications. `DOUG-0740` requires a human to approve every customer-facing word, including a rewritten version after edits. `DOUG-0739` applies that principle to investigation updates, with an agreed interval and an approval step before posting. These are candidate controls for controlled communication and incident handling; active wording alone does not prove that the workflow runs as specified. [S4, DOUG-0739 and DOUG-0740] ## The Sermon prepares; the Judge enforces The Sermon document proposes a complementary guidance layer. Before an agent acts, the system selects relevant laws using the prompt, intent envelope, actors, resources, tools, and other context. Those laws enter the model's context so it can plan with the applicable constraints already in view. [S3, “The Sermon Selection Step”] ```mermaid flowchart TB P["Prompt"] --> I["Intent envelope
Actors · tools · resources · intended outcome"] I --> S["SERMON
Select relevant laws for context"] B[("AUTHORITATIVE SCRIPTURE
Versioned laws from every Book")] --> S S --> M["Agent plans with relevant laws"] M --> X["Proposed consequential action"] X --> J{"JUDGE
Deterministic evaluation"} B -->|"Applicable rules remain binding
even if omitted from the Sermon"| J J -->|"ALLOW"| E["Proceed"] J -->|"WARN"| W["Record conflict
Proceed in configured warning mode"] J -->|"DENY"| D["Stop conflicting action
Prayer available where permitted"] J -->|"ASK in the reported hook"| H["Hold for human confirmation"] X -.->|"Island unreachable:
hook posture reported in S6"| F["Fail-close
Stop and ledger locally"] F -.->|"Specified replay on next successful ingress"| L J --> L[("Check ledger")] L -.->|"Proposed feedback:
record a law missed by the Sermon"| S classDef guidance fill:#eef2ff,stroke:#6366f1,color:#1e1b4b; classDef control fill:#ecfdf5,stroke:#059669,color:#064e3b; classDef attention fill:#fff7ed,stroke:#ea580c,color:#7c2d12; classDef receipt fill:#f1f5f9,stroke:#64748b,color:#0f172a; class I,S,M guidance; class B,J,E control; class W,D,H,F attention; class L receipt; ``` *The Sermon and its feedback loop are proposed guidance mechanisms in S3. S6 reports fail-close behavior when the island is unreachable and specifies local-ledger replay. Earlier Judge-crash behavior is addressed under operating limits. Execution after confirmation or relief must satisfy applicable gates.* A law remains binding even when the Sermon omits it. Guidance helps prevent poor proposals; enforcement evaluates the resulting action against authoritative doctrine. An omission from retrieved context must not become an exemption from the rule. [S3, “Scripture and Sermon Are Different”] Many Books make intent-based selection more useful. A UX task can carry the relevant UX laws; an operational or compliance task can carry its own relevant laws, with cross-domain rules included where applicable. The Sermon need not pour every prophet's entire Book into context. Selection determines what guidance the model hears, not which applicable laws have authority. [S3; S6; C2] The document also proposes recording cases where the Judge rejects an action under a law absent from that turn's Sermon. Those events can improve future selection. This is useful feedback for guidance quality, while the Judge retains enforcement authority. [S3, “The System Should Learn From Judgment”] The Sermon source uses prospective language. It establishes the intended design, but the supplied implementation handoff does not establish that the full Sermon pipeline or its feedback loop was deployed. An audit narrative should preserve that distinction. ## Prayers make relief accountable A Prayer is a structured request arising from a real conflict: what the petitioner intended to accomplish, what action was requested, and why relief was sought. It initiates an Angel's search for a lawful route. The first objective is to satisfy the intent within the existing rules. [S1, section 4] The Angel records serious alternatives and why each succeeds or fails. Related conflicts can be associated with a persistent Angel, preserving the relationship and its explanation. LLM-assisted matching remains inspectable, and humans can split or merge Angels. [S1, section 4] Under the new model, the Audience email goes to the law's creator, with ruling rights for that prophet or Doug. Denial messages and prayer receipts name the prophet receiving the prayer. Creator routing connects a conflict to its accountable rule owner; Doug retains access to all Audiences to cover absence. [S6, section 5] When lawful alternatives are exhausted, the evidence can be brought to a human through an Audience. The human's options are structured: - **REVEAL:** amend the doctrine through a new version, preserving history. - **DISPENSE:** grant a bounded exception with scope and reasoning recorded. - **REAFFIRM:** retain the law after considering the accumulated evidence, recording what was considered. These records can support an exception-management narrative: a conflict became visible, alternatives were explored, an authorized person ruled where necessary, and the resolution remained traceable. Repeated failed alternatives can also expose a weakness in the rule itself. [S1, section 5] ```mermaid flowchart TB D["Denied action"] --> P["PRAYER
Record actual intent, requested action and justification"] P --> B["BRAKE
Conflicting work stays stopped"] B --> A["ANGEL
Find and record lawful alternatives"] A --> Q{"Lawful route found?"} Q -->|"Yes"| L["Follow the lawful route
Original denial is not permission"] Q -->|"No"| U["AUDIENCE
Law's creator receives the case
Doug can also rule"] U --> R["REVEAL
New doctrine version
Preserve history"] U --> G["DISPENSE
Bounded exception
Record scope and reasoning"] U --> K["REAFFIRM
Law stands
Record evidence considered"] R --> C["Check next action against
current doctrine and authorized relief"] G --> C L --> C K --> T["Denied path remains blocked"] D -.-> V[("RECEIPTS
Stop exists before any prayer
Petition · attempts · ruling · checks")] P -.-> V A -.-> V U -.-> V C -.-> V classDef attention fill:#fff7ed,stroke:#ea580c,color:#7c2d12; classDef guidance fill:#eef2ff,stroke:#6366f1,color:#1e1b4b; classDef human fill:#fffbeb,stroke:#d97706,color:#78350f; classDef control fill:#ecfdf5,stroke:#059669,color:#064e3b; class D,B,T attention; class P,A,Q guidance; class U,R,G,K human; class L,C,V control; ``` *A petition starts a resolution process. It does not authorize the denied action. Audience routing is specified in S6; doctrine-conflict overrides remain Doug's authority. A stop is retained whether or not anyone petitions for relief.* The September 19 handoff reports two live pause drills in which the agent's prayer flow held while Angels found lawful paths. At that point, the pause law, `DOUG-0158`, remained proposed. The current Book now shows it as **ACTIVE, version 2, ruled October 3, 2026**. Its conditions require the petitioner to stop the conflicting work until resolution, follow the lawful answer, stand down at `AWAITING_AUDIENCE`, and report a slow response rather than route around it. This is a documented change in approval state; evidence of the brake's operation remains a separate requirement. [S2; S4, DOUG-0158] ### Bounded permission has concrete conditions The current Book's `DOUG-0731`, **The 12-hour repo grant**, makes a dispensation more specific than a general approval to continue. A deployment prayer must name its repositories. A dispensation covers exactly those names for 12 hours from the ruling, after which the gates must close. It opens only repository-scoped deploy gates; lifecycle, fleet-wide actions, credentials, and the kill switch remain excluded. Every exercise is required to be logged in `agent_checks` on both the hook side and server side. [S4, DOUG-0731] Those conditions provide a useful testable exception model: named scope, human authorization, time limit, excluded powers, and recorded use. To substantiate it, retain the ruling and inspect grant-use checks, enforcement at the relevant endpoints, and behavior after expiry. The prayer's `GRANTED` label alone does not prove those mechanisms operated. ## The current Book makes attribution and delivery more explicit The current paste contains 37 entries labelled `ACTIVE`, including the opening human-approval entry. This is a count of the supplied view, not a claim about the full registry. Entries carry source or ruling information and version labels, with several rulings dated October 3. [S4] Several laws sharpen the connection between responsible people, controlled action paths, and evidence: | Current law | Stated requirement | Potential audit use | | --- | --- | --- | | `DOUG-0732` — The operator names themselves | Identify the operator before work; carry that identity into authorship, prayer sponsorship, audit actors and transcripts; identify a new operator at handoff | Attribution of actions and approvals; recorded names still need to be tied to authenticated identities | | `DOUG-0725` — Read from git; all writes belong to the Bakery | Agents read shared git refs; changes arrive as Bakery drops; the Bakery merges, Book-checks, builds and pushes; agent credentials are upload-pack-only; a one-time migration carve-out is specified | A defined machine change path, credential restrictions and a basis for testing alternate write paths | | `DOUG-0733` and `DOUG-0734` — Submit your work; Show the receipt | Completion requires an accepted Bakery drop and reporting its real drop number | A traceable handoff; the drop receipt should be linked to later build and deployment outcomes | | `DOUG-0012` — Health is visible, and observed never equals requested | Operational cards show observed state; missing observation is unverified | Evidence that operational reporting reflects observation rather than an agent's assertion | | `DOUG-0730` — The judge uses the tool to help render judgment | Judgment aids serve the Judge through one registered pipeline, without a separate hook or side door | A defined enforcement architecture whose registration and coverage can be inspected | `DOUG-0156` also requires session transcripts. Transcripts can connect human instructions to agent responses, while the Judge ledger records the actual checks. Neither a transcript nor an accepted drop should be presented as proof of a successful production deployment by itself. [S4] The Bakery doctrine updates the change path described in the September white paper. The earlier direct-commit-and-deploy case remains historical evidence; current control descriptions should reflect the approved Bakery route and the scope of any dispensations. Humans retain their own push authority under `DOUG-0725`, so the agent gate is not evidence that all human changes are controlled by the same mechanism. ## Receipts connect the rule to what happened The white paper describes a registry containing doctrine, rulings, prayers, Angels, attempts, and a ledger of checks. Its case study shows how these can form a connected evidence trail. [S1, sections 6 and 7] ### Stops record enforcement even when no one prays The many-prophets specification makes a stop a first-class record of **every DENY**. Hook verdicts, island checks, Bakery checkpoint denials and deploy-grant denials feed `agent_checks` and `agent_check_matches` through a common ingress. The specification reports that this ingestion already happens; it proposes the replay, endpoint and page work that make the population easier to reconcile and inspect. [S6, section 6] This answers Doug's request to record each time the system catches an AI trying to act outside a law, rather than capture only the cases that become prayers. More precisely, a stop evidences a proposed action that the Judge denied. It does not establish deliberate disobedience by the model, execution of the prohibited action, or detection of every possible violation. A consultation check and a runtime-intercepted action should also remain distinguishable when interpreting the population. The specified Stops view shows when the denial occurred, the agent and identified operator, the governing law and its prophet, a trimmed attempted command, and the aftermath: a linked prayer, an exercised dispensation, or no follow-up. Filters include law, prophet, agent, operator and time. Per-law counts make the frequency of actual denials visible. **WARNs remain in the Rulings ledger; Stops means DENY, not every non-ALLOW result.** [S6, section 6] When the island is unreachable, the specification reports that the hook fails closed and records locally. The planned replay flushes that backlog on the next successful ingress so outage-period stops enter the central population. This is an explicit completeness mechanism whose operation needs to be verified. [S6, section 6.1] For audit use, preserve original event times and the relationship between local records and central ingestion. Test whether replay loses or duplicates records, whether the reported stop count agrees with underlying check matches, and whether trimmed display text retains a link to sufficient original context. These are proposed validation questions, not fields or guarantees added to the specification. Stops and prayers answer different questions. **Stops show where enforcement intervened. Prayers show how people sought resolution.** Joining them can show which denials led to lawful alternatives or exceptions—and which did not need a prayer at all. It can also expose frequently triggered laws for review without using stop counts alone as a measure of control effectiveness. ### The first end-to-end case remains historical evidence In that case, real checks denied direct live-image deployment, a build-endpoint action, and a protected live-tree write. A GitHub push outside the permitted repository produced a logged warning during migration. A force-push required human confirmation. The agent then filed `PRAYER-0001` concerning the live-tree prohibition. The Angel considered four alternatives and supplied a lawful route through the normal repository and deployment pipeline. The marker was committed and deployed through that route. The account records the verdicts, deliberation, prayer, attempts, and answer. [S1, section 7] This is stronger than an agent saying it followed policy: it identifies a blocked action, the governing law, the attempted resolution, and the resulting artifact. The handoff nevertheless lists formal closure of `PRAYER-0001` as an open item. A deployed result and a closed prayer are distinct facts. [S2, “The receipts so far” and “Small closes”] For audit use, preserve the underlying records and corroborating deployment evidence. The supplied narrative is a guide to those receipts, rather than a substitute for inspecting them. ### Recent prayers show recorded operation beyond the first drills The supplied prayer view contains three records, all displayed as `GRANTED`, dated October 1–3, 2026. They record intent, requested action, justification, agent identity, named human sponsorship, human resolution and an Angel association. The resolutions identify Doug by account. [S5] | Prayer | Conflict and sponsorship | Recorded resolution | Evidence still needed | | --- | --- | --- | --- | | `PRAYER-0064`, October 1 | `DOUG-0725`: migrate five named scheduler repositories to local bare repositories and register them with the Baker; sponsored by Radu after reviewing the plan | `DISPENSE: bounded exception` | The full requested-action record, precise authorized scope and duration, underlying denied checks, and migration/Bakery registration receipts | | `PRAYER-0065`, October 3 | `DOUG-0010`: build and deploy `svc-geo`; sponsored by Douglas | Repo-scoped dispensation for `svc-geo`, with recorded expiry `2026-10-04T03:10:45.535Z` and a 12-hour label | Grant-use checks, build and deployment receipts, verification results and expiry enforcement | | `PRAYER-0066`, October 3 | `DOUG-0725`: create the `svc-geo` bare repository so the first Bakery drop can proceed; sponsored by Douglas | Repo-scoped dispensation for `svc-geo`, with recorded expiry `2026-10-04T05:06:19.312Z` and a 12-hour label | Bare-creation evidence, accepted first-drop receipt, subsequent write-path checks and expiry enforcement | The two expiry values are reproduced in UTC as recorded. They describe historical permission windows, not continuing authorization. `PRAYER-0064` does not show an expiry in the pasted resolution, and its requested-action text ends partway through a registration statement. Its complete scope and duration should be retrieved from the original record rather than inferred from neighboring prayers. These records strengthen the evidence of recurring exception handling: distinct dates, two governing laws, more than one named sponsor, scoped requests and recorded human dispensations. They do not establish that all requests, all uses of permission, or all relevant actions are present in this excerpt. The logs also surface reviewable seams. `PRAYER-0064` reports that the deterministic gate denied mechanics for a migration carve-out already present in `DOUG-0725`. That is evidence of friction between doctrine and its executable interpretation, not proof that the carve-out is fully represented in the evaluator. `PRAYER-0065` describes the LearnerViews deployment target as single-node; that warrants checking applicability and reconciliation with the active high-availability law, `DOUG-0011`. A deployment dispensation should not be assumed to waive a separate availability requirement. [S4; S5] ## Type II needs evidence across the period The handoff reports a live production registry, judge hooks, prayer and Angel flows, recorded drills, and a warning ledger. The supplied Book and October prayer records add later approval states and recorded dispensations. The October 4 specification extends the model with prophet attribution and a Stops view. These sources provide dated observations and a defined next design, but they do not establish sustained effectiveness across an audit period or a complete population of checks. [S2; S4; S5; S6] To make the evidence usable over time, Thinking Cap should assemble the following for each control being supported. This is a proposed evidence approach, not a claim that every field or export already exists: | Evidence group | What to retain or verify | What it helps demonstrate | | --- | --- | --- | | Doctrine and approval | Rule ID, prophet, immutable version, scope, source, effective status and recorded human ruling | The approved requirement and responsible creator in force at the time | | Authority and admission | Authenticated console actor, permission history, conflict screens at filing and approval, block records and prayer-linked overrides | Authorized adoption and accountable cross-Book conflict handling | | Enforcement coverage | Harness and tool integrations, configuration history, covered action types and known gaps | Where and when the control actually operated | | Judgment population | Dated checks with agent and operator, intended action, governing rule version and prophet, verdict and enforcement mode | Repeated operation and a population available for sampling | | Stops and completeness | DENY matches across the hook, island and Bakery; local outage records, replay reconciliation and linked aftermath | Recorded enforcement independent of whether a prayer followed | | Action outcome | Links to approval records, commits, deployments or other resulting artifacts | Whether execution followed the verdict and required conditions | | Prayers and exceptions | Petition, attempts, Angel relationship, human ruling, bounded scope and resolution | Accountable relief and exception handling | | Monitoring and follow-up | Warnings, Judge failures, reviews, remediation and closure records | How degraded operation and deviations were addressed | ```mermaid flowchart TB subgraph Basis["CONTROL BASIS"] A["Approved requirement
Creator and authorized ruler"] --> V["Rule version and effective dates"] V --> C["Coverage and enforcement configuration"] end subgraph Period["REPEATED OPERATION ACROSS THE AGREED PERIOD"] E1["Dated check
Agent · operator · law · prophet"] E2["Dated check
Intent · verdict · enforcement mode"] EN["Further checks
Include warnings and failures"] E1 --> E2 --> EN end C --> E1 C --> E2 C --> EN E1 --> P[("Evidence population")] E2 --> P EN --> P H["Human approvals
Prayers and dispensations"] --> P S["DENY stops and aftermath
Including cases with no prayer"] --> P L["Local outage ledger
Replay and reconciliation"] --> S B["Doctrine conflict blocks
Recorded override authority"] --> P O["Action outcomes
Drop · build · deployment receipts"] --> P M["Review and remediation
Follow-up · closure"] --> P P --> R["Reconcile completeness
Identify gaps and bypasses"] R --> T["Auditor samples and corroborates
against the documented control"] classDef basis fill:#eef2ff,stroke:#6366f1,color:#1e1b4b; classDef operation fill:#ecfdf5,stroke:#059669,color:#064e3b; classDef evidence fill:#fffbeb,stroke:#d97706,color:#78350f; class A,V,C basis; class E1,E2,EN operation; class P,H,S,L,B,O,M,R,T evidence; ``` *This is a proposed audit evidence model. Repetition represents a population collected over the period, not a claim that the supplied excerpts already contain it. Individual approvals and outcomes must be linked to the corresponding actions and checks.* Keep the population across the agreed period, rather than selecting only successful demonstrations. Verify completeness by reconciling checks with the relevant action records, identify missing or bypassed paths, and preserve configuration changes that affect interpretation. A ledger of verdicts alone cannot prove that all relevant actions were checked or that denied actions stayed blocked. ## The operating limits belong in the control description The sources distinguish authority, operating behavior and rollout state. Those distinctions materially affect what the Book can claim. **Failure posture has a dated history.** The September white paper describes fail-open behavior on a Judge crash. The October 4 specification reports that an unreachable island causes the hook to fail closed and ledger locally, with central replay to be added. These are different failure cases and sources from different dates. Do not carry the old fail-open statement forward as the blanket current posture, or infer from island-unreachable behavior that every evaluator failure now closes the gate. Verify each failure path, its effective dates, and the reconciliation of outage records. [S1, section 3; S6, section 6] **WARN is a transition mechanism.** The white paper permits log-and-allow operation while the estate is reconciled with a law, followed by a ratchet to `DENY`. The handoff specifically lists `DOUG-0014` reconciliation as unfinished and identifies the warning ledger as the evidence trail. A warning demonstrates detection; it does not demonstrate prevention. The mode and its effective dates must travel with the evidence. [S1, section 6; S2, “The build map”] **Registry size is not active-control coverage.** The September 19 snapshot contains **607 entries: 23 active, 583 proposed, and 1 rejected**. The corpus ingestion created 566 proposed entries and flagged 13 contradictions. The handoff also says `DOUG-0018` remained proposed even though the Judge already enforced it. That historical mismatch should be reconciled with the human-approval principle before using approval status as proof of control authorization. The current paste does not establish its resolution or provide current totals for proposed and rejected entries. [S2; S4] The supplied view's 37 active labels provide evidence about those entries, while the September totals remain historical. The many-prophets specification separately says that all **560 existing entries** belong to Doug. These numbers describe different supplied snapshots or views; no registry reconciliation was supplied. Do not present any of them as a verified full current count. They show why an audit export needs doctrine state, prophet ownership and actual enforcement configuration. [S2; S4; S6, section 1] **Active doctrine and executable teeth are different.** S6 says active laws from all Books preach through the saith map, while new blocking rules remain deployed code in the Judge. The audit narrative must identify which laws are enforceable through those teeth, which are guidance, and what coverage each checkpoint provides. The conflict wall also has an explicitly LLM-assisted admission screen; deterministic runtime judgment does not make that screen deterministic. [S6] Where laws overlap—such as operator-only deployment rules, the Bakery route and repository grants—the evidence should show precisely which gate a dispensation opens and which restrictions remain binding. A doctrine-conflict override, an action-specific dispensation and a 12-hour repository grant serve different purposes; one should not silently become permission for another. ## The rollout needs its own evidence The many-prophets file is a locked design specification with a staged roll plan. It calls for the data migration, console identity and email injection, island permissions and conflict wall, creator routing, Stops endpoint and page, hook replay, and updated agent tool descriptions. It does not supply deployment receipts for that work. The older live components and October prayer receipts should not be used as proof that every new feature is deployed. [S6, section 9] Its end-to-end drill supplies a concrete acceptance path: found a second Book; block a near-duplicate and an opposing law; obtain Doug's dispensation and complete creator approval; route a prayer to the creator and rule through the email link; exercise Doug's cross-Book smite; and verify a forced DENY in Stops under the correct prophet. Preserve the results, rather than treating the planned drill as already passed. [S6] For the audit, also verify server-side rejection of unauthorized cross-Book approval and edit requests, conflict rechecking under concurrent approvals, outage-ledger replay, and linkage of Stops to their underlying checks. These additional tests follow from the stated control boundaries. Record when each deployed boundary began operating so evidence is assessed against the correct version of the system. ## Bringing the Book into Thinking Cap's audit work The next step is to connect the Book's records to Thinking Cap's documented controls. For each relevant control, identify its control owner, law creator, authorized rulers, governing law versions, execution coverage, enforcement modes, evidence population, and handling of failures or exceptions. A prophet is the owner of doctrine; that does not automatically make them the owner of every organizational control the doctrine supports. Agree the mapping and evidence approach with the audit team. The deployment and Bakery gates are concrete candidates for supporting change-control evidence. Judgment and Stops records can support monitoring evidence. Versioned doctrine, creator permissions and conflict rulings can support governance and approval evidence. Prayers, attempts and dispensations can support exception review. These are proposed uses based on the supplied mechanisms, rather than a completed mapping to the Trust Services Criteria. The Book's strongest contribution is a traceable account of rules in operation: whose law governed an action, which version applied, what the Judge stopped or allowed, where a human intervened, and what happened afterward. With many prophets, rule ownership broadens. With Stops, enforcement evidence extends beyond the subset of cases that become prayers. Collected, reconciled and reviewed across the audit period, those records can help Thinking Cap substantiate the controls it actually operates. ## Source notes - **S1 — `the-book-of-doug.md`:** *The Book of Doug*, white paper, September 2026. Defines doctrine, human approval, immutable versions, deterministic judgment, fail-open behavior, prayers, Angels, rulings, logging, staged enforcement, and the first end-to-end case study. - **S2 — `the-book-of-doug-where-we-are.md`:** *The Book of Doug — Where We Are*, handoff dated September 19, 2026. Reports live components, registry counts, production receipts, pause drills, fixes and open work. Counts and implementation status in this document are attributed to that snapshot. - **S3 — `book-of-doug-the-sermon-layer.md`:** *Book of Doug: The Sermon Layer*, undated design document. Separates contextual guidance from deterministic enforcement and proposes retrieval feedback from judgments. - **S4 — Current Book paste supplied October 4, 2026:** Begins “Humans approve; machines propose” and ends with `DOUG-0741`. Contains 37 active-labelled entries, provenance, ruling dates and versions. The opening human-approval entry omits its ID in the paste; its relationship to `DOUG-0001` is established by S1. Treated as the current view Doug supplied, not a complete independently verified registry export. - **S5 — Prayer logs paste supplied October 4, 2026:** Begins “Prayers — petitions for relief from a law” and contains `PRAYER-0066`, `PRAYER-0065` and `PRAYER-0064`. Establishes the displayed requests, sponsorship, resolutions and Angel associations. Does not include the complete `agent_checks` ledger, grant-use records or execution receipts; the `PRAYER-0064` requested-action field is visibly incomplete. - **S6 — `book-of-many-prophets-spec-2026-10-04.md`:** *The Book of Many Prophets — spec*, October 4, 2026. Defines per-user Books, creator rulings, Doug's cross-Book powers, conflict screens and overrides, creator-routed Audiences, Stops, outage-ledger replay, page and proxy changes, agent surfaces and the roll plan. Statements explicitly reported as already happening are attributed to the specification; planned migrations, endpoints, replay and drills are not treated as verified deployments. - **C1 — Accompanying conversation:** Doug's statement in *Improve SOC 2 Message* that anyone on the team can now add their own laws. Used as a reported contribution update, without inferring self-approval or verified permissions. - **C2 — Follow-up conversation:** Doug's examples of Isobel caring about UX and Liam about compliance, and his intention to log caught rule-breaking attempts as well as prayers. S6 supplies the detailed authority and DENY-based Stops model; the examples do not establish deployed Books for either person. - **External context:** [AICPA's Journal of Accountancy explanation of SOC reporting](https://www.journalofaccountancy.com/issues/2011/jul/20103500/) supports the Type II distinction between control design and operation over a period. The [AICPA SOC 2 reporting guide overview](https://www.aicpa-cima.com/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy-OPL) describes the examination's focus on the system and relevant controls. Book-specific claims come from S1–S6 and C1–C2.