Faultline
Can an agent fix an ML pipeline without quietly invalidating the experiment? Faultline turns five realistic failure classes into versioned tasks with hidden graders, reproducible run manifests, and explicit infrastructure outcomes.
Applied ML / research engineering
I’m Daniel, a physicist turned founder and applied ML engineer. I turn ambiguous questions into training and evaluation experiments, then build the systems that carry useful models into production.
01 / SELECTED WORK
Recent work starts with an uncomfortable question: how could this result be wrong? I turn that question into a test, build the surrounding system, and keep the failure visible long enough to learn from it.
Can an agent fix an ML pipeline without quietly invalidating the experiment? Faultline turns five realistic failure classes into versioned tasks with hidden graders, reproducible run manifests, and explicit infrastructure outcomes.
A trained, one-output LightGBM model becomes dependency-free Python, C++17, or JavaScript. Executed and compiled tests compare every target against LightGBM raw scores at 1e-12 tolerances.
At Perfsy, I work on ML-driven performance optimization—designing experiments, evaluating model behavior, building data workflows, and carrying what works into the product.
Namelor taught me what “end to end” actually costs. I handled the product decisions, interface work, backend architecture, and deployment—the useful and unglamorous parts alike.
Could a machine help an architect think without flattening the creative process? Casabauhaus was my attempt to find out. I built and tested AI-assisted design tools around that tension.
02 / HOW I WORK
model.fit().The dataset is messy. The metric lies. Latency enters the room. I like that part: finding the failure, tightening the loop, and turning a promising model into software people can rely on.
Start with a question. Build the dataset, run the experiment, and keep honest notes.
Write the test that could prove the idea wrong. Read the misses, not just the mean.
Give the model dependable data, inference, monitoring, and deployment paths.
Put it in front of a real user and stay close enough to see what breaks.
METHODS + TOOLS
03 / ABOUT
I studied matter at its smallest scales. Then I started companies. Both taught me the same thing: a good answer begins with a better question.
I’m Daniel. I studied condensed matter physics at UC San Diego, then chose the less tidy education of founding software companies.
I have spent the years since moving between equations, code, product decisions, and users. I’m happiest with a hard problem, a fast feedback loop, and teammates who care more about getting it right than looking right.
04 / CONTACT
If you are training or evaluating models, building the systems around them, or turning research into a product, I would like to hear what is hard.