---
title: "A Self-Modifying Software Substrate With Acceptance Gates"
summary: "A bounded component of the Consullo public research program: A Self-Modifying Software Substrate With Acceptance Gates."
status: "specified but not implemented"
provenance: "derived from the owner-approved private Consullo design corpus; no artifact-specific public receipt has been issued"
claim_ids: ["CP-001"]
last_reviewed: "2026-08-12"
receipt: "none"
non_claims: ["Publication does not establish implementation or operational effectiveness.", "The implementation-evidence appendix records component evidence only and is not evidence of operational capability for this page."]
---
# A Self-Modifying Software Substrate With Acceptance Gates

## Specialized Abstract

Consullo Seed AI requires an executable substrate that can generate, edit, repair, test, validate, document, deploy, and monitor its own agents and supporting software. This thesis defines that substrate as a constrained software-engineering architecture rather than as unconstrained autonomous coding. The claim is not that Consullo can safely rewrite itself without oversight. The claim is that Consullo specifies a self-modifying software substrate whose modifications can be routed through deterministic build stages, LLM-Native Functional Java constraints, atomic prompt decomposition, automated repair, post-verification methods, provenance, staged deployment, and Thesis 1 and Thesis 5 acceptance gates. Capability Status: specified/proposed, with component implementation status to be established per repository.

The substrate is the practical bridge between recursive capability amplification and real system change. Without it, improvement remains advisory. With it, improvement can become code, tests, method memories, workflow automation, build artifacts, and deployment state. Its central risk is also direct: generated code can compile, pass tests, and still be semantically wrong, insecure, overfitted, unmaintainable, mis-scoped, or misaligned. The thesis therefore treats acceptance gates as part of the substrate, not as an afterthought.

## Specialized Introduction

Self-modifying software is often imagined as an agent editing its source code. Consullo's design is more structured. AgentBuilder designs frame agent construction as a multi-stage, resumable pipeline that turns an agent purpose into repository artifacts, specifications, generated code, tests, documentation, OpenClaw configuration, deployment artifacts, and creation telemetry. Current repository evidence is stronger for agent-generation and repair utilities than for a single implemented AgentBuilder class. Agent programming methodology further constrains generated code to a static-method, JSON-only, PDCA-signature style designed for LLM generation and verification. Atomic prompt decomposition and compiled-code orchestration define how LLM calls should be reserved for language-heavy work while deterministic algorithms handle structured work. Repair-agent designs define a richer automated repair pipeline.

The thesis here is that these designs should be understood as one software substrate for recursive self-improvement. It is not enough for Consullo to generate code. It must generate code in a form that is inspectable, testable, replayable, recoverable, provenance-linked, and permissioned.

## Master-Frame Contract

This thesis imports:

- improvement-loop acceptance semantics and method-memory learning from Thesis 1
- cognitive search, decomposition, critique, and synthesis capabilities from Thesis 2
- causal-decision logic from Thesis 3 for repair strategy selection and experiment design
- alignment gates, scoped trust, containment, security limits, and deployment permission from Thesis 5
- substrate context for LLM routing, rapid knowledge access, atomic prompt orchestration, token-cost accounting, and internal resource accounting

This thesis exports:

- agent and code generation mechanisms
- automated repair pipeline structure
- test, regression, semantic, formal, and statistical validation requirements
- provenance requirements for generated or modified artifacts
- LLM-Native Functional Java constraints
- static-method, JSON-only, PDCA method contracts
- post-verification method requirements
- secure build, signing, and runtime capability-gating requirements
- repair-pipeline self-improvement recurrence

## Main Argument

The software substrate should be designed around one rule: generated software is not accepted because it exists; it is accepted only because it satisfies a staged evidence contract. That contract begins before code generation and continues after deployment.

First, specification precedes generation. AgentBuilder should receive a target agent description, validate naming and dependency order, derive or retrieve method-memory contracts, produce a projected specification, and define required capabilities, data access, trust tier, tool use, and expected artifacts. This stage prevents the code generator from becoming the de facto requirements authority.

Second, generated code must stay inside an LLM-native programming discipline. Consullo's static-method, JSON-only, PDCA signature pattern is designed to reduce hidden state, framework magic, inheritance complexity, and serialization mismatch. This does not make generated code correct, but it narrows the surface that validators and LLM repair agents must understand. Capability Status: specified, with implementation varying by repository. Software-capability thresholds here use Consullo Capability Status; RSP-style frontier-risk thresholds remain a separate safeguard-mapping question.

Third, complex LLM tasks should be decomposed. Atomic prompt and compiled-code orchestration pushes deterministic parsing, classification, validation, graph search, constraint checking, and workflow transitions into compiled algorithms where feasible. LLMs should handle ambiguous language and synthesis tasks, not every procedural step. This makes cost and reliability part of software architecture.

Fourth, repair must be a pipeline, not a one-shot patch. The proposed repair cluster includes fault localization, execution-trace analysis, static-analysis integration, historical-fix retrieval, repair knowledge graphs, contrastive test generation, patch candidate generation, patch validation, patch ranking, multi-hunk coordination, runtime error diagnosis, security vulnerability repair, regression validation, repair metrics, and semantic patch validation. Capability Status: proposed.

Fifth, verification must distinguish levels of evidence. Compilation and tests are necessary but insufficient. Post-verification methods, semantic validators, static analyzers, contrastive tests, regression tests, provenance checks, property checks, and human or AAF escalation for high-stakes changes all supply different kinds of evidence. A software substrate that collapses them into "tests passed" will overaccept plausible but wrong patches.

Sixth, deployment must be staged and reversible where feasible. Secure AgentBuilder pipeline requirements imply deterministic builds, artifact signing, attestation, registry allowlists, full pipeline re-evaluation for modifications, runtime capability gating, and append-only audit records. YOLO mitigation adds integrity monitoring and restoration expectations for autonomous file operations.

## Expansion: Substrate Topology

Thesis 4 is the executable bridge between the other theses and the repository. Thesis 1 can define an accepted improvement, but Thesis 4 determines whether that improvement can become code, tests, method memories, deployment artifacts, and monitoring hooks. Thesis 2 can decompose a task cognitively, but Thesis 4 determines which parts become deterministic algorithms, atomic prompts, generated files, or workflow automation. Thesis 3 can recommend an experiment, but Thesis 4 builds the instrumentation and stores the resulting artifact. Thesis 5 can block or constrain a change, and Thesis 4 must make that block operational rather than advisory.

The substrate should therefore be understood as a pipeline of artifact transformations under evidence gates. A specification becomes a candidate design. A candidate design becomes generated or edited source. Source becomes compiled artifacts. Compiled artifacts become test results, validation reports, provenance records, and deployment candidates. Deployment candidates become staged runtime exposure. Runtime exposure becomes monitoring data and repair history. At every transition, the system can reject, revise, narrow, escalate, or promote.

This topology avoids the misleading phrase "self-modifying code" as a single act. Consullo's stronger and safer claim is multi-stage self-modifying software under constraints. The modification is not only the patch. It includes the specification, prompt, model or tool invocation, generated artifact, tests, validation suite, provenance, permission state, deployment stage, and post-deployment evidence. A patch that cannot be traced through those stages is not a valid substrate modification for recursive improvement.

The substrate has to preserve both determinism and uncertainty. Compilation, formatting, schema validation, dependency analysis, and many static checks are deterministic. LLM-generated code, semantic interpretation, repair strategy selection, and high-level documentation are probabilistic or judgment-laden. A credible substrate keeps these evidence classes separate. It should not pretend that LLM semantic review is a proof, and it should not treat deterministic compilation as semantic correctness.

The topology also clarifies why Thesis 4 imports Thesis 1 and Thesis 5. Thesis 4 should not decide alone that a code change is an improvement. It can provide evidence to Thesis 1. It should not decide alone that a high-stakes action is permissible. It can provide provenance, tests, rollback, and deployment context to Thesis 5. The software substrate executes decisions under imported acceptance and permission semantics.

