Pre-Forge: Reference Sheet Generator#

Created: 2026m03d26

Purpose: Run this prompt in a SEPARATE session before starting a Model Forge session. It produces concise reference sheets (~5K tokens each) for formal tools that the forge agent needs. The sheets are saved as files in source/matheology/compiler/forge/wb/ and loaded by the forge prompt automatically.

Why separate: Producing good reference sheets requires reading textbook-level material and distilling it. This is a different task from adversarial model testing. Mixing them wastes forge working space on reference generation and risks biasing the forge agent with the reference author’s framing.

When to run: Once, before your first forge session. Re-run only if you need additional reference areas or want to update existing sheets.

What the User Needs to Do#

Open a fresh Opus session (200K is sufficient).
Paste the prompt below.
The agent will produce 4 reference sheets as files.
Review each sheet for accuracy (you said you’re roughly familiar with all 4 areas — use that familiarity to catch errors).
The sheets are then available for any future forge session.

The Prompt#

/effort max

You are producing REFERENCE SHEETS for a formal logic auditing
system called the Model Forge. These sheets will be loaded into a
separate context window where an auditor develops and stress-tests
new axiomatic models in mathematical theology (matheology).

The auditor already knows: S5 modal logic, classical extensional
mereology (CEM), first-order predicate calculus, basic game theory,
and standard propositional/predicate logic. These do NOT need
reference sheets.

The auditor needs compact, precise reference sheets for 4 areas
that are relevant to model development but may not be fully loaded
in the forge context. Each sheet must be:

- CONCISE: target 4000-5000 tokens (roughly 3-4 pages)
- SELF-CONTAINED: no external references needed to use it
- APPLIED: not a textbook summary but a "what you need to know
  to USE this in matheology model development" guide
- HONEST about limitations: what the tool CAN'T do matters as
  much as what it can

For each sheet, structure as follows:

1. ONE-PARAGRAPH ORIENTATION
   What is this? Why does it matter for formal model development?
   What problem does it solve that the auditor's existing toolkit
   (S5, CEM, FOL, game theory) cannot?

2. KEY CONCEPTS (5-8 items)
   Each concept: name, informal definition, formal notation (if
   standard), and a one-sentence example of how it applies to
   reasoning about axiomatic systems, models, or cross-model
   relationships.

3. CRITICAL THEOREMS (3-5)
   The theorems the auditor is most likely to need. For each:
   informal statement, formal statement (brief), and WHY it
   matters for model development. Do NOT include proofs ---
   the auditor needs to APPLY these, not re-derive them.

4. COMMON PITFALLS (3-5)
   Mistakes people make when first applying this framework.
   Especially: mistakes that look correct to someone who knows
   modal logic but not this specific theory.

5. BRIDGE TO MATHEOLOGY
   Concrete examples of where this framework connects to the
   existing matheology system (25 axioms, 11 theorems, 2 models,
   66 HELL findings). What new questions can it ask? What
   existing questions can it sharpen?

─────────────────────────────────────

Produce these 4 reference sheets, saving each as a separate file:

SHEET 1: Category Theory for Cross-Model Reasoning
File: source/matheology/compiler/forge/wb/category-theory.rst

Focus on: functors between models (PET and JUB as categories),
natural transformations (systematic correspondences between models),
limits and colimits (how to combine or restrict models), adjunctions
(when two operations are "optimally paired"). The existing system
has "alignment echoes" between models --- category theory may
formalize whether these are functorial (structural) or accidental.

SHEET 2: Homotopy Type Theory for Identity and Equivalence
File: source/matheology/compiler/forge/wb/homotopy-type-theory.rst

Focus on: the univalence axiom (equivalent structures are identical),
higher inductive types (defining structures by their construction
rules), path types (what it means for two things to be "the same"),
transport (moving proofs across equivalent contexts). The existing
system has versioned variants (VVN) and asks "when is version N
equivalent to version M?" --- HoTT may formalize this.

SHEET 3: Mechanism Design for Axiomatic Economics
File: source/matheology/compiler/forge/wb/mechanism-design.rst

Focus on: incentive compatibility (when is truth-telling optimal?),
the revelation principle (any mechanism can be converted to a
direct one), Vickrey-Clarke-Groves mechanisms (efficient allocation
with honest reporting), impossibility results (Myerson-Satterthwaite,
Gibbard-Satterthwaite). The existing system's JUB model describes
economic mechanisms (capitalism-communism analysis, Jubilee-System
cycles) --- mechanism design provides the formal toolkit to check
whether those mechanisms actually achieve their stated goals.

SHEET 4: Paraconsistent Logic for Graceful Contradiction Handling
File: source/matheology/compiler/forge/wb/paraconsistent-logic.rst

Focus on: what paraconsistency IS (not everything follows from a
contradiction), relevant logics (only "relevant" conclusions follow),
dialetheism (some contradictions may be true --- and when this is
useful vs. dangerous), LP (Logic of Paradox) as a minimal system.
The existing matheology system may encounter situations where two
models make contradictory claims about the same domain. Classical
logic says the entire system explodes. Paraconsistent logic says:
contain the blast, reason about the rest.

─────────────────────────────────────

AFTER producing all 4 sheets:

- List any additional areas you think would strengthen the forge
  toolkit (beyond these 4) with a 1-sentence justification each.
- Note any concerns about the 4 sheets: areas where you are less
  confident in your summary, or where the matheology connection
  is speculative rather than clear.

LANGUAGE RULES (non-negotiable):
- No bare "Jubilee" as standalone noun
- No "validate/verify/validation/verification"
- No "the" before unproven superlatives
- HELD/BREACH, not PASS/FAIL

When to Use Which Prompt#

Situation	Prompt	Notes
First time, no reference sheets exist	Pre-forge (this file), then forge 200K or 1M	Run pre-forge once; reuse sheets forever
Quick model sketch, familiar territory	Forge 200K v2 (without reference sheets)	104K working space; fast iteration
Quick model with unfamiliar formal tools	Forge 200K v2 (with reference sheets)	84K working space; more formal reach
Deep model work, full adversarial landscape needed	Forge 1M v2 (with or without reference sheets)	722K+ working space; the full arsenal
Reference sheets need updating or expanding	Pre-forge again (fresh session)	Review output against your domain knowledge