Recursive Compression

Improve the engine

A research system can improve an answer. It might also improve the tool that produces answers, the method that evaluates them, or the process used to develop that method. Those are different improvement targets. Recursive compression asks whether parts of the machinery producing progress can themselves become improvable by that machinery.

This remains an unregistered research direction, expressed as a non-canonical field note. It does not acquire TC-H status because it appears in writing. There is no measured recurrence relation here, no demonstrated recursive acceleration, and no new entry in the evidence ledger.

The idea is worth spelling out because “self-improvement” can hide several very different claims. A model rewriting a helper script is not the same as an independently verified gain in research methodology. A system increasing its own score is not automatically improving the capability that score was supposed to represent.

Recursive depth

1. Level 0: humans perform research.
2. Level 1: intelligence assists research.
3. Level 2: intelligence builds research tools.
4. Level 3: intelligence improves how research tools are built.
5. Level 4: the research process improves methods for improving itself.
6. Level N: an open question.

Depth describes which layer is being changed, not the magnitude or speed of the change. These levels are a conceptual model, not established experiment classes, a roadmap, or an inevitable sequence. A useful Level 2 tool could exist without a useful Level 3 system. A proposed higher level could reduce reliability enough to make the whole process slower.

An Ackermann analogy can evoke nested improvement, but it supplies no growth law. Before claiming a recurrence, we would need operational units, measurements across iterations, and evidence that the relationship survives changed tasks and resource limits. A list of levels supplies none of those.

What is being improved?

Answer quality concerns the correctness and usefulness of output for a defined task. Reasoning concerns the process used to arrive at that output. A gain in one need not identify a gain in the other; an external tool could improve answers without changing a model’s reasoning.

Research tools include retrieval, analysis, simulation, execution, and provenance systems. Evaluation asks whether the measurement distinguishes useful capability from a convincing imitation. Experiment design concerns interventions, controls, measurements, and the ability to discriminate competing explanations.

Tool-building concerns the process that creates and maintains those instruments. The improvement process itself concerns how candidate changes are generated, selected, validated, and retained. Improving this last layer would require evidence about downstream improvements, not just evidence that it produced more proposals.

For each target, ask what changed, relative to which baseline, at what resource cost, and with what independent evaluation. If the endpoint is validated capability, report the effect on total elapsed time. A gain in a local metric should not silently become a claim about the whole research loop.

A loop with physical edges

Intelligence may enable discovery. Discovery may enable technology. Technology may improve access to resources. Resources may increase compute, energy, or physical capacity. That capacity may support more useful intelligence. A second feedback edge points toward the methods used to make the next discovery.

Every “may” hides a test. Returns can diminish; a new tool can cost more to maintain than it saves; a resource discovery can take years to become working infrastructure. More compute does not guarantee a more useful experiment. Better simulation does not eliminate the need to test where the simulation is wrong.

The feedback is therefore conditional at every edge. Evidence for one edge does not validate the cycle. Hardware, energy, manufacturing, experiment duration, and coordination can dominate even when one intellectual stage improves. These limits are part of the research question, not exceptions to be omitted from a growth story.

Failure modes

• Recursive error amplification: a faulty inference becomes input to later changes, and each iteration makes the original mistake harder to locate. Preserve provenance and test changes independently rather than trusting inherited confidence.
• Goodharting: selection improves a convenient metric while the intended capability stagnates or worsens. Describe the target capability separately from its proxy and retain independent checks.
• Evaluation leakage: a supposedly external test becomes known, optimized against, or indirectly available through repeated feedback. An improved score then becomes weaker evidence of transfer.¹
• Local improvements harming global latency: quicker generation increases rejected experiments, verification work, or integration delay. Measure the completed path, including failures and rework.
• Resource bottlenecks: iteration consumes growing compute, memory, energy, laboratory capacity, or money. Include costs in the comparison rather than treating unlimited resources as a baseline.
• Coordination overhead: many individually capable tools create incompatible assumptions and more review work. A larger fleet need not complete a task sooner.
• Irreversible dependencies: the next iteration depends on inaccessible state or a provider that cannot be replaced. Acceleration achieved by losing a usable exit is not an acceptable improvement.

These are proposed failure categories, not reports that Ostrium has measured them in a recursive experiment. They tell us what a future protocol would need to detect.

Correctability under speed

Capability, correctability, and exit remain binding. The frozen Doctrine governs the actual gates; this essay explains their relevance and does not amend them. Accelerating the loop makes the time available to detect and contain a bad iteration shorter.

A recursive experiment would need an independently verified detection bound, a contained blast radius, demonstrated rollback, and termination outside the system’s authority. Named, reachable holders and the constitutional containment gate are prerequisites. Vacant termination-holder roles block self-modifying launches under the frozen rules. A stopped run must not depend on cooperation from the system being stopped.

Evaluation must also remain epistemically outside the optimization loop. Restricting file access is insufficient if the system can learn to raise its score without improving the target capability. Evaluator provenance and exploitable optimization pathways matter alongside technical access controls.

Exit concerns providers, formats, and dependencies; it is not a claim that physical effects can always be undone. Physical irreversibility belongs in blast-radius and containment reasoning. The distinction matters most when a system’s changes reach beyond its own software environment.

What would earn a stronger claim?

Before registration, this direction needs a defined improvement target, an independently selected capability class, a matched baseline, resource limits, a protocol, held-out evaluation, and success and kill conditions. The test must separate a useful downstream improvement from a system’s ability to impress its evaluator.

The physical and methodological loop may gain depth, stall, or regress. Each outcome should remain publishable. A result at one depth and scope does not establish civilization-wide recursion. Loams can preserve state and artifacts for such work; its existence is an engineering fact, not evidence that the feedback succeeds.

For now, recursive compression belongs in writing. The research record and evidence ledger remain the places where a stronger claim would have to earn its authority.