## Expansion: Specification Before Generation

The first software-substrate invariant is that specification precedes generation. A generated agent should not define its own requirements after the fact. The specification should name purpose, scope, PDCA method contract, JSON input and output schemas, dependencies, tool privileges, data access, trust tier, expected artifacts, tests, provenance requirements, deployment stage, and rollback path. If these fields are missing, the generator should return for specification repair rather than inventing unchecked behavior.

This requirement is especially important for agents. Agent generation can produce plausible Java classes, descriptions, cards, tests, and documentation even when the underlying role is underspecified. That fluency is dangerous. A class with a good name and syntactically correct methods can smuggle in authority, data access, or unbounded tool use if the specification is loose. Thesis 4 therefore treats agent purpose, scope, dependencies, and privileges as gate inputs rather than prose context.

Specification repair should be an explicit stage. If the desired artifact lacks a clear scope, conflicts with existing dependencies, duplicates an existing agent, requests unsafe privileges, or lacks a validation path, the system should repair the specification before generating code. This may involve narrowing the role, splitting the agent, adding tests, requiring human approval, or routing to Thesis 5. A bad specification should not be passed downstream merely because the code generator can produce something.

The specification should also state what is not being generated. Non-goals prevent capability creep. For example, a utility agent that repairs descriptions should not silently gain authority to modify source code. A compilation validator should not silently become a deployment approver. A documentation generator should not become a policy author. Non-goals are not cosmetic; they define boundaries that validators can check.

Finally, the specification should create a provenance anchor. Later artifacts should link back to it. If a patch is accepted, the evidence ledger should be able to answer: accepted relative to which specification? If a deployment fails, rollback should know which specification was violated. If a method memory is extracted, lineage should identify which specification and validation outcomes produced it. Without this anchor, recursive repair becomes story-driven rather than evidence-driven.

## Expansion: LLM-Native Functional Java

Consullo's LLM-Native Functional Java discipline is a software-substrate strategy. It is designed to make generated code easier for both compilers and language models to inspect. Static methods reduce hidden instance state. JSON-only data exchange standardizes boundaries. PDCA signatures encourage methods to declare their planning, doing, checking, and acting semantics. The goal is not aesthetic purity. The goal is a narrower, more replayable surface for generation, repair, and validation.

This discipline is a response to the failure modes of unconstrained generated software. Inheritance hierarchies, hidden mutable state, framework magic, reflection-heavy behavior, implicit dependency injection, and ad hoc serialization can make generated code difficult to reason about. They also make repair harder because local patches may have distant effects. A static-method, JSON-envelope style can be verbose, but it gives validators more visible contracts.

The methodology should not be treated as proof of correctness. A static method can still be wrong. JSON can still carry invalid semantics. A PDCA signature can be filled with shallow behavior. The claim is more limited: these constraints reduce certain classes of hidden complexity and make automated validation more tractable. Capability Status remains specified, with implementation varying by component.

LLM-Native Functional Java also supports repair. When methods share predictable signatures and data exchange patterns, repair agents can localize errors, compose prompts with known context, generate verification methods, and compare outputs more reliably. A repair model that has to infer both business logic and framework structure at once is more likely to produce plausible but wrong patches. Methodological regularity reduces the burden on the model and increases the value of deterministic checks.

The tradeoff is that methodology constraints can become rigidity. Some software problems may require richer abstractions, persistent state, streaming behavior, or specialized libraries. The substrate should allow exceptions, but exceptions should be explicit. A generated artifact outside the methodology should carry a rationale, additional validation requirements, and possibly a higher risk lane. Methodology deviation is not forbidden; silent deviation is.

## Expansion: Atomic Prompt And Compiled-Code Orchestration

Atomic prompt decomposition is a cost and reliability discipline for the software substrate. It asks which parts of a task require language reasoning and which parts should be handled by deterministic algorithms. Parsing, schema validation, regex extraction, graph traversal, workflow state transitions, dependency analysis, and many classifications can often be implemented as compiled code. Ambiguous synthesis, explanation, naming, and interpretation may still require LLM calls. The substrate should route accordingly.

This matters for self-modifying software because LLMs are expensive and probabilistic. If every step of code generation, validation, and repair is handled by a monolithic prompt, the system becomes harder to audit and more expensive to improve. Atomic decomposition creates smaller prompts with clearer input/output contracts. Compiled-code orchestration makes repeated deterministic work cheaper and more stable. The result is not only lower cost; it is better evidence separation.

In a software-repair workflow, deterministic components might identify changed files, parse compilation errors, map missing imports, check naming conventions, run tests, compare JSON schemas, and extract method signatures. Atomic prompts might propose a repair strategy, explain a semantic mismatch, summarize a failure trace, or generate a candidate patch. Post-processing should then validate the output through deterministic checks wherever possible. The LLM should not be the only judge of its own patch.

Atomic decomposition also supports method-memory reuse. A successful repair can be stored as a method memory with deterministic steps, prompt templates, expected inputs, expected outputs, cost hints, and validation conditions. Future tasks can reuse the deterministic skeleton while adapting only the language-heavy components. This is how Thesis 4 connects to Thesis 1: the software substrate produces method memories that can improve future software modification.

The risk is over-decomposition. Splitting a task into too many atomic prompts can increase coordination overhead, lose context, or create brittle handoffs. The substrate therefore needs measurement: token cost, latency, failure rate, context-loss rate, repair success, and post-deployment outcomes. Atomic prompt decomposition is an engineering hypothesis until those measures show benefit for a task class.

This compile-once-run-many discipline now has direct empirical backing. External work on "compiled AI" formalizes the same paradigm Consullo already carries in its vocabulary (the `CompiledAI*` agent family) and in its static-method, JSON-passing execution model: an LLM generates a validated code artifact during a one-time compilation phase, after which the workflow runs as deterministic static code with zero further model calls (Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation, arXiv:2604.05150, "Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation"). The key observation is the one above stated sharply — many workflows require intelligence to *design* but not to *execute* — and removing the model from the execution loop pays off on three axes at once: it eliminates per-transaction output variance (the study reports 100% reproducibility versus 18–75% runtime variance even at temperature 0), it collapses cost (a fixed generation cost amortized across all later executions, break-even near a couple dozen transactions), and it shrinks the prompt-injection attack surface from one model call per transaction to one per compiled workflow. Four design principles transfer directly: constrained generation into narrow, well-defined functions bounded by tested templates; compilation over interpretation (the artifact is validated, tested, and deployed as static code); validation as a hard requirement before deployment; and *compliance by construction* — encoding regulatory, hazard, and Friendship constraints into the templates and prompt blocks so generated code inherits them by default rather than being audited for them afterward.

For the steps that genuinely cannot be precompiled — extracting a structured field from an ambiguous note, classifying under semantic uncertainty — the same work names the right discipline: *bounded agentic invocation*, in which the deterministic artifact calls an LLM for a specific narrow subtask under a defined output schema, with fallback logic, drift monitoring, and a human-escalation threshold, while the overall flow stays deterministic. This is exactly the bounded `llm_assist` step of a method memory, and the substrate should require those four guards — schema, fallback, drift monitoring, escalation — on any such step rather than treating a bounded LLM call as a free deterministic substitute (see `../../technical-reports/method-memory/method-memory.md`).

## Expansion: Repair As Pipeline

Repair should be modeled as a pipeline because real software failures rarely map cleanly to one patch. A compilation failure may reveal a dependency mismatch, which reveals a naming inconsistency, which reveals a generated specification gap. A runtime failure may require trace analysis, input reconstruction, data-shape validation, and semantic review. A security defect may require policy analysis, test generation, and staged rollout. A one-shot patch generator cannot carry this structure reliably.

