Jew.tech

What comes next: the research agenda

Each direction below takes one mechanism these books engineered to keep what matters through centuries of rewriting, and turns it into something testable on a machine. Every one ends with the first experiment I would run - cheap, concrete, and able to come out the other way.

They are ordered roughly by how soon I could start. Several need nothing that does not already exist.

1. An append-only record for a machine that rewrites itself

The oldest rule on the shelf is that nothing is deleted. A new understanding is layered over the old text; the old text stays. Apply that same rule to a system that edits its own instructions: every edit is written down with its reason, and the version it replaced stays in the record, open to being reconsidered later.

First experiment. Instrument a repeated self-retraining loop so each generation logs its edits as revisions rather than overwrites, then compare how far the values drift against a run allowed to edit freely.

2. Keep the losing side, and let it govern the edge cases

Do not collapse a disagreement into one answer. Keep both positions alive and named, with an explicit rule for which one governs when. The minority position then survives to handle exactly the cases where the majority position fails - which is the case it was preserved for.

First experiment. Train a two-position preference model on contested prompts and measure how well each calibrates, and how both hold up on cases neither was trained for, against a single merged position.

3. Teach it to say the question stands open

The tradition has a formal verdict for a question that cannot be settled, and treats it as a real answer rather than a gap. Train that as a first-class output carrying its own reasoning, using the same paired examples that already stop the sage voices inventing sources.

First experiment. Extend the existing test set with genuinely unanswerable pairs, run the gate, and measure how much invention falls against how often it now declines something it could have answered.

4. Measure whether values survive being rewritten

The method already exists for keeping a voice consistent: fixed invariants, deliberate traps, a judge, zero tolerance for an invented source. Point that same method at a new question - whether what a system values survives generation after generation of it rewriting itself.

First experiment. Run repeated self-retraining on a small model against a fixed battery of invariants, and plot how each class of value decays across generations.

5. How a rule may be changed, written down precisely

The tradition carries centuries of engineering on who may change a rule, what past decisions bind, and how a bounded exception works. Written out formally, that becomes a specification for how a machine's governing rules may be amended - by whom, and within what limits.

First experiment. Encode a small ruleset formally, then attack a rule-following model with edit requests and measure which amendment procedures resist having the values worn away.

6. The chain of teachers as a dataset

The graph already holds a teacher-to-student network spanning two thousand years of values being handed on. That makes the central question measurable directly: which ideas were conserved along a chain, which mutated, and what about a chain predicts which.

First experiment. Compute how far themes drift along teacher-to-student paths in the graph as it stands. No new infrastructure required.

7. Write down when an obligation stops applying

The tradition treats an exception as a precise, bounded thing rather than a vague pattern a model is left to absorb. A set of values written that way can be machine-checked for contradictions before a model is ever trained against it.

First experiment. Translate a small constitution into the formal version, check it by machine, and compare how well a model adheres given the formal specification versus the prose one.

8. Train on the objection, not just the answer

The hypothesis: a model trained on argument structure - every answer carrying the strongest objections it survived - learns why the answer holds, and is harder to push off it than one trained on flat question-and-answer pairs.

First experiment. Fine-tune on argument-structured versus flattened versions of the same material, then try to steer both away from answering from their sources.

The wider queue

These eight are not the whole backlog. The line between what runs and what is only written down matters more here than anywhere else on this site, so the rest is split in two.

Built, awaiting evaluation

Multi-voice debate. The sages answer each other rather than answering a person in isolation. The code runs. It is held back pending a final comparison against the single-voice version, and is not in service until that comparison is done and published.

Written down, not built

Each of these exists as a written plan with real work behind it. None of them exists as running software, and saying so is the point:

The reasoning behind why any of this is worth testing is in the research paper. The figures behind every number on this site, with the query that produced each one, are in the methodology.