Inspiration
What if a machine could figure out what went wrong by observing the consequences?
My interest in this question began with causal representation learning (CRL), which studies how to recover hidden causal variables from high-dimensional observations. Mathematically, I can describe this as
$$ X = g(Z) $$
where (Z) represents latent causal variables, (X) represents observations, and (g) is the unknown mapping between them.
The central challenge is identifiability: can I recover the underlying causal explanation uniquely, up to unavoidable symmetries, or could multiple different models explain the same observations?
My mathematical research explores algebraic matroids, Jacobian rank, and intervention design as ways to characterize identifiability. I wanted to investigate these ideas through three physical and computational settings: a drawing robot learning its own geometry, a circuit diagnosing a hidden fault, and a finance assistant reasoning from incomplete physical evidence.
What it does
Causal Machines brings together three demonstrations.
- The drawing robot uses camera input to guide a physical two-servo arm as it draws on an iPad. Its learning system compares the predicted pen position with where the pen actually lands and corrects its geometric model.
- Fault Doctor diagnoses a broken logic circuit from its inputs and outputs. It selects the next test using information gain, eliminates inconsistent explanations, and identifies faults that cannot be distinguished from one another.
- Flow Ledger, built for Hyphenate's Autonomous Systems for Finance challenge, combines tanker movements, thermal activity, and official oil data. It provides a commodity analyst with an evidence trail and withholds estimates when observational coverage is insufficient.
The common mathematical problem is determining which hidden explanations remain consistent with the observations, and which additional experiments could distinguish them.
How I built it
Drawing robot — Learning a physical causal mapping
I built a two-servo linkage, Arduino control, camera-based pose estimation, an iPad drawing interface, and a learned model connecting servo commands to pen position.
For joint angles (\theta_1) and (\theta_2), the robot predicts a pen position through a forward model:
$$ \hat{\mathbf p}=f(\theta_1,\theta_2) $$
The camera measures the actual pen position, allowing me to calculate the prediction error:
$$ \mathbf e=\mathbf p_{\text{observed}}-\hat{\mathbf p} $$
The objective is to reduce the discrepancy between predicted and observed movement. One way to express this calibration objective is
$$ \mathcal L= \frac{1}{N}\sum_{i=1}^{N} \left| \mathbf p_i^{\text{observed}} - f(\theta_{1,i},\theta_{2,i}) \right|_2^2 $$
Instead of assuming the theoretical geometry perfectly describes the physical robot, I use observations of its consequences to improve its model through a draw–learn–redraw loop.
Fault Doctor — Causal intervention and information gain
I built a circuit model, an adaptive test selector, and a browser demonstration where a user can hide a fault and observe the diagnosis process.
I modeled the unknown fault as a hypothesis (F) and selected input interventions (x) that maximized expected information gain.
$$ x^*=\arg\max_x I(F;Y\mid D,x) $$
Equivalently,
$$ x^*=\arg\max_x \left[ H(F\mid D) - \mathbb E_{Y\mid D,x} \left[H(F\mid D,x,Y)\right] \right] $$
Here, (D) represents previous observations, (Y) represents the output of the next test, and (H) is Shannon entropy.
This allows the system to choose tests that most effectively eliminate possible fault explanations rather than exhaustively checking every input.
A more fundamental issue is observational equivalence. Two faults are indistinguishable if they produce identical outputs for every possible input:
$$ f_i\sim f_j \iff \forall x\in\mathcal X,\quad y(x,f_i)=y(x,f_j) $$
When this occurs, no additional input test can uniquely identify the fault. Instead, Fault Doctor reports the correct equivalence class, reflecting what the available evidence can actually establish.
Flow Ledger — Inference under incomplete observations
I built the finance data pipeline using Python, FastAPI, SQLite, and MapLibre, combining live AIS ship movements, NASA thermal detections, and EIA figures.
I treated tanker activity and other physical measurements as imperfect observations of an underlying economic system.
A useful distinction is between the physical quantity of interest, (Z_t), and the available measurement, (X_t):
$$ X_t=g(Z_t)+\varepsilon_t $$
where (\varepsilon_t) represents measurement noise and other unmodeled effects.
Importantly, observations may also be missing entirely. I therefore track data coverage:
$$ C=\frac{N_{\text{usable}}}{N_{\text{required}}} $$
If coverage is insufficient, the system abstains instead of extrapolating an unsupported estimate.
I also examined relationships between tanker activity and official oil figures. A correlation between two time series does not establish that one causes or predicts the other, particularly when both may be influenced by shared trends.
The mathematics connecting all three
My broader research focuses on causal identifiability through algebraic matroid theory.
For a parameterized observable map (\Phi(\theta)), I can study the Jacobian
$$ J(\theta)= \frac{\partial\Phi(\theta)}{\partial\theta} $$
and the rank of selected subsets of its rows:
$$ r(S)=\operatorname{rank}(J_S(\theta)) $$
For suitable algebraic models, generic Jacobian rank characterizes algebraic independence. This gives a combinatorial way to investigate which observations contribute independent information.
I am particularly interested in whether intervention selection can be formulated as a minimum-cost basis problem:
$$ S^*= \arg\min_{S\subseteq\mathcal I} \sum_{i\in S}c_i $$
subject to
$$ r(S)=r(\mathcal I) $$
where (c_i) represents the cost of an intervention.
However, full rank does not necessarily imply unique causal recovery. Algebraic dependence can leave multiple models compatible with the same observations. My proposed research therefore also investigates injectivity and model-separation conditions.
This matroid-based approach is a broader research direction, not a claim that I have already implemented a matroid optimization algorithm in all three demonstrations. The shared idea is that a machine should select informative evidence and understand when its observations cannot distinguish competing explanations.
Challenges I ran into
The physical robot made the problem concrete. I had to get the servos moving reliably, map camera observations to the arm's pose, and handle views obstructed by the links and Apple Pencil. A discrepancy between predicted and observed movement could come from calibration error, sensor noise, or limitations in the model itself.
Fault Doctor revealed a deeper mathematical limitation. Some circuit faults produce exactly the same outputs under every input, meaning they are not individually identifiable. I had to make the system distinguish uncertainty that can be reduced through further experiments from ambiguity that no possible experiment can resolve.
For Flow Ledger, a ship going silent could indicate missing AIS coverage rather than a meaningful change in physical activity. I also had to avoid interpreting correlations driven by common time trends as evidence of predictive or causal relationships.
Across all three projects, the hardest part was determining what the observations actually justified.
Accomplishments that I'm proud of
I built a physical arm that uses camera input to guide itself while drawing on an iPad. In separate simulation tests, my draw–learn–redraw approach reduced drawing error from approximately 1–4.5 mm to about 0.35 mm across five pictures and three robot builds.
Fault Doctor correctly identified the distinguishable class for all 1,051 modeled single-fault adder cases in simulation, using an average of only 10 tests out of 512 possible inputs. This demonstrated how selecting informative interventions can substantially reduce the number of experiments required.
Flow Ledger operated on real data. One live snapshot tracked 177 tankers, detected five large-tanker departures, and flagged 12 AIS gaps. With only 9% of the required seven-day coverage, it correctly declined to produce a flow estimate.
What I'm most proud of is that these systems recognize the difference between producing a plausible answer and producing one supported by evidence.
What I learned
The biggest lesson was that prediction is not the same as causal understanding.
In causal representation learning, a model can accurately reconstruct observations while failing to uniquely identify the latent variables responsible for them. Multiple hidden models may be consistent with the same observable data.
Each project exposed this issue differently. Fault Doctor encounters observationally equivalent hypotheses. The robot must account for imperfect calibration and obstructed measurements. Flow Ledger must separate genuine physical signals from missing observations and spurious correlations.
I also learned the importance of intervention design. Fault Doctor uses information gain to choose its next experiment, while my theoretical research asks whether algebraic matroid structure can characterize small sets of interventions sufficient for identifiability.
The central principle connecting my work is that autonomy requires knowing not only how to make an inference, but whether the inference is identifiable from the evidence available.
What's next for Causal Machines
I want to measure the physical robot's drawing accuracy and calibration over repeated real-world runs, test Fault Doctor on a physical breadboard, and improve Flow Ledger with more complete daily coverage and an independent source of port activity.
I also want to continue my research into matroid-guided causal identifiability and intervention design, investigating whether Jacobian-rank computations and model-separation conditions can provide verifiable criteria for when a causal representation can be recovered.
Ultimately, my goal is to build machines that can explain their conclusions, show which observations support them, choose informative experiments, and recognize when another test is necessary.
Log in or sign up for Devpost to join the conversation.