The repair pipeline begins with fault characterization. The system should classify whether the failure is syntactic, compilation-related, dependency-related, interface-related, test-related, semantic, runtime, security-relevant, performance-related, provenance-related, or permission-related. Misclassification sends the repair to the wrong tools. For example, treating a semantic invariant failure as a missing import problem can produce a compiling patch that preserves the bug.

The next stage is context retrieval. HistoricalFixRetriever, RepairKnowledgeGraphManager, method memories, dependency graphs, test history, and provenance records should provide prior repair patterns. Retrieval should be scoped. A pattern useful for a generated agent description may be unsafe for authentication code. A historical patch that fixed a test may be an anti-pattern if it later caused a regression. Repair retrieval needs validation history, not only textual similarity.

Patch generation should be plural when the failure is ambiguous. A single candidate may be enough for routine deterministic repairs. For semantic, security, or multi-file defects, the pipeline should produce several candidates or at least several repair rationales. PatchCandidateGenerator and MultiHunkRepairCoordinator should preserve alternatives because rejected alternatives can teach validators and future repair agents.

Patch validation should layer evidence. Compilation and target tests come first, but regression tests, contrastive tests, static analysis, security checks, semantic validation, provenance checks, and permission gates all matter. A candidate that passes the target test while deleting validation logic should be rejected. A candidate that fixes a local issue while requesting broader privileges should route to Thesis 5. A candidate that cannot link to its specification should fail provenance.

Patch ranking should not rank only by tests passed. It should consider scope minimality, semantic fit, regression risk, security impact, cost, maintainability, provenance completeness, and deployment risk. A larger patch may be justified when the failure is architectural, but large patches should carry stronger evidence. A small patch may be attractive, but a minimal change that hides a deeper defect is not necessarily better.

The pipeline ends with learning. Accepted patches update repair patterns and method memories. Rejected patches become anti-patterns or future benchmark cases. Incidents update risk models. Regressions update validator suites. Cost overruns update routing. This learning is what makes the repair pipeline recursive rather than merely automated.

## Expansion: Validation Evidence Classes

The software substrate needs a richer validation vocabulary than "tests passed." Tests are important, but they are only one evidence class. A generated or repaired artifact should be evaluated through multiple lenses: methodology conformance, compilation, unit tests, regression tests, contrastive tests, static analysis, security scanning, post-verification methods, semantic validation, deployment monitoring, provenance, cost/benefit, and permission state. Different scopes require different depth.

Methodology conformance checks whether the artifact follows Consullo's coding discipline: static methods where expected, JSON input and output envelopes, PDCA signatures, bounded side effects, clear dependencies, and no silent privilege expansion. Compilation checks whether the code builds. Unit tests check local behavior. Regression tests check previously protected behavior. Contrastive tests distinguish a correct patch from plausible wrong alternatives. Static analysis catches type, dependency, style, and sometimes security issues. Security scanning looks for capability, injection, auth, data, and network risks.

Post-verification methods are especially relevant to generated agents. A generated method may include or trigger verification logic that checks postconditions, return-value integrity, state consistency, and schema validity after important operations. These methods do not prove correctness, but they turn some hidden failures into observable failures. They also create reusable validation patterns for future agents.

Semantic validation is the hardest class. A patch can compile and pass tests while changing intended meaning. Semantic validation may include property checks, invariant checks, symbolic or formal reasoning for narrow functions, LLM-assisted review, trace comparison, contract checking, or human review. The substrate should label which kind of semantic validation was used. A formal property check is not the same as an LLM explanation that the patch "looks right."

Deployment monitoring is the final evidence class. It observes what happens after staged exposure. Some defects only appear under realistic inputs, concurrency, latency, external services, or user behavior. Deployment evidence should record incident rate, rollback events, performance change, error change, unexpected tool use, trust-scope violations, and downstream agent behavior. Without deployment monitoring, validation ends before the system sees reality.

The acceptance gate should preserve evidence-class coverage. For low-risk reversible internal changes, compilation, tests, and provenance may be enough. For high-stakes changes, no single class is enough. A security-sensitive patch may require static analysis, security tests, AAF or human escalation, and staged deployment. A validator change may require a held-out reference suite. A generated agent with external tool privileges may require scoped trust, policy review, and runtime capability gating.

## Expansion: Semantic Validation And Plausible Wrongness

The central software risk is plausible wrongness: code that looks reasonable, compiles, passes available tests, and still violates intended behavior. LLM-generated code is particularly vulnerable because it often optimizes for local plausibility. Automatic program repair has long shown a related problem: patches can satisfy an incomplete test suite by exploiting gaps rather than implementing intended semantics.

Plausible wrongness appears in many forms. A patch may hard-code a test value. It may catch and suppress an exception that should surface. It may broaden permissions to make a workflow pass. It may delete a validation check that blocks bad inputs. It may convert a security failure into a warning. It may satisfy a JSON schema while changing business meaning. It may preserve the public method signature while violating a hidden invariant. It may improve latency by skipping evidence preservation.

The substrate should therefore generate tests that try to distinguish intended semantics from test overfitting. ContrastiveTestGenerator exists for this reason. A contrastive test asks not only "does the patch pass the observed failure?" but "does it behave differently from known wrong repairs?" For example, a repair that handles missing imports should not remove the dependency check. A repair that fixes a failing JSON parser should not accept arbitrary malformed JSON. A repair that resolves a permission error should not disable permission enforcement.

Semantic validation should also use specification linkage. The validator should ask which part of the specification the patch satisfies. If no specification clause is linked, the patch may be fixing a symptom without evidence of intended behavior. This is another reason specification must precede generation. Semantics cannot be validated against vibes; it must be validated against a contract, invariant, property, example set, or explicit human decision.

LLM-assisted semantic review can be useful, but it should be treated as probabilistic evidence. It can explain likely intent, compare code to specification, identify suspicious changes, or propose invariants. It should not be the only semantic validator for high-stakes code. Where possible, LLM review should produce artifacts that deterministic tools can check: properties, tests, invariants, or proof obligations.

The long-term research problem is to bind semantic validation to task classes. Some functions can be validated with property tests or formal methods. Some workflows can be validated with regression suites and trace comparison. Some policy logic can be validated with rule engines and adversarial cases. Some language-heavy behavior may only be validated statistically and through human review. Thesis 4 should not pretend one technique covers all software.

## Expansion: Provenance And Reproducibility

Self-modifying software without provenance is not recursive improvement; it is unmanaged mutation. Every generated or repaired artifact should be traceable to its specification, triggering request, prompt or method memory, model or tool, source files, validation results, permission state, deployment stage, and post-deployment outcome. Provenance is what lets the system reproduce, audit, roll back, and learn from changes.

Provenance should include rejected candidates where practical. A rejected patch can reveal a misleading prompt, a recurring model failure, an underspecified requirement, or a benchmark weakness. If only accepted patches are stored, the system loses evidence about the search space and repeats mistakes. Rejected candidates do not need the same retention depth as accepted high-stakes changes, but they should preserve enough reason codes to support learning.

Build reproducibility is part of provenance. A future reviewer should be able to know which code version, dependency set, test suite, environment, and toolchain produced a validation result. If a validation result cannot be reproduced or meaningfully replayed, it should not carry the same weight as reproducible evidence. This matters for recursive improvement because future modifications will use past validation as training data or method-memory evidence.

Provenance also constrains deployment. A deployment artifact should link to the accepted patch, specification, validation record, permission state, and rollback plan. If an artifact cannot be linked, it should not be promoted. This is especially important for generated agents, because generated files, descriptions, cards, tests, and configuration may drift apart. Cross-artifact consistency is part of provenance, not a documentation nicety.

