01 / BROKEN
The network is wired wrong.
The fracture node is disconnected and the output bypasses it. Houdini warning indicators remain visible in the original capture.
FAIL
PERSONAL R&D PROJECT — V1 MILESTONE
WHAT IF AI
COULD WRITE
HOUDINI CODE
— AND HOUDINI
COULD SAY
“THAT’S WRONG”?
I built an experimental system that gives AI a Houdini task, runs its work in real Houdini, detects failure, feeds back evidence, and verifies the repair.
AI proposes.
Houdini decides.
THE CONTROL LOOP 01—06
REAL DCC FEEDBACKDETERMINISTIC GATE
01 / THE IDEAIN 10 SECONDS
Looks right
can still be wrong.
AI can generate Houdini code that sounds plausible but does not match the real scene.
A node type, parameter, connection, or API may look reasonable in text and still be invalid in Houdini. This system treats Houdini itself as the execution authority.
AI PROPOSES↓HOUDINI EXECUTES↓VALIDATION CHECKS↓REPAIR → REGRESSION → VERIFIED
02 / WHY THIS PROJECTSHORT ORIGIN
From procedural work
to a systems question.
I started exploring this while learning Houdini and working through the technical complexity behind procedural and simulation workflows. Python became a way to automate and inspect parts of that work; AI became another tool for exploring Houdini development.
That led to a bigger question: could AI do more than generate Houdini code? Could it develop, test, diagnose, and repair a Houdini system while Houdini itself remained the authority? That question became Autonomous Houdini Developer.
03 / REAL RBD RUNFAILURE → REPAIR → PROOF
AUTONOMOUS RBD DEVELOPMENT · 03 OCT 2026
A small network.
A real engineering loop.
The task: build a fracture network from Box through RBD Material Fracture to Null. The candidate ran in Houdini, but its wiring was wrong. The validator caught it; a minimal repair restored the intended structure.
These supplied captures document related RBD development and repair runs. Their original run identifiers and evidence are preserved in the screenshots; the canonical V1 release run is identified separately below.
02 / DIAGNOSE → REPAIR
Inspect the cause. Change only the links.
The diagnosis identifies the direct Box-to-Null bypass and the missing fracture input. The patch reconnects the existing nodes in the candidate file.
PATCH APPLIED
03 / RUN AGAIN
Execute the repaired candidate.
The terminal capture records a separate successful RBD development run. The run ID and result values are retained exactly as shown in the supplied screenshot.
VERIFIED · PASS
04 / VERIFIED HOUDINI RESULT
Now the intended network cooks.
The final scene shows source_box → rbd_material_fracture → RBD_OUTPUT, with the fractured geometry visible in the viewport.
05 / DETERMINISTIC PROOF
Check the result, not the model’s confidence.
Concrete validation records show the required nodes, cooked geometry, multiple RBD pieces, a name attribute, Houdini version, and geometry counts. This evidence image is from its own recorded repair run.
VALIDATION · PASS
Inspect the run evidence
04 / THE SYSTEM UNDERNEATHENGINEERING
That simple loop has a real system behind it.
The architecture below maps to V1 implementation components. The run starts from a task adapter and a seeded candidate; optional planning/development-agent hooks exist in the orchestrator.
INPUTRBD task adaptergoal · expected result
COORDINATIONV1 orchestratorrun workspace · retry limits
WORK AREAIsolated candidateseed · backup · snapshot
EXECUTIONHoudini executorreal Hython process
AUTHORITATIVE CHECKDeterministic validatorexpected vs observed
OBSERVATIONHoudini inspectornodes · links · parameters · geometry
DIAGNOSISAI repair agentevidence-guided diff
GUARDSPatch preflight + appliertarget · syntax · staged apply
RECHECKRegression runnerHoudini execution per case
FINAL GATECandidate verifiervalidation + regression + hash
PROVENANCERun evidenceresults · SHA-256
Hython: run it for real.
Means Houdini’s Python environment executes the candidate.
How The executor launches Hython and records structured results.
Why Plausible text is not proof that Houdini accepts or cooks a network.
Candidate: isolate the change.
Means The repair target is a run-scoped working copy.
How Code Manager constrains candidate roots and writes, and supports backups and snapshots.
Why Experiments stay bounded and the baseline is not the repair surface.
Inspector: see scene state.
Means Give the repair loop facts about Houdini’s network.
How A read-only inspector reports node types, connections, parameters, and geometry.
Why Diagnosis can be grounded in observed state rather than guesses.
Preflight + applier: constrain the edit.
Means A patch must pass local checks before it changes the candidate.
How Preflight checks target file, syntax, inspected parameters, and validator protection; applier stages and compiles Python edits.
Why A plausible repair should not gain a wider mutation surface.
Validation + regression: test the result.
Means Compare actual Houdini state with the task contract, then repeat configured checks.
How Deterministic validation compares expected and observed values; Regression Runner executes each configured case in Houdini.
Why A local repair must preserve the behavior the task requires.
Verifier + hash: record acceptance.
Means A final status with traceable evidence.
How Candidate Verifier requires immediate PASS and complete configured regression PASS, then captures a SHA-256 candidate snapshot with evidence.
Why Acceptance is reviewable later; the hash is provenance, not a Git replacement.
05 / SAFETY + HALLUCINATION DEFENSEBOUNDED MUTATION
The model can be wrong.
The system expects that.
Generated Houdini changes may invent an API, choose an unknown parameter, or alter the wrong file.
V1 does not eliminate model error. It puts checks around where a proposal can go and makes Houdini execution and deterministic validation authoritative.
PROTECTED BASELINE ↓
ISOLATED CANDIDATE RUN-SCOPED WORKSPACE + BACKUP
PATCH PREFLIGHT ↓
REAL HYTHON EXECUTION INSPECTED SCENE STATE
VALIDATION + REGRESSION ↓
CANDIDATE VERIFIER STATUS + HASH + EVIDENCE
- Isolated candidate workspaceCandidate paths and file writes are constrained by the code manager.
- Inspection and schema checksUnknown parameter names are rejected against inspector output.
- Patch and syntax checksUnified-diff contracts and Python syntax are checked; application stages changed files first.
- Protected validatorPreflight rejects repair changes targeting the RBD validator.
- Bounded repair and evidenceRejected patches can be retried with feedback; run results and verification are recorded.
- Not a perfect hallucination fixPassing one bounded task does not establish correctness for arbitrary Houdini work.
06 / FAILURE LABIMPLEMENTATION STATUS
Failure Lab injects controlled defects into a candidate, backs it up, and records hashes. It does not execute Houdini or perform repairs.
BROKEN_CONNECTION
Disconnects Box from Fracture and routes Box directly to Null.
INVALID_PARAMETER
Changes the existing singlepass parameter to a value that violates task expectation.
MISSING_INPUT
Category exists; injector raises NotImplementedError.
BROKEN_OUTPUT
Category exists; injector raises NotImplementedError.
REGRESSION
Category exists; injector raises NotImplementedError.
07 / VERIFIED RUNSUMMARY → DETAIL
RUN ID
20261003T171742Z_Autonomous_RBD_Development_4983b2e6
V1 RELEASE RUN · PASS
IMMEDIATE VALIDATIONPASS
REGRESSIONPASS · 1 / 1
CANDIDATE VERIFICATIONVERIFIED
Show candidate fingerprint and evidence fields
FINAL CANDIDATE · SHA-256
306c6a6c3389030927ec713a36866c3fd4c1ec71ff0a89bce6ffb023b6c08ccbRegression: 1 passed · 0 failed · 0 inconclusive. The verifier records VERIFIED only after immediate validation and the configured regression suite pass.
A focused proof record, not a claim that every Houdini workflow has been solved. Download sanitized run summary ↗
08 / TEST BASELINEESTABLISHED PROJECT RESULT
18 / 18PASS
Previously established baseline · 0 failed
Tests cover orchestration, candidate workspaces and code management, patch application, validation and regression, candidate verification, Houdini execution and inspection, RBD development, repair, and AI routing/diagnosis.
The complete suite was not rerun in this environment. Eighteen tests are a bounded baseline; they do not establish support for all Houdini workflows.
09 / PROJECT STATUSPERSONAL R&D
V1 demonstrates
- Bounded Houdini / RBD development and repair
- Real Houdini / Hython execution
- Deterministic validation and Houdini inspection
- Constrained repair and regression
- Candidate verification, evidence, and provenance
V1 does not establish
- Universal Houdini autonomy or all workflows
- Production deployment or multi-DCC autonomy
- Complete Failure Lab coverage
- Broad Pyro / VDB capability
- Public availability
10 / RESEARCH ROADMAPFUTURE DIRECTIONS · NOT PROMISES
Autonomous development loop
Bounded RBD task, repair, validation, regression, verification.
Repeatability + robustness
Explore longer runs, broader regression, provider failure recovery, reliability, and robustness testing.
Broader Houdini domains
Explore Pyro, VDB, more Failure Lab cases, generated tests, stronger planning, version awareness, and larger regression suites.
11 / WALKTHROUGHDEMO VIDEO
▶
DEMONSTRATION VIDEO PLACEHOLDER
TASK · FAILURE · INSPECTION · REPAIR · REGRESSION · VERIFYACTUAL VIDEO NOT YET SUPPLIED MP4 READY
When the real demonstration is ready, place it at media/demo.mp4 and replace this placeholder with a native video element.
12 / PORTFOLIO CONTEXTOTHER PROJECTS
One project in a larger body of work.
This page stays focused on Autonomous Houdini Developer. Other tools and projects will have their own pages and stories.