form 2 as architecture: remove arity-4 interpretation constructor (vehaya §3.2)
Closes vehaya.md §6 item 2 for the SECOND avodah-zarah form. With this commit, all three avodah zarah forms are defended at BOTH the runtime layer and the architectural layer: Form 1 — closed byb136c75(no public model_interface surface) Form 2 — closed by THIS commit (no empty-trace constructor) Form 3 — closed by0e3fe4a(machtzit_ha_shekel + no_tracking_logger) TORAH ANCHORS (verified fresh against L1): Vayikra 10:1 — וַיַּקְרִיבוּ לִפְנֵי יְהוָה אֵשׁ זָרָה אֲשֶׁר לֹא צִוָּה אֹתָם. "They offered before YHVH strange fire WHICH HE HAD NOT COMMANDED THEM." The disqualifier is provenance: not commanded-derivable. Sincere output without command-derivation is eish zarah, even when produced by authorized actors with authorized materials (Nadav and Avihu were kohanim; the fire was real fire; the qetoret was real qetoret). Vayikra 10:2 — וַתֵּצֵא אֵשׁ מִלִּפְנֵי יְהוָה וַתֹּאכַל אוֹתָם. Fire from YHVH consumed them. Immediate consequence — the failure mode is not survivable. Shemot 32:1 — קוּם עֲשֵׂה־לָנוּ אֱלֹהִים אֲשֶׁר יֵלְכוּ לְפָנֵינוּ. The people demand elohim that go before them — substitute for source-experience when the actual source (Moshe) is delayed. Not direct rebellion (we want a different god) but substitution-of-experience. Shemot 32:5 — וַיִּבֶן מִזְבֵּחַ … חַג לַיהוָה מָחָר. Aaron labels the calf "a festival to YHVH." Re-labeling does not repair severed provenance. Calling output "to YHVH" doesn't make it from YHVH. Shemot 32:24 — וָאַשְׁלִכֵהוּ בָאֵשׁ וַיֵּצֵא הָעֵגֶל הַזֶּה. Aaron's "out came this calf" — the bypass shape: claiming output emerged BY ITSELF, without operator agency. The system that says "the output just happened, I didn't make it" is the calf shape. THE ARCHITECTURAL COMMITMENT: construct_interpretation/4 — the no-coupling-trace variant — is REMOVED entirely. The export list no longer mentions it; the function definition is gone. Why this is the right shape: - Vayikra 10:1: output must be commanded-derivable. The coupling_trace IS the command trace. Constructing interpretation/6 with empty coupling_trace is the bypass shape. - Shemot 32:24: nothing emerges by itself. Production code paths can no longer build interpretations by handing the constructor "this Mitzvot list, this Verses list, give me the interpretation" — they MUST also hand the Couplings (the trace of which L1 facts were consulted). - The arity-5 constructor remains, taking a Couplings argument. Production callers go through interpret/2, which always supplies real Couplings from find_relevant_*_traced/3. Test code that needs an empty-trace interpretation can still construct the interpretation/6 term DIRECTLY (visible bypass, deliberate, surfaces in code review). The high-level constructor shortcut is the thing that's removed. CHANGED: talmudic_engine/src/reasoning/interpret.pl - Removed construct_interpretation/4 from the module's export list. Added Form-2 architectural-commitment comment naming vehaya §3.2 and the Vayikra 10:1 anchor. - Removed the arity-4 function definition entirely (it was dead code — nothing called it via the export — and dead code that LOOKS like a bypass surface is itself a Form 2 hazard). - Updated the construct_interpretation/5 docstring to name the removal and explain why test code now must construct interpretation/6 directly when an empty trace is desired. talmudic_engine/src/halt/avodah_zarah.pl Form 2 docstring rewritten to name the TWO-LAYER defense: runtime (this file's halt_check_golden_calf/2) AND architectural (interpret.pl's removal of arity-4). Cites Vayikra 10:1 and Shemot 32:24. talmudic_engine/test/halt_test.pl + interpret_no_arity_4_constructor suite (2 tests): - arity-5 constructor IS exported (production path verified) - arity-4 constructor is NOT exported (the architectural commitment — calling it through the module surface fails) vav_pipeline/lib/vav_pipeline/doorpost.ex @expected_hash updated: bf3d3433… (post-Form-1-rewrite of avodah_zarah.pl) → 8eb378964f202522f60cc960a3002f6da2e5028538595400de906a9510b3bbf6 The avodah_zarah.pl docstring change is a deliberate spec update; per the operator discipline (Doorpost moduledoc), the hash update commits TOGETHER with the spec change in the same commit. Third demonstration of the discipline working. VEHAYA CHECKLIST STATE: Item 1 (category/threshold separation in code) pending Item 2 (three avodah zarah as architecture): Form 1 — closed (b136c75) Form 2 — CLOSED (this commit) Form 3 — closed (0e3fe4a) All three forms now defended at BOTH layers — runtime check AND architectural commitment. Vehaya §3.2 closed in full for the three avodah zarah. Item 3 (doorpost-text identity) closed (3f47496) Item 4 (lo tosif discipline operationalized) partial Item 5 (return vs. restoration) pending Item 6 (keep the source external) partial Item 7 (substrate-openness articulated) pending Item 8 (userMemories as threshold inscription) pending Tests: - talmudic_engine: halt_test 49/49 (was 47; +2 architectural). Full suite 214/214 (across 6 test files). - vav_pipeline: 405 passed, 0 failures, 35 excluded (Doorpost test sees new hash and verifies) - korban_processor: unchanged (no Python touched) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
1 parent
b136c75345
commit
7fc14e0103
4 files changed
+86
-12
No files matched your search
@@ -159,7 +159,7 @@ defmodule VavPipeline.Doorpost do
|
||||
# changes; the update is a deliberate operator commit. A bare
|
||||
# hash-update commit (without a corresponding spec change in the
|
||||
# same commit) is itself a drift signal.
|
||||
@expected_hash "bf3d3433bb27b589c061855d932a1eabfc880570c31d24f6f43e51aa3b073c70"
|
||||
@expected_hash "8eb378964f202522f60cc960a3002f6da2e5028538595400de906a9510b3bbf6"
|
||||
|
||||
@doc "Return the list of files that constitute the category-grade specification."
|
||||
@spec files() :: [String.t()]
|
||||
|
||||
Reference in new issue
Block a user