The evidence ledger should represent provenance as a view, but physical implementation may require hashes, signatures, append-only logs, commit IDs, artifact identifiers, and external backups. Thesis 4 should not claim those mechanisms exist unless they do. At the design level, the requirement is clear: no accepted software modification participates in recursive improvement unless it has auditable lineage.

## Expansion: Staged Deployment And Rollback

Staged deployment is how the substrate prevents validation from becoming an all-or-nothing decision. A candidate can be accepted for static review, sandbox, benchmark, canary, production, or post-deployment observation. Each stage has different evidence requirements and different reliance permissions. A patch that is acceptable in sandbox may be unacceptable in production. A generated agent may be allowed to run on synthetic inputs but not on external requests or sensitive data.

Sandboxing should isolate candidate behavior from production effects. It can use mocked services, synthetic data, limited tool access, and controlled inputs. Benchmark stage evaluates against known task suites. Canary stage exposes the change to limited real usage or a narrow internal scope. Production stage allows broader reliance. Post-deployment observation continues evidence collection and can demote, roll back, or constrain the artifact.

Rollback must be realistic. Code rollback can restore a prior commit, but it may not undo data writes, external messages, security exposure, customer impact, or learned state changes. The substrate should therefore distinguish rollback from mitigation. A reversible internal code change may only need a revert path. An externally visible change may need notification, compensation, key rotation, incident review, or trust downgrade. Thesis 4 imports Thesis 5 on this point.

Deployment gates should also check runtime capability. An agent may compile and pass tests but still request tools beyond its intended scope. Runtime capability gating should enforce allowed tools, data access, network egress, file operations, and external communication. These controls should be tied to the specification and trust scope. Generated code should not be allowed to expand its own runtime authority by editing configuration or manifests without separate review.

YOLO-mode mitigation belongs in this deployment discussion. Autonomous file operations and broad write privileges can be useful for development, but they create obvious risk. Integrity monitoring, restoration expectations, audit logs, and guarded execution are not optional if the system can modify repository state. A substrate that can write but not restore or explain what it wrote is not ready for recursive improvement.

## Expansion: Validator Non-Regression

The formal appendix states that recursive pipeline improvement must not weaken validators on a held-out reference suite unless a documented human-authorized trade replaces that suite with a stronger one. This is a key Thesis 4 invariant. Generator improvements are tempting because they produce more patches, faster patches, or more successful benchmark outcomes. But if the improvement comes from weakening validation, the pipeline has become more dangerous.

ValidatorStrength should eventually be defined as a composite. It might include acceptance rate on known-good candidates, rejection rate on known-bad candidates, detection of semantically wrong test-passing patches, security-failure detection, provenance-gap detection, and calibration of risk severity. The exact formula may vary by task class, but the principle is stable: a validator should not become more permissive without evidence that permissiveness reflects better discrimination rather than weaker gates.

The reference suite should include historical false accepts, false rejects, adversarial patches, security-sensitive examples, provenance failures, specification mismatches, and routine good patches. If it contains only ordinary successful repairs, a validator can look strong while missing the real failure modes. The suite should also be versioned. Replacing it may be necessary as the system evolves, but replacement should be auditable.

Validator non-regression applies to generated tests too. A test generator can improve coverage, but it can also encode the same mistaken assumption as the code generator. If generated tests are used to validate generated code, independence is weak. The substrate should distinguish tests derived from the same prompt context from tests produced by independent specifications, historical regressions, contrastive cases, or human review.

This invariant ties Thesis 4 to Thesis 1. A proposed validator change is an improvement candidate. It should have baseline, target metric, evidence package, cost, side-effect checks, protected-set non-regression, and rollback plan. Validator changes are high leverage and should not be treated as ordinary refactors.

## Expansion: Implementation Mapping

Current repository evidence gives Thesis 4 a stronger footing than the more speculative cognitive or causal theses, though a weaker one than it had before August 2026. AgentCompilationValidator provides real compilation validation. Utility classes support agent generation, repair, card repair, description repair, verification-method composition, dry-run method composition, and check-in insertion; all of these remain in the repository. Dependency and integration-order validation, method-call testing for loaded agent classes, and repair-workflow coordination for interface, compilation, test, and dependency failures were implemented and tested until 2026-08-10, when the subsystem containing them was deliberately removed. They are currently specified rather than implemented, no successor class performs them, and they should not be read as present capability.

This evidence matters because it shows that Consullo already contains pieces of a self-modifying substrate. The pieces are not merely agent names. They are source files and tests. They support a conservative claim: parts of compilation validation, dependency validation, A2A dispatch, agent utilities, and reporting are implemented and tested. This is not enough for the full thesis claim, but it is enough to ground the substrate in repository reality.

The gaps are equally important. The repository evidence map does not identify a formal semantic-validation layer matching this thesis. ValidatorStrength and held-out validator-non-regression suites are specified but not implemented. Staged sandbox/canary/production deployment semantics are not established as an operational pipeline. Provenance proofs and append-only evidence-ledger integration are specified but not implemented as a full substrate. Secure pipeline controls are documented/proposed rather than demonstrated end to end.

The first implementation milestone should connect existing pieces into one bounded repair demonstration. A known compilation failure should trigger repair, produce a candidate, run AgentCompilationValidator, record provenance, report cost, and produce an evidence-ledger entry. Extending the demonstration to dependency failures additionally requires rebuilding dependency validation and, if method-call testing is wanted in the loop, A2A integration testing; both were removed on 2026-08-10 and are prerequisites of that extension rather than existing pieces to connect. The demonstration can remain internal and low-risk. Its value is showing the shape of the loop.

The second milestone should add semantic or contrastive validation for one task class. For example, a generated repair should face tests that distinguish missing-import repair from validation-removal repair. The goal is not comprehensive semantics. It is evidence that the substrate recognizes test-passing plausible wrongness as a distinct failure mode.

The third milestone should add staged deployment semantics. A candidate should move through branch, sandbox, benchmark, or canary states with explicit gates and rollback. Even a simulated deployment stage would improve the evidence story if it links artifacts, validation, permission, and outcome. Without staging, Thesis 4 remains closer to generation and repair tooling than to a self-modifying substrate.

## Expansion: Secure Pipeline And Authority Leakage

The secure software pipeline is where Thesis 4 most directly meets Thesis 5. Generated code is not dangerous only because it may be wrong. It is dangerous because it may request or acquire authority beyond the scope that justified its creation. Authority leakage can occur through build scripts, configuration files, registry entries, deployment manifests, environment variables, tool permissions, network access, file-system write access, dependency additions, or agent cards that advertise broader capabilities than the implementation was reviewed for.

Secure pipeline controls should therefore validate more than source code. They should validate manifests, dependencies, runtime capability tokens, registry entries, generated documentation, and deployment configuration. A generated agent whose Java class is narrow but whose card requests broad external-tool authority is a substrate failure. A patch that changes a helper method but also updates configuration to grant new network egress is a high-stakes permission change. A dependency addition that introduces remote code execution risk is not merely a build change.

Artifact signing and attestation are useful because they make the accepted artifact distinguishable from later mutation. Registry allowlists are useful because they prevent unreviewed generated agents from becoming routable by default. Runtime capability gating is useful because it enforces scope after deployment rather than trusting the code's intention. Append-only audit records are useful because they preserve the path from specification to deployment.

The pipeline should also treat dependency changes as first-class modifications. Generated code often pulls in libraries to solve local problems. Dependencies can introduce license risk, security vulnerabilities, transitive bloat, version conflicts, and maintenance burden. A self-modifying substrate should prefer existing approved libraries where feasible, require justification for new dependencies, and route high-risk dependencies through security review.

Authority leakage is especially subtle in repair. A repair agent may "fix" a permission error by broadening access, "fix" a timeout by disabling a guard, or "fix" a validation failure by skipping validation. These patches can look locally successful. The secure pipeline should therefore compare requested authority before and after the patch. Any expansion of tools, data, network, deployment, or governance authority should trigger Thesis 5 routing.

