Cogitan

About

We build AI
that engineers trust.

Most AI is built for the easy case — consumer prediction, content ranking, recommendation. We build for the hard case.

Engineering domains have constraints that most ML systems ignore: physical laws that predictions must respect, calibration requirements that rule out overconfident point estimates, and stakes that make a wrong answer expensive in ways that a 95% accuracy headline doesn't capture.

We started with superconducting circuit verification because it concentrates these constraints sharply — RSFQ design is slow not because engineers lack compute, but because the simulation-based verification loop wasn't designed for design-space exploration, and nothing existed to fill that gap.

Fluxus is the result of taking that problem seriously. The same seriousness applies to whatever we build next.

01

Calibration over confidence

We care more about honest uncertainty than impressive accuracy headlines. A model that knows when it doesn't know is safer than one that doesn't.

02

Physics-aware by default

Surrogates that ignore the underlying physics extrapolate badly. We embed physical constraints into architecture and training objectives from the start.

03

Differentiable for optimization

Verification is only half the problem. A learned model that you can backpropagate through enables optimization workflows that simulation can't support.

04

Trained on your process

General models are seductive but wrong for precision engineering. Every client's surrogate is trained on their data, their cell library, their process rules.

What we are not

We are not a general-purpose AI platform. We are not building foundation models. We are not a consulting firm that wraps existing models in a thin domain layer.

We are a small team building deep, specific tooling for engineering problems where the existing software stack has a real and measurable gap. We care about the physics. We care about the uncertainty. We ship things that work.

Work on hard problems.
Care about getting them right.

If that sounds like you — or if you have an engineering problem that deserves this kind of attention — reach out.

Contact us