Creative technologist, bridging creative and engineering. I design, build and consult on AI workflows and systems for studios, agencies, production companies and image‑led brands.
Liquid Light Engine is a specification-led system for generating photographic material worlds. It separates material physics, visual language and image intent, then carries selected specifications through validation, compilation and rendering.
Physical and aesthetic constraints are established upstream rather than renegotiated for every image. This provides a stable framework for directing the search, evaluating its results and developing selected materials further.
Ten laws govern thickness, reflection, viscosity, trapped air, light, depth and finish. Derived through material research, comparative rendering and regression testing, they define the conditions required for consistent physical behaviour. The core is hash-verified; any drift stops the system at load.
The visual language is encoded as a sealed profile governing lighting, tonal structure, framing, reflection behaviour and exclusions. Different profiles can establish radically different image conditions while the underlying material physics remains fixed.
Selected material worlds are formalised as specifications and stored in collections. Once approved and entered into the ledger, a material becomes part of the working library, where it can be retrieved, adapted or used as the basis for further development.
The authoring stage establishes the material intent. A specification may be developed through the system's Claude skill, derived from a brief, retrieved from the library or supplied directly. In every case, the pipeline begins with structured material data rather than an open image prompt.
"material": {
"opacity_mode": "opaque-dark" }
"energy": {
"viscosity": 9, "state": "churn" }
"reflections": { "regime": "dual" }
"tonal": {
"composition_note": "focal-event" }
The specification holds the material hypothesis and every behaviour that must survive translation. It is data before it is prose.
The Compiler translates one selected specification into continuous render language. Position carries weight; exclusions are assembled only for that world’s actual failure modes.
custom_nodes/
└── ComfyUI-LLE-Engine/
├── LLEProfileLoader
├── LLECollectionPicker
├── profiles/
├── collections/
└── example_workflows/LLE_default.json
Copy the pack into ComfyUI and restart. The engine bundles its Python requirements; the flagship canvas arrives pre-wired.
/lle-spec-author one world, inside a sealed profile /lle-new-aesthetic a whole taste, onboarded and sealed
Specifications are not typed, they are authored — against the active profile, by instruments built for that job: one for a single world, one for onboarding an entire new taste. The system's first stage is a tool, not a prompt box.
Validation is not engineering bolted onto a picture practice. Photography is already the study of why something looks the way it does; a system built out of that has to be able to prove itself wrong somewhere measurable. Three places hold that.
The rules were not authored in advance. Core prompt candidates were proposed against a scored baseline, graded, and promoted only when they beat it on verdict accuracy without regressing the guard cases. Profile laws carry the specific failure that earned them: no rule without a recorded corpse.
98.9% verdict accuracy on a 31-case labelled core-tier set, measured across three runs with Opus 4.8 as the certification instrument. Certification is bound to that exact prompt, model and settings; production runs on Gemini 3.1 Pro. The validator judges specification text, never image quality.
A profile is sealed to the exact physics core it was certified against — the seal is a hash of the assembled manifest. Load it on a different core and the system still runs, but reports the profile as uncertified until it is proven again. Taste is portable; the claim that it was proven is not.
A specification is written to survive translation, so it need not end at an image — handed to an agent, the same document should be able to build the material as a CG shader. And the worlds that never shipped are still specifications: kept, they become a library to draw a starting point from on a job. Neither exists yet.