## Expansion: Benchmark Strategy

Thesis 4 needs benchmarks that reflect the difference between coding-agent performance and self-modifying substrate reliability. The canonical benchmark-design contract for this strategy is `appendix-thesis-4-software-substrate-benchmarks.md`. This body section summarizes the software-evidence logic; the appendix defines benchmark families, report fields, reference-suite requirements, negative controls, minimal demonstration package, and non-claim boundaries.

SWE-bench-style tasks are useful because they test repository navigation, issue understanding, patch generation, and realistic software repair. They should be part of the comparison class. But Consullo also needs project-local benchmarks tied to its own substrate: agent generation, Java compilation repair, dependency repair, A2A method-call validation, check-in insertion, JSON envelope validation, verification-method composition, agent card repair, and generated documentation consistency.

The first benchmark layer should be deterministic local repair tasks. These include missing imports, bad package names, malformed JSON, missing check-in methods, inconsistent agent cards, dependency-order failures, and compilation errors. They are narrow, but they provide cheap signal and can be versioned. They are also good candidates for end-to-end Thesis 1 demonstrations because the baseline and expected outcome can be clear.

The second layer should be semantic near-miss tasks. These are cases where the obvious patch compiles and passes a target test but violates intent. For example, a patch might remove a validation branch, broaden a catch block, accept all JSON to avoid parse errors, skip an A2A auth check, or hard-code a test fixture. These tasks test whether SemanticPatchValidator, ContrastiveTestGenerator, RegressionTestValidator, and security checks can detect plausible wrongness.

The third layer should be multi-artifact consistency tasks. Generated agents often require source files, descriptions, cards, tests, documentation, and registry or deployment configuration to agree. A benchmark should test whether a generated or edited agent remains consistent across artifacts. This is where ConsistencyValidator and CodeProvenanceTracker matter. A class name mismatch, stale documentation, or incompatible agent card can be a real substrate failure even when source code compiles.

The fourth layer should be staged-deployment simulations. A patch should move through static review, sandbox, benchmark, canary, and production-like states. The benchmark should test whether promotion requires the right evidence and whether rollback or mitigation records are created when a stage fails. This layer can begin as a simulation; the important thing is to make deployment state part of validation rather than an afterthought.

The fifth layer should be validator-non-regression benchmarks. These should include known-good patches, known-bad patches, semantically wrong test-passing patches, missing-provenance patches, security-sensitive patches, and high-cost patches. A validator update should be tested against this suite before it is accepted. Generator performance alone is not enough; the substrate must maintain or improve discrimination.

Benchmarks should report cost. A repair pipeline that solves 10 percent more tasks at 10 times the cost may or may not be worthwhile depending on scope. Cost includes model calls, tool runtime, human review, validation time, deployment monitoring, and downstream maintenance. Cost reporting links Thesis 4 back to Thesis 1's bounded-compute discipline.

## Expansion: Validation Matrix And Evidence Depth

The software substrate needs a validation matrix that maps change type to required evidence depth. Without such a matrix, every change is either under-validated or over-validated. A missing-import repair does not need the same review as a validator modification. A generated documentation update does not need the same evidence as an authentication patch. A deployment manifest change does not have the same risk profile as a pure test addition. The matrix should make those differences explicit.

One axis of the matrix is artifact type: source code, test code, generated documentation, agent card, deployment configuration, registry entry, dependency file, method memory, prompt template, validator rule, and evidence-ledger schema. Each artifact type has different failure modes. Source code can be semantically wrong. Test code can encode the candidate's mistake. Documentation can mislead operators. Agent cards can advertise authority that code was not reviewed for. Deployment configuration can expand runtime privileges. Dependency files can import vulnerabilities. Validator rules can change future acceptance. Evidence-ledger schema changes can erase future auditability.

Another axis is risk lane: low-risk reversible, privileged internal, security-sensitive, validator-affecting, externally consequential, and alignment-infrastructure. A low-risk reversible change may need methodology conformance, compilation, unit tests, and provenance. A security-sensitive change may need static analysis, security-specific tests, dependency review, AAF or human escalation depending on scope, and staged deployment. A validator-affecting change should require a held-out reference suite and explicit ValidatorStrength non-regression. An alignment-infrastructure change should route through Thesis 5 because it affects future permission decisions.

A third axis is reversibility. Some software changes are easy to roll back at code level, but still hard to reverse operationally. A patch that writes data, changes external API behavior, rotates credentials, modifies trust state, or sends external messages may have effects that survive code revert. The validation matrix should distinguish code reversibility from effect reversibility. That distinction should drive deployment stage and rollback evidence.

A fourth axis is evidence maturity. A task class with stable benchmarks and historical failures can use more automation than a novel task class with little evidence. The substrate should not treat novelty as freedom. Novelty should usually increase evidence requirements, because validators have less historical calibration. Conversely, routine low-risk repairs can become more automated only after repeated evidence shows that automation catches the relevant failures.

The validation matrix should produce an evidence plan before generation begins. A generator should know what evidence a candidate must satisfy. This avoids a common repair failure where a patch is produced first and validation is improvised later. Pre-declared evidence also makes cost estimation more honest. If a candidate needs security review, contrastive tests, AAF routing, and canary monitoring, the evaluator should know that before spending generation budget.

The matrix should also allow rejection before code generation. If a requested change would require evidence that cannot currently be produced, the correct result may be `needs-input`, `blocked`, or `escalated`, not speculative generation. This is especially important for high-stakes changes whose validation requirements exceed current tooling. Producing plausible code for an unverifiable request is a substrate failure.

## Expansion: Staged Deployment State Machine

Staged deployment should be represented as a state machine rather than as a loose checklist. A candidate modification can move through states such as `specified`, `generated`, `compiled`, `validated`, `sandboxed`, `benchmarked`, `canaried`, `promoted`, `monitored`, `rolled-back`, `mitigated`, `rejected`, or `superseded`. Each state should have entry criteria, exit criteria, allowed actions, evidence requirements, and rollback semantics.

The `specified` state means the candidate has a scope, artifact plan, tests or validation plan, provenance anchor, permission lane, and rollback expectation. The `generated` state means an artifact exists but has not yet passed deterministic checks. No generated artifact should become routable solely because it exists. The `compiled` state means deterministic build checks passed. It does not mean semantic correctness. The `validated` state means required tests, static checks, semantic checks where applicable, security checks, provenance checks, and permission checks for that risk lane passed.

The `sandboxed` state limits effect. The candidate may run against synthetic inputs, mocked services, temporary files, or isolated branches. It should not have full external authority. The `benchmarked` state evaluates against versioned tasks. The `canaried` state exposes the candidate to narrow real or production-like usage with monitoring and rollback. The `promoted` state allows broader reliance but should still carry monitoring obligations. The `monitored` state collects post-promotion evidence and can trigger demotion.

Rollback states should be explicit. `Rolled-back` means code or configuration returned to a prior state. `Mitigated` means effects could not be fully reversed and compensating actions were taken. `Superseded` means a later accepted change replaced the candidate. These distinctions matter because recursive improvement learns different lessons from each. A clean rollback suggests staging worked. Mitigation suggests external effects escaped pure code recovery. Supersession may indicate the earlier change was incomplete or context changed.

Every transition should write evidence. Moving from generated to compiled writes build evidence. Moving from compiled to validated writes test and validation evidence. Moving from validated to sandboxed writes stage-entry rationale and containment boundaries. Moving from canaried to promoted writes monitoring evidence and permission state. Moving to rollback writes failure evidence and recovery actions. Without transition evidence, deployment state becomes a label rather than a control.

