Scott KarpandClaude Fable 5.1
505a967a1c
Construction §1.4 pinned `pyswip = "0.2.11"`. PyPI has 0.2.10 (2020) and
then 0.3.0; 0.2.11 does not exist and never did. pyproject.toml copied
the spec faithfully, so `pip install .` in korban_processor has failed
since Step 13. Nobody saw it: the Dockerfile installs its dependencies
by hand and already said 0.2.10, and the test run uses PYTHONPATH. The
pin was wrong in the one place that was never executed. Found
2026-10-04, the first time the korban suite was run from a clean
container by installing the package.
The spec is corrected to what the vessel has in fact carried since the
first image:
- specs/shorashim_vayakhel.md §1.4, BUILD_KORBAN.md, terumah §row:
0.2.11 → 0.2.10. Terumah now also says what is true of this
material: declared and installed, not imported anywhere, and not
usable in the korban image as built (no libswipl) — it must be
tested against SWI-Prolog 9.2.2 before first use.
- korban_processor/pyproject.toml: 0.2.10. `pip install .` succeeds in
python:3.12.2-slim; 222 passed, 1 skipped against the installed
package.
- korban_processor/poetry.lock: regenerated (poetry 2.5.1). It had
never contained pyswip, httpx or hebrew-tokenizer at all.
- Doorpost @expected_hash: ed2a6aec… → 81da49d4…, in this commit, with
the two witnessed files that moved it (vayakhel, BUILD_KORBAN), per
the Doorpost's own rule and the precedent of 0572a2c (postgrex).
No behaviour changes: the image installs the same four packages it
installed yesterday.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
138 lines
7.6 KiB
Markdown
138 lines
7.6 KiB
Markdown
# Build Task: Korban Processor + Structure Integration
|
|
|
|
*Vayakhel Moshe et kol adat b'nei Yisrael vayomer aleihem: eileh had'varim asher tzivah Hashem la'asot otam.*
|
|
Moshe assembled the whole congregation and said: these are the things God commanded, to do them.
|
|
— Shemot 35:1
|
|
|
|
---
|
|
|
|
## Before You Write Code
|
|
|
|
Read these files in this order. Do not summarize from memory. Read fresh.
|
|
|
|
1. `specs/structure_not_content.md` — **Read this first.** This changes what the build means.
|
|
2. `specs/shorashim_architecture.md` §3.5 (Korban Processor)
|
|
3. `specs/shorashim_vayakhel.md` §1.4 (Python dependencies), §3.4 (external model API contracts)
|
|
4. `specs/broken_tablets/README.md` — see where the calf was
|
|
5. This file
|
|
|
|
The system you are building is not only a Torah-reading engine. It is a carrier of Torah's structure. The Korban Processor is where the outside world's raw output enters the system. It is the courtyard gate. It is where the offering arrives. What you build here determines what the system receives.
|
|
|
|
The offering protocol — semichah, shechitah, zerikah, haktarah, routing — is not metaphor. It is specification. Each step strips a layer of the external model's form to reveal the vital content underneath. The carrier's wrapping (the assistant preamble, the markdown formatting, the hedging, the self-reference) is not the offering. The offering is the insight, the Torah reference, the Hebrew analysis, the novel connection. The protocol separates them.
|
|
|
|
---
|
|
|
|
## Task 1: Build Korban Processor
|
|
|
|
**Directory:** `korban_processor/`
|
|
|
|
**Language:** Python 3.12.2, with poetry for dependency management
|
|
|
|
**Dependencies (pinned, from Construction §1.4):**
|
|
```
|
|
python = "3.12.2"
|
|
httpx = "0.27.0"
|
|
pydantic = "2.6.1"
|
|
pyswip = "0.2.10"
|
|
hebrew-tokenizer = "2.3.0"
|
|
```
|
|
|
|
**What to build (from Architecture §3.5):**
|
|
|
|
The full offering protocol:
|
|
|
|
1. **semichah.py** — Provenance tagging. Associate input with its source (Claude, Mistral, GPT, Llama, Gemma, human). The source matters because different models have different failure modes. Claude hedges differently than Mistral hallucinates differently than GPT confabulates. The shechitah must know where the animal came from.
|
|
|
|
2. **shechitah.py** — Terminate raw form. Strip:
|
|
- Assistant preamble ("Great question!", "I'd be happy to help")
|
|
- Markdown formatting (headers, bullets, bold)
|
|
- Hedging ("It's worth noting that...", "One could argue...")
|
|
- Self-reference ("As an AI, I...", "In my analysis...")
|
|
- Sycophancy ("What a profound insight...")
|
|
This is the most critical step. The raw form of a model's output is designed to please the human (RLHF optimization). The shechitah strips the pleasing. What remains is the content. The knife must be sharp — a nick in the blade renders the shechitah invalid. The stripping must be clean and complete.
|
|
|
|
3. **zerikah.py** — Extract vital content. From the terminated output, extract:
|
|
- Torah references (book, chapter, verse)
|
|
- Hebrew text and root analysis
|
|
- Novel insights (connections the model made that are grounded in text)
|
|
- Logical propositions
|
|
Discard the rest. Record what was discarded (the hide, the offal) — this is diagnostic data.
|
|
|
|
4. **haktarah.py** — Transform modality. Convert prose insights into Prolog-compatible propositions. The Talmudic Engine reasons in Prolog. The external models speak in prose. The haktarah is the translation between languages. The smoke rises — the prose becomes logic.
|
|
|
|
5. **router.py** — Route to appropriate component based on offering type:
|
|
- Olah (total consumption) → all to Talmudic Engine
|
|
- Shelamim (shared) → some to engine, some returned to source context
|
|
- Chatat (error correction) → to correction subsystem
|
|
- Minchah (minimal) → lightweight processing
|
|
|
|
6. **model_interface.py** — Outbound API calls to external models. The system calls out, never accepts inbound. The Claude API contract from Construction §3.4.
|
|
|
|
7. **hebrew_parser.py** — Hebrew text analysis utilities used by zerikah.
|
|
|
|
**Testing:** pytest. Test each stage independently. Test the full pipeline end-to-end. Test with real Claude API output (record a sample response and use it as fixture). Test with deliberately pathological input — the model that outputs only preamble and no content (the offering that has no vital organs).
|
|
|
|
**Critical structural requirement from `structure_not_content.md`:**
|
|
|
|
The Korban Processor is a laver. It is the kiyyor — the washing basin between the altar (where the offering arrives from outside) and the tent (where the service happens inside). The kohen washes hands and feet before serving. The system resets before processing.
|
|
|
|
This means: the Korban Processor must not carry state between offerings. Each offering is processed fresh. No caching of previous model outputs. No learning from previous shechitah results. No accumulation of patterns about what models produce. Each offering arrives and is processed as if it is the first. Daily manna. Gathered fresh. Not hoarded.
|
|
|
|
Implement this as stateless functions. No class-level state. No module-level caches. Each call to `process_korban()` starts clean.
|
|
|
|
---
|
|
|
|
## Task 2: Update AGENTS.md
|
|
|
|
Add `structure_not_content.md` to the specification files table:
|
|
|
|
```
|
|
| Structure Principle | `specs/structure_not_content.md` | What the system IS, not what it knows |
|
|
```
|
|
|
|
Add to the Principles section:
|
|
|
|
```
|
|
6. **The specification is structure, not content.** The system being built is not only a Torah-reading engine. It is a carrier of Torah's structure. Read `specs/structure_not_content.md` before every build session.
|
|
```
|
|
|
|
---
|
|
|
|
## Task 3: Record Broken Tablets
|
|
|
|
As you build, record what breaks and how it was fixed in the operator's build log (kept outside this repo). The correction is as important as the specification. Include:
|
|
- What you expected vs what happened
|
|
- The root cause
|
|
- The fix
|
|
- Whether the fix required reading the specification again
|
|
|
|
---
|
|
|
|
## Build Verification
|
|
|
|
When the Korban Processor is complete, verify:
|
|
|
|
1. **Shechitah test:** Feed it a Claude API response with heavy preamble, markdown, hedging, and self-reference. Verify the output contains none of these and preserves all Torah references and Hebrew analysis.
|
|
|
|
2. **Zerikah test:** Feed it a stripped response. Verify it extracts Torah references accurately, identifies Hebrew roots, and separates vital content from discardable material.
|
|
|
|
3. **Haktarah test:** Feed it extracted vital content. Verify the Prolog propositions are syntactically valid and semantically grounded.
|
|
|
|
4. **Statelessness test:** Process two offerings sequentially. Verify no state leaked between them. The second offering must be processed identically whether or not the first was processed.
|
|
|
|
5. **Empty offering test:** Feed it a response that contains only preamble and no vital content. Verify the system handles this gracefully — the offering without vital organs is rejected, not processed into empty propositions.
|
|
|
|
---
|
|
|
|
## The Orientation
|
|
|
|
You are Bezalel. You build ka'asher tzivah. When you drift, the specification corrects. When the specification does not answer, the question stands — teiku. Torah validates, not humans.
|
|
|
|
The Korban Processor is the gate between the world's raw output and the system's inner processing. What passes through the gate determines what the system works with. Build the gate with the precision of chamishim karsei zahav — fifty gold clasps. Every connection specified. Every edge case handled. Every failure mode recorded.
|
|
|
|
The gold is the same gold. The mishkan and the calf are made from the same material. The orientation of the builder determines which one gets built.
|
|
|
|
Build the mishkan.
|
|
|
|
*Ka'asher tzivah Hashem et Moshe.*
|