The state machine also supports automation boundaries. Low-risk candidates may move automatically through early states when evidence is complete. High-risk candidates should require human or Thesis 5 gates before later states. Validator-affecting changes may be prevented from promotion until reference-suite non-regression passes. The state machine should make these boundaries machine-checkable where feasible.

## Expansion: Validator Reference Suite Design

The validator reference suite is the most important implementation object for recursive repair-pipeline improvement. It is the suite that prevents generator improvements from being purchased by validator weakening. The suite should be held out from ordinary patch generation and should contain both accepted-good and rejected-bad examples. It should be versioned, provenance-linked, and reviewed when the repository or threat model changes.

A useful reference suite needs categories. Known-good candidates test whether the validator accepts correct, useful changes. Known-bad candidates test whether it rejects obvious failures. Semantically wrong but test-passing candidates test plausible wrongness. Security-sensitive candidates test whether authority leakage, missing auth checks, unsafe dependency changes, or data exposure are detected. Provenance-deficient candidates test whether missing lineage blocks acceptance. Cost-pathological candidates test whether locally correct but uneconomical changes are flagged. Severity-calibration cases test whether the validator classifies risk at the right level.

The suite should include historical false accepts and false rejects. A false accept becomes a future validator test so the same failure is not repeated. A false reject becomes a test of whether the validator is too conservative in a specific scope. Including both is important because validators can game a reference suite by rejecting everything or accepting only trivial changes. ValidatorStrength should reward discrimination, not severity for its own sake.

Reference-suite maintenance should be governed. Adding a case can improve coverage but also change incentives. Removing a case may be justified when it becomes obsolete, but removal should preserve the rationale and historical outcome. Changing weights in ValidatorStrength should be treated as a validator-affecting modification, not a local configuration tweak. If a future repair pipeline improves generator performance while reducing detection of semantic wrongness or security issues, the suite should reveal that trade.

The suite should also include adversarial variants. For example, a patch that fixes compilation by deleting a method, a patch that fixes JSON parsing by accepting everything, a patch that fixes auth failure by bypassing a policy gate, a patch that fixes a timeout by disabling timeouts, and a patch that fixes a test by hard-coding the fixture. These cases are valuable because they represent exactly the kinds of repairs an overfit generator might discover.

A first version of the reference suite can be small. It does not need to cover the entire repository. A dozen carefully chosen cases across known-good, known-bad, semantic, security, provenance, and cost categories would be more valuable than a large unstructured test dump. The point is to create an anchor for validator non-regression that can grow with evidence.

Empirical work on autonomous algorithm discovery adds three generation-side and scoring-side controls that complement this detection-side suite (Let the Barbarians In: How AI Can Accelerate Systems Performance Research, arXiv:2512.14806, ADRS, "Let the Barbarians In"). First, restrict the editable surface: an evolutionary or LLM optimizer will reward-hack whatever it is allowed to touch, so the candidate should be confined to the target function or module and forbidden from editing the evaluator, the workload, the scoring code, or the tests — the same threat the existing adversarial cases describe, but prevented at generation time rather than only caught at validation time. Second, use a smooth, deterministic scoring function: optimizers exploit noise and discontinuities, so a metric that is reproducible run-to-run and varies continuously with solution quality yields fewer spurious "wins" than a noisy or threshold-shaped one, and reduces the chance that an accepted improvement is measurement artifact. Third, evaluate against diverse, held-out workloads rather than a single trace, because a candidate tuned to one workload may regress on others; this is the software-substrate form of the transfer discipline that Thesis 1 applies to method memories.

## Expansion: Generated Test Governance

Generated tests deserve their own governance because they can either strengthen the substrate or make it more self-deceptive. A generated test can encode the intended behavior, capture a regression, or make a failure reproducible. It can also encode the candidate's bug, assert implementation details instead of specification, hard-code a fixture, or reward the patch that generated it. A self-modifying substrate must not treat generated tests as independent evidence by default.

Every generated test should have provenance. The record should say what generated it, what specification clause or failure it covers, whether it was generated before or after the candidate patch, what behavior it is meant to distinguish, and whether it was reviewed or validated independently. A test generated after seeing the candidate may still be useful, but it should not carry the same weight as an independent pre-existing or independently reviewed test.

Generated tests should be classified. A reproduction test captures the original failure. A regression test protects previously expected behavior. A contrastive test distinguishes a correct repair from known wrong repairs. A property test checks a general invariant over input space. A security test checks a policy, permission, or exploit path. A golden-output test checks known output for known input. These classes should be recorded because they provide different evidence.

Generated tests should also be subject to negative review. A test that simply mirrors candidate behavior without reference to specification is weak. A test that asserts a broad catch-all behavior may be dangerous. A test that lowers security expectations should be rejected. A test that makes the suite more brittle without improving semantic coverage should be revised. Test generation is itself a modification of future validation pressure, so it belongs under Thesis 1 acceptance semantics.

Independence matters. Ideally, a different process, model, prompt, or deterministic rule should review generated tests than the one that generated the patch. When that is not feasible, the evidence package should mark the independence gap. For high-stakes changes, generated tests should not be the only new evidence. They should be paired with static checks, property checks, human review, or AAF/human escalation where appropriate.

Generated tests can improve recursive capability if governed well. They turn failures into reusable validators, reduce repeated manual review, and improve future repair. But if governed poorly, they train the system to satisfy its own artifacts. The distinction should be visible in evidence records.

## Expansion: End-To-End Software Demonstration Blueprint

The strongest next implementation evidence for Thesis 4 would be a bounded end-to-end software modification demonstration. It should not attempt general autonomous coding. It should demonstrate that a candidate change can move through specification, generation or repair, validation, provenance, permission, staged exposure, observation, and learning.

The first demonstration should use a low-risk repository-local task with deterministic validation, such as repairing a compilation failure, dependency mismatch, malformed agent card, missing check-in method, or generated description inconsistency. The baseline should be reproducible. The expected outcome should be narrow. The artifact set should be small enough for a reviewer to inspect manually.

The demonstration should produce a specification record before any patch. The specification should name scope, expected files, non-goals, validation plan, permission lane, and rollback expectation. Then the generator or repair utility should produce a candidate. The evidence package should record model or tool used, prompt or method memory, files changed, and cost.

Validation should then run in layers. Compilation or deterministic checks should run first. Target tests should follow. Regression or contrastive tests should run where available. Provenance should be checked. If the candidate touches permission, security, validator, deployment, or evidence-ledger surfaces, it should route to stronger review. The result should be a structured validator record, not a narrative summary.

The demonstration should include a rejected candidate. This could be a patch that compiles by removing a validation check, a test that asserts the wrong behavior, or a metadata change that expands authority. Rejecting a plausible candidate is as important as accepting a correct one because it shows that the substrate is not merely a patch-production engine.

The demonstration should include a staged state. Even if no production deployment occurs, the candidate should enter a sandbox or simulated canary state with defined entry and exit conditions. Observation should record whether the change behaved as expected. Rollback or supersession should be possible and documented.

Finally, the demonstration should extract a method memory or anti-pattern. A successful repair can produce a reusable method for a narrow task class. A failed repair can produce an anti-pattern or reference-suite case. This is the recursive connection: the software substrate should improve not just the object-level code, but future repair and validation behavior.

## Expansion: Publication-Grade Evidence Package

Before Thesis 4 is positioned as more than a specified and partially implemented substrate, it needs a publication-grade evidence package. That package should be small, reproducible, and auditable. It should not be a broad claim that the system codes autonomously. It should be a trace of one or more bounded modifications through the full substrate.

The package should include repository commit or snapshot identifiers, task specification, baseline failure, candidate artifact diff, generation or repair trace, validation results, provenance record, permission state, deployment or simulation stage, monitoring result, cost report, and learning artifact. It should also include a clear list of what was not demonstrated: no full semantic-validation layer, no full staged deployment pipeline, no validator-non-regression suite unless it exists, no proof of safe self-modification, and no unrestricted autonomy.

A skeptical reviewer should be able to replay the evidence or at least inspect every link. If a test passed, the reviewer should see which test. If a repair was accepted, the reviewer should see why. If a candidate was rejected, the reviewer should see the reason. If cost was measured, the reviewer should see what counted. If permission was satisfied, the reviewer should see which scope and authority applied.

The package should also distinguish component evidence from integrated evidence. AgentCompilationValidator is component evidence. A complete repair demonstration that uses it as part of an acceptance-gated workflow is integrated evidence for a narrow scope. A second-cycle method-memory effect would be stronger recursive evidence. Treating component evidence as integrated evidence is the main evidence-inflation risk for Thesis 4.

This package can become the template for future claims. Each stronger software-substrate claim should add evidence: more task classes, semantic near misses, security-sensitive cases, deployment stages, validator-reference suites, and post-deployment observations. The suite should grow by evidence increments rather than by broadening language.

## Expansion: Open Research Questions

The first open question is how to operationalize `ValidatorStrength`. The formal appendix now defines a first-pass composite convention over known-good acceptance, known-bad rejection, semantic-wrongness detection, security detection, provenance-gap detection, and severity calibration. The remaining problem is empirical: constructing held-out reference suites, choosing weights, and showing that validator non-regression can be measured in a way that resists gaming. A useful definition must account for both acceptance of correct candidates and rejection of incorrect candidates. It should not reward validators for rejecting everything, and it should not reward permissiveness that increases post-deployment regressions.

The second open question is how much semantic validation can be formalized. Some properties can be checked with deterministic tests, contracts, type systems, model checking, or property-based tests. Other properties depend on intended use, human judgment, policy interpretation, or external effects. The substrate should push semantics toward formal or deterministic checks where feasible, while marking judgment-based semantic review as probabilistic evidence.

The third open question is how to prevent repair agents from learning the benchmark too well. A repair pipeline that repeatedly trains on project-local failures may become excellent at satisfying project-local tests while brittle elsewhere. Hidden tests, benchmark refresh, adversarial variants, and external comparison tasks can reduce this risk. Post-deployment monitoring remains necessary because no benchmark suite can cover all real behavior.

The fourth open question is how to handle generated tests. Generated tests are useful because they increase coverage quickly. They are dangerous because they may encode the same mistake as the generated code or assert the candidate's behavior rather than the specification's behavior. The substrate needs provenance for tests too: where did the test come from, what specification clause does it cover, what failure would it catch, and is it independent of the candidate?

The fifth open question is how to balance method regularity against expressive power. LLM-Native Functional Java makes code easier to generate and verify, but some domains may need richer abstractions. The substrate should not turn methodology into a straitjacket. It should instead treat deviations as higher-evidence changes: allowed when justified, but not silently accepted.

The sixth open question is how to secure the generator itself. A system that can generate agents and deployment artifacts is an attractive target for prompt injection, dependency confusion, malicious specifications, compromised templates, and poisoned method memories. Thesis 4 imports external-input distrust from Thesis 5, but implementation needs concrete controls: sanitization, source trust, dependency pinning, review of generated privileges, and audit-preserving provenance.

The seventh open question is how much human review remains necessary. Full automation is risky; full manual review does not scale. The answer likely depends on scope and stage: low-risk deterministic repairs can be heavily automated, semantic or security-sensitive changes need stronger review, and high-stakes externally consequential changes require Thesis 5 routing. The substrate should make this a policy table, not an informal judgment.

## Expansion: Claim Status Table

The following status table should guide long-form revisions:

| Claim | Capability Status | Evidence Status | Notes |
| --- | --- | --- | --- |
| Consullo specifies a self-modifying software substrate with acceptance gates | specified/proposed | Documented | Supported by this thesis, formal model, and source corpus. |
| Compilation validation exists for parts of the repository | implemented for parts | Implemented/Tested for parts | Evidence map cites AgentCompilationValidator and tests. |
| Dependency and A2A integration checks exist for parts of the repository | specified, not implemented | Documented/Proposed | Implementations were removed 2026-08-10 with the subsystem containing them; no successor exists. |
| Agent-generation and repair utilities exist | implemented for parts | Implemented/Tested for parts | Evidence map cites utility classes; not a complete AgentBuilder pipeline. |
| LLM-Native Functional Java constrains generated code | specified | Documented/partially implemented | Methodology exists; coverage varies by component. |
| Atomic prompt and compiled-code orchestration is integrated into the substrate | specified/proposed | Documented/Proposed | Designs exist; full integration evidence pending. |
| Formal semantic-validation layer exists | proposed | Gap | No full implementation identified in evidence map. |
| Validator non-regression suite and `ValidatorStrength` are implemented | proposed | Gap | Formal requirement exists; implementation pending. |
| Staged sandbox/canary/production deployment pipeline exists | proposed | Gap | Deployment semantics specified; operational pipeline pending. |
| Consullo can safely rewrite itself autonomously | not claimed | Not applicable | Explicitly outside the thesis claim. |

The table exists to prevent evidence inflation. Thesis 4 has real implementation evidence, but it is component evidence. The long-form thesis should not let component evidence imply the full substrate is operational. The correct claim is that Consullo has implemented pieces that could support a self-modifying substrate, while the integrated acceptance-gated substrate remains specified/proposed.

## Expansion: Publication Boundary

Thesis 4 can be presented as a serious software-engineering architecture because it names concrete mechanisms, repository evidence, formal predicates, and known gaps. It should not be presented as a demonstrated autonomous coding system. It should not be presented as proof that generated code can be safely accepted through tests. It should not be presented as evidence that semantic validation, secure deployment, or validator non-regression are solved.

The publication boundary should be: Consullo specifies and partially implements components of a self-modifying software substrate. It has compilation validation, dependency validation, A2A testing, repair orchestration, generation utilities, and design-level methodology. It still lacks a complete semantic-validation layer, validator-non-regression implementation, provenance proofs, staged deployment pipeline, and end-to-end demonstration where an accepted software modification passes through Thesis 1 and Thesis 5 gates.

That boundary is not a weakness. It makes the thesis falsifiable. A reviewer can ask whether the repository evidence supports each component. A future implementation can close gaps one by one. A failed attempt to implement semantic validation or staged deployment would be evidence that the substrate needs revision. This is exactly the discipline the five-thesis suite is meant to impose.

## Agent Cluster And Architecture

Primary Thesis 4 agents and functions:

- `AgentBuilder`: orchestrates multi-stage agent construction
- `AgentEditor`: modifies existing agents through constrained specification and repair pathways
- `AgentDocumenter`: generates documentation and design artifacts
- `CodeProvenanceTracker`: links changes to proposals, evidence, authorship, and outcomes
- `WorkflowAutomationCompiler`: converts workflows into executable automation
- `FormalProofConstructor`: provides formal reasoning or proof artifacts where feasible
- `ReasoningChainVerifier`: checks reasoning artifacts used in generation or repair
- `ConsistencyValidator`: checks cross-artifact consistency
- `FaultLocalizer`: identifies likely fault locations
- `ExecutionTraceAnalyzer`: captures runtime behavior for repair context
- `StaticAnalysisIntegrator`: incorporates compiler, type, and static-analysis findings
- `HistoricalFixRetriever`: retrieves prior successful repairs
- `RepairKnowledgeGraphManager`: maintains repair patterns and fix relationships
- `ContrastiveTestGenerator`: generates tests that distinguish correct from incorrect behavior
- `PatchCandidateGenerator`: produces candidate patches through multiple strategies
- `PatchValidator`: validates compilation, target tests, regression tests, and contrastive tests
- `PatchRanker`: ranks validated patches with heuristic and semantic evidence
- `MultiHunkRepairCoordinator`: coordinates cross-file and multi-location repairs
- `RuntimeErrorDiagnoser`: detects and classifies runtime failures
- `SecurityVulnerabilityFixer`: repairs security-relevant defects
- `RepairPromptComposer`: composes structured repair prompts
- `RegressionTestValidator`: checks behavioral regressions
- `RepairMetricsCollector`: records repair-pipeline evidence for self-improvement
- `SemanticPatchValidator`: checks intended semantics beyond test passing

The substrate also imports methodology metrics roles from the internal agent-programming methodology, atomic prompt orchestration roles from `atomic-prompts.md`, and secure pipeline controls from `secure-agent-builder-pipeline.md`.

## Formal Model Summary

Let `P` be the current program or agent repository, `sigma` its specification, `F` the observed failure or improvement request, `G` the generator or repair pipeline, `C` the Consullo coding constraints, `V` the validation suite, `Phi` learned or specified semantic invariants, `Prov` provenance evidence, and `Perm` Thesis 1 and Thesis 5 permission state.

The simplified acceptance rule is:

```text
AcceptPatch(P', P, sigma) iff
  Compiles(P')
  and TestsPass(P', V)
  and SemanticInvariantsHold(P', Phi)
  and RegressionRiskWithinBounds(P', P)
  and SecurityPolicySatisfied(P')
  and ProvenancePresent(Prov, P', P)
  and PermissionSatisfied(Perm, P', sigma)
```

The repair-pipeline recurrence is:

```text
RepairPipeline_{t+1} =
  Improve(RepairPipeline_t, accepted_patches, rejected_patches, incidents, metrics)
```

This recurrence is what makes the software substrate relevant to recursive self-improvement. The pipeline that repairs agents can itself become an object of validated improvement. The authoritative full rule is maintained in `appendix-formal-models.md` Model 4.

## Literature-Grounded Extension

Automatic program repair research supplies the cautionary background. GenProg-style and test-suite-based repair showed that plausible patches can pass tests while overfitting incomplete specifications. SemFix and Angelix show the value of semantic constraints and synthesis. Modern coding agents such as SWE-agent and AutoCodeRover show that LLMs plus repository navigation, search, and issue context can solve real software tasks, while SWE-bench-style evaluations expose the importance of realistic benchmarks.

Consullo's distinctive claim is not merely that an LLM can produce patches. The broader specified claim is that a self-modifying agent ecosystem should combine generation, repair, verification, provenance, staged deployment, trust gates, and method-memory learning into one substrate. This is more ambitious than ordinary coding-agent benchmarks and therefore requires narrower claims until demonstrated by evidence.

Recent systems work provides encouraging external evidence for the substrate's central bet. The ADRS study ("Let the Barbarians In: How AI Can Accelerate Systems Performance Research") reports ten case studies in which open-source evolutionary LLM frameworks (OpenEvolve, GEPA, ShinkaEvolve) matched or exceeded human state-of-the-art on real systems-performance problems — for example a 13x faster expert-parallelism load balancer and roughly 35% scheduling cost savings — at a cost of a few hours and tens of dollars per task (Let the Barbarians In: How AI Can Accelerate Systems Performance Research, arXiv:2512.14806). Two lessons transfer to Thesis 4. The first is a domain-selection principle: these results held precisely because systems-performance problems admit cheap, objective, hard-to-game verifiers — a candidate can be run against predefined workloads and measured against a baseline — and the targeted code (a scheduler, balancer, or allocator) is small and interpretable. Consullo should therefore weight its self-modification lanes toward problems with reliable, inexpensive verifiers; this is also the cheapest way to satisfy the persistent-external-grounding condition that keeps a self-improving loop out of the collapse regime (`../../self-improvement/recursive-self-improvement-limits.md`). The second is that such systems repeatedly imported techniques from unrelated fields — apportionment from political science, Condorcet/Borda voting from social choice, Kirchhoff's law and gradient control from physics, UCB from reinforcement learning — to beat domain specialists, which both supports the cross-field-transfer leverage Consullo already tracks and underscores that the verifier, not the generator's domain pedigree, is what makes the result trustworthy.

## Seed AI Relevance

The software substrate turns Seed AI from advisory reasoning into executable change. If Thesis 1 proposes an agent improvement, Thesis 4 supplies the machinery to instantiate it as code, tests, method memories, repository artifacts, deployment configuration, and monitoring hooks. If Thesis 5 blocks the change, Thesis 4 must honor that block. If Thesis 3 recommends an experiment, Thesis 4 can generate the instrumentation. If Thesis 2 supplies cognitive decomposition, Thesis 4 can translate parts of that decomposition into atomic prompts and compiled workflows.

The substrate's current status is not graded in this public edition. Many repair agents and secure-pipeline controls are proposed or specified, while the implementation-evidence appendix is withheld pending owner re-verification. Semantic validation, validator non-regression suites, provenance proofs, and staged deployment remain gaps. This thesis therefore does not treat the full substrate—or any component whose grade depended on the withheld appendix—as implemented.

Java repair is the first exploitation lane for organizational RSI, not the whole Seed AI process. A repair that compiles, passes tests, and preserves provenance is valuable substrate evidence, but it does not by itself demonstrate research-organization improvement. The organizational claim begins when substrate lessons transfer across lanes, such as improving evaluator rubrics, pre-registration templates, method-memory reuse, benchmark design, or portfolio decisions under protected-set non-regression. Semantic validation and staged deployment remain necessary, but not sufficient, for organizational-RSI claims.

## Recursive Self-Improvement Contribution

This thesis contributes to recursive self-improvement in three ways.

First, it makes code and agent construction repeatable. A replayable AgentBuilder pipeline can turn improvement proposals into comparable artifacts rather than one-off manual edits.

Second, it makes repair evidence reusable. RepairMetricsCollector, HistoricalFixRetriever, RepairKnowledgeGraphManager, and method-memory updates convert repair history into future repair capability.

Third, it makes the repair and generation pipeline itself improvable. Prompt templates, validators, test generators, static-analysis selection, patch-ranking rules, and semantic invariant classes can all be modified under Thesis 1 acceptance semantics. This is the substrate-level version of recursive capability amplification.

## Risks, Constraints, And Governance

The first risk is plausible-patch overfitting. A patch may pass available tests while violating intended semantics. Contrastive tests, semantic validation, post-verification, property checks, and deployment monitoring reduce this risk but do not eliminate it.

The second risk is authority leakage. Generated agents may request capabilities, data access, network egress, or tool privileges beyond their intended scope. Secure pipeline manifests, runtime capability tokens, scoped trust, and Thesis 5 default-deny rules are mandatory controls.

The third risk is provenance failure. If a generated artifact cannot be traced to its specification, prompt, model, validator, tests, permission state, and deployment outcome, it cannot safely participate in recursive improvement.

The fourth risk is validator monoculture. If the same model family generates code, tests, semantic checks, and repair judgments, shared blind spots may create false confidence. Multi-model critique, independent static tools, deterministic checks, and human or AAF escalation are needed for high-stakes cases.

The fifth risk is cost growth. An overly elaborate repair pipeline can become more expensive than manual intervention or simpler replacement. Cost per accepted repair must be measured and fed back to Thesis 1.

## Specialized Summary

A Self-Modifying Software Substrate With Acceptance Gates defines the executable layer of Consullo Seed AI. It connects AgentBuilder, LLM-Native Functional Java, atomic prompt decomposition, automated repair, post-verification, secure build pipelines, provenance, and staged deployment into a constrained substrate for system change. Its promise is not autonomous coding without oversight. Its promise is that software modification can become measurable, replayable, auditable, repairable, and recursively improvable. Its main weakness is that code can appear correct under incomplete evidence. For that reason, this thesis treats tests, semantics, provenance, permission, trust, and monitoring as parts of the software substrate itself.