SvelaroRoot-cause analysis on plant dataBy Angelo ZilettiSeptember 2026
What plant data can reveal about root causes, and what causal methods add
Plants record almost everything, yet finding what drives a yield or quality problem still
depends on experience. We took three public industrial datasets whose true causes are known,
ran six methods on each, and asked two questions: can the data reveal the drivers at
all, and how much of that does a method actually hand to the engineer?
In short
The data sets the ceiling. Whether a historian can answer a root-cause
question at all depends on whether the plant moved while it was recording, not on how much
data it holds. How much of that answer reaches the engineer is then up to the method.
Three datasets, three ceilings. The cryoplant held three steady operating
points for eight days and gives up only one of its three documented causes. IndPenSim moves
constantly but holds too few independent observations for its 22 variables at fine resolution.
Tennessee Eastman is informative, with a sharp limit: when the true cause accounts for less than
3% of the target’s movement, ten of nineteen problems, no method ranks it first.
Above the limit, the methods separate. Correlation and Granger hand back nearly
every variable, so the true cause is on their list but almost never at the top, and an engineer has
two dozen variables to check. The causal methods return short lists but are far from equal:
DYNOTEARS returns nothing, PC rarely puts the true cause first, and PCMCI+ and Svelaro Causal Search
(SvelaroCS) put it first in a third and two thirds of the problems, from lists of about five and two
variables.
A wrong answer can point backwards. On IndPenSim, correlation and Granger
return 5 to 7 of the 7 variables the target itself produces, as if they were causes; the causal
methods return at most two. On Tennessee Eastman, the misses of PCMCI+ and SvelaroCS mostly land
within two steps of the true cause, those of correlation and Granger across the plant.
Ask the historian three questions first. Did the plant move while recording,
is any stretch long enough to model, and is there enough independent data for the variables
involved? The steadiest period is the least informative.
Disclosure: the author is the founder of Svelaro, whose method SvelaroCS is one of
the six compared. All six ran on identical data with settings fixed in advance.
When yield drops, the data that explains it is usually already on disk. Every flow,
temperature, pressure and valve position has been logged by the historian for years. In
practice, though, finding the cause still comes down to the people who know the plant best,
because the standard analysis answers a slightly different question.
That analysis ranks process variables by how strongly they move with yield.
On a plant, that ranking is crowded. Control loops, recycles and shared utilities tie units
together, so when one thing changes, many others follow. Almost every variable ends up moving
with yield, and the ranking fills with variables that follow the problem rather than
cause it.
All three variables move with yield, so a correlation ranking lists all three. Only the feed
rate changes it. Adjusting the pump speed does nothing, and trying to raise off-gas CO₂ to
raise yield has the arrow backwards. (Illustration; the variable names are generic.)
Adjusting a variable that only moves with yield will not improve it. That is
why root-cause work is a causal question, and why causal discovery (methods that try to separate variables that drive an outcome from variables that merely follow it) is attractive for process data.
Before comparing methods, though, there is a question that is rarely asked:
can this particular historian reveal the drivers at all? A method cannot find
what the data does not contain. Until that limit is measured, a poor result cannot be told
apart from an impossible problem. This post measures both: what the data allows, and how much
of it each method recovers.
02 · Data and methods
Three datasets where the true causes are known
A method can only be judged where the right answer is known in advance. We used three public
industrial datasets that each come with their cause-and-effect structure, and that together
cover what a plant historian can look like: a disturbed continuous process, a batch process
under industrial control, and a real plant held steady.
Simulation · chemical plant
Tennessee Eastman
The process industry’s reference simulation of a chemical plant [1],
on which fault detection and diagnosis methods have been compared for three decades. We use
the widely distributed run set of normal operation plus 21 faults [2]:
twenty disturbances defined by Downs and Vogel, and a twenty-first added by Russell et al.
[3]. This is not the usual use of the benchmark. The faults only make the plant move; they are not the
answers. The answers come from a published mechanism graph [4]: every variable with exactly one documented direct cause in the graph becomes one root-cause problem, with that variable as the target, its cause as the answer and 26 other variables as candidates. Twenty variables qualify; one, the pilot on which the time resolution was set, is left out (see the method notes), so nineteen problems. The methods never see the graph.
Problems
19 targets
Documented causes
1 per target
Candidates
26 measured variables
Runs
22 (normal + 21 faults)
Simulation · batch bioprocess
IndPenSim
A realistic simulation of industrial penicillin production [5],
released as a set of 100 batches run under three control strategies: a fixed recipe, operator control and automatic feedback control [6], [7].
Because it is built from known equations, both the causes and the consequences of
the production rate are known, which lets us see whether a method mistakes one for the other.
Target
penicillin production rate
Candidates
22 variables
True causes
15
Consequences
7, known from the equations
Operating plant · cryogenics
ESS accelerator cryoplant
An operating plant: recordings from the cryoplant of the European Spallation Source in Lund,
published with a causal graph drawn by the plant’s experts over its subsystems
[8], [9]. The plant was run at three settings and held at each, which is how many plants run for long stretches.
The expert graph is drawn between 23 subsystems, not tags (the individual recorded process variables). We chose two target tags and took the
subsystems the graph names as their causes; a returned tag counts by the subsystem it belongs to.
Duration
7.9 days, in 3 periods
Readings
68,488 at 10 s
Candidates
151 for the first target, 221 for the second
Targets
2 (one with 3 documented causes, one with 1)
Six methods: two standard, four causal
We ran the same six methods on all three datasets. Two are what a plant analytics team typically reaches for; four are causal discovery methods.
Standard methods
CorrelationRanks every candidate by how strongly it moves with the target.
The baseline most root-cause dashboards are built on.
Granger[10]Asks whether a variable’s past
improves the prediction of the target. It adds time order to correlation, but it is still a
test of prediction rather than of cause.
Causal methods
PC[12]The classic causal discovery algorithm. It removes a link
when it vanishes once other variables are accounted for; it treats every reading as independent and ignores time order. It returns a set of variables with no order.
DYNOTEARS[13]A causal discovery method for time series that fits
current and lagged effects in one optimisation, with a penalty that keeps the network sparse.
PCMCI+[11]A widely used causal discovery method for time series. It keeps a variable only if it still predicts the target once the other candidates are accounted for. Run here with its standard partial-correlation test.
Svelaro Causal Search (SvelaroCS)Nonlinear cause–effect modelling for one chosen
outcome: it searches only for the causes of the target and decides for itself how many to
report.
One scoring rule for every method. Each method delivers a list of identified causes, the list process engineers would take to the plant, and we compare it
with the true causes. The length of that list matters as much as whether it contains the
answer: every variable on it is one more thing somebody has to check on a running plant.
Because the true structure is published, we can also classify every wrong answer. Was the
named variable further upstream of the target, a consequence of it, or unrelated? That turns
“the method missed” into something an engineer can learn from, and it is where one
of the most useful results below comes from.
03 · The data decides first
Did the plant move while it was recording?
Before comparing any methods, we measured what each dataset can support. A causal method
learns from how variables move together when something changes. If nothing changes, there is
nothing to learn from, however many readings the historian holds.
Share of each variable’s variation that happens inside one operating condition
The same measurement on all three datasets: of all the variation a variable shows, how much
happens within one operating condition (a fault run, a batch, a setpoint period) rather than as a jump between conditions. The quantity is the movement share defined in section 06 (check 1).
The cryoplant barely moves. It ran at three settings and held each one, so
only 1% of its variation happens inside a setting; more than half of its tags change by
less than one per cent while a setting holds. Those tags behave like fewer than three
independent patterns, and over half of them have a near-identical twin elsewhere in the plant
(correlation above 0.99). The consequence is direct: of the three documented causes of the
temperature we analysed, only one is recovered, and that one alone accounts for 94% of the
target’s variation. The other two are not so much missed as left with nothing to explain: once the first cause is accounted for, what remains of the target’s variation is within the noise. Correlation and Granger reach further only by returning 126 and 37 of the 150 tags; PC, DYNOTEARS, PCMCI+ and SvelaroCS all find that one cause and neither of the others. The plant’s second target was analysed on a wider export of the same archive, 221 tags of
which 27 lie outside the expert graph, and it fares no better: no method places its single
documented cause among the first answers.
Correlation returns 191 of the 221 tags; Granger and DYNOTEARS return none; PC returns 25, PCMCI+ three and SvelaroCS one, none of them the cause.
IndPenSim moves constantly, with 97% of the variation inside each batch, and
fails for a different reason: too few independent observations. The process has a
memory of about three days, so thirty batches of roughly ten days each hold only about a
hundred independent looks at the process, not the thousands of rows the file contains. Asked to
weigh 22 variables over a day of history at 4-hour resolution, the analysis needs more
independent information than the data holds. Finer sampling adds no information, since
consecutive readings within a batch are nearly copies of each other, while coarser sampling covers
the same day of history with fewer lags, and every lag costs one term per variable. At 6-hour resolution it
fits, and the causal search goes from finding 4 true causes to finding 6.
Tennessee Eastman: informative, with a sharp limit
Tennessee Eastman is the rich case: its faults move the process, and half of the variation
happens inside a fault run. Even here there is a limit, and it belongs to each problem. For
each of the 19 problems we measured how much of the target’s movement its true cause
accounts for.
Share of the target’s movement the true cause accounts for (log scale)
Each row is one problem, written target ← true cause. When the cause accounts for less
than 3% of the target’s movement (ten of the nineteen problems), no method we tested
ranks it first.
Below 3%, none of the methods we tested could pick the cause out from the other candidates. Above it, most problems are solvable, with two instructive exceptions, X13 (the benchmark refers to its tags by number) whose cause accounts for 46% of its movement, and X8 at 7%. Both are defeated by stronger stand-ins: other variables that predict the target
better than its real cause does (X16 and X27 for X13; X7 and X4 for X8). The limit tells you
when a problem is hopeless; it does not promise success above it.
One caution: this measurement needs the true cause, so it can grade a benchmark but cannot be
run on a live problem. The checks you can run on your own historian, before knowing
anything, are in section 06.
04 · What each method hands over
The shortlist an engineer actually gets
Every method ends with the same artefact: a list of variables to go and check. On the nine
Tennessee Eastman problems above the limit, and on the penicillin process, here is what that
list contains.
Bar length is the number of variables an engineer must investigate; the green part is the true cause,
averaged over the nine problems on Tennessee Eastman and counted on IndPenSim. On IndPenSim the equations also say which variables are consequences of the
target (red). DYNOTEARS returned no variables on the problems shown.
Long lists contain the cause; short lists have to earn it.
On Tennessee Eastman, correlation and Granger return 24 and 22 of the 26 variables, so the
true cause is almost always somewhere in them. The causal methods differ sharply: DYNOTEARS returns nothing at all, PC returns about 4 and has the cause on its list in 4 of the 9 problems, PCMCI+ about 5 and in 5, and SvelaroCS 2 and in 7. Of every ten variables handed over, 0.4 are the true cause for correlation, which is exactly what picking at random would give, about 1 for PC and PCMCI+, and 5.4 for SvelaroCS.
A short list is only useful if it is short for the right reasons. The next figure
puts every method against that test: how many true causes it finds, compared with how many
it would find by picking the same number of variables at random.
The dashed diagonal is picking at random: check k of N variables and you expect to find k/N
of the true causes. A method earns its place only by sitting above that line, and the further above, the darker its point. Correlation
reaches every Tennessee Eastman cause only by standing in the corner where random picking
reaches them too; Granger falls below the line. DYNOTEARS sits at zero: it returns nothing. On IndPenSim, PCMCI+ returns five variables, all true causes, close to SvelaroCS’s six.
The same number of guesses for everyone
The fairest comparison gives every method the same budget: if an engineer checks only the
first k variables of each list, how often is the true cause among them?
Each cell counts the true causes a method has found after checking the first k variables of its
list; darker means further above picking k variables at random, shown in the red row. Pale cells mean the
list has already ended, so checking deeper adds nothing:
PCMCI+ stops at five variables on IndPenSim, SvelaroCS at six there and at two to three on Tennessee Eastman.
DYNOTEARS returns nothing on the problems shown. PC’s list has no order, so its values average over random orderings of the list.
At one guess each, correlation and DYNOTEARS are right on none of the 9 Tennessee Eastman problems, Granger on 1, PC on about 1, PCMCI+ on 3 and SvelaroCS on 6. Correlation needs five
guesses to reach five problems and never catches up. On IndPenSim the gaps are narrower: with 15 true causes among 22 candidates, random picking already does well, so the lead of PCMCI+ and SvelaroCS over it is smaller, although every variable on their lists is a true cause.
An acceptance test worth writing into a proof of concept. “Did it find
the cause?” is not a specification, because a method that returns everything passes
it. “Did it find more than picking the same number of variables at random?” is.
On Tennessee Eastman, correlation solves 0.6 more problems than random picking of its list size, PC 2.6, PCMCI+ 3.2 and SvelaroCS 6.3, while Granger solves 0.7 fewer and DYNOTEARS, returning nothing, solves none.
A note on the 15 IndPenSim causes: they are causes by the equations, but a cause only shows in the
data if it moved in these batches. One held steady by the controller is invisible to any method, as below the
3% limit on Tennessee Eastman, so no method should be expected to return all 15.
05 · How methods are wrong
Near misses and backwards answers
Because the true structure is published, every wrong answer can be placed on the plant’s
map. Three kinds of wrong matter differently to an engineer: an answer a step or two from the true
cause, an answer in the wrong part of the plant, and an answer that points backwards.
A near miss or a random miss
On the nine Tennessee Eastman problems above the limit, we sorted each method’s first pick
into three kinds: the true cause, a wrong variable close to it, or a wrong variable further away,
counting steps along the published mechanism graph.
Steps are counted along the published mechanism graph, in either direction. First picks come from each method’s returned list; PC’s list has no order, so its counts are
averages over random orderings. A variable picked at random from the same candidates lies within two
steps of the cause 11% of the time.
PCMCI+ names the true cause first in 3 of the 9 problems, and 5 of its 6 misses lie within two steps of the cause; SvelaroCS is right in 6, and 2 of its 3 misses lie within two steps. Those near misses point to the right unit,
the right loop, often the neighbouring instrument. PC and DYNOTEARS do not share this: PC is right in about 1
and misses mostly far away; DYNOTEARS names nothing.
Correlation and Granger are right in 1 of 18 attempts between them, and they miss by a median of
six steps, as far as a variable picked at random. Both count as a miss in any table of hit rates,
and they are not the same miss: one sends the investigation next to the cause, the other across
the plant.
Backwards answers
IndPenSim’s equations name seven variables that the penicillin production rate itself
creates, such as carbon dioxide evolution, oxygen uptake and generated heat. They are highly
visible precisely because production creates them: oxygen uptake correlates 0.63 to 0.68 with the
production rate inside every batch, more strongly than almost any true cause.
Consequences of the target returned, out of 7, fewest to most,
across the seven analyses of IndPenSim with more than 30 points per batch (three control
strategies, two or three time resolutions). An eighth, at 8-hour resolution, has 25 and fails
check 2; there SvelaroCS returned four.
Returning one of these is not a near miss. Raising oxygen uptake to raise
production has the arrow backwards; the production rate does not respond, and on a production
fermenter the lesson costs a batch. In every analysis with more than 30 points per batch, correlation and Granger return five to seven of
the seven, PC at most two, PCMCI+ at most one, SvelaroCS none, and DYNOTEARS returns nothing at all.
06 · Check your own historian
Three questions before any analysis
The three checks below need only the historian itself, no knowledge of the true causes, and each caught a real failure in this study.
Did the plant move while it was recording? Compare how much a variable moves inside an operating condition with how much it moves between conditions:
This is the share plotted in section 03. A condition is one operating period: in this study a fault run, a batch or a setpoint period; on a live plant a batch, a campaign or a stretch between setpoint changes. Readers who know one-way ANOVA will recognise the split: the numerator is the within-group variance, the extra term in the denominator the between-group variance. A share of a few per cent means the historian recorded a handful of steady states, not the plant responding. The cryoplant: 1%.
Is each stretch long enough to model? Count the points in each continuous stretch at the
resolution you analyse, and take the median over stretches. At 8-hour resolution a penicillin batch has
only 25 points. The analysis still runs, but its answers might no longer be reliable.
Is there enough independent data for the variables involved? Readings taken close together are nearly copies of each other, so a record holds far fewer independent observations than rows. Estimate that number from the target’s autocorrelation and subtract the terms the analysis has to estimate:
where is the number of points in a stretch, the target’s autocorrelation at lag (summed until it first turns non-positive), the number of candidates and the lags allowed. The 3 is the fixed cost of the test that judges each link: the standard error of Fisher’s z-transform for a partial correlation is , so the margin is what that test has left to work with. Below zero, the data cannot pin down every term.
Check
Tennessee Eastman
IndPenSim, 4 h
IndPenSim, 6 h
IndPenSim, 8 h
ESS cryoplant
1 · Did the plant move?
50%
97%
97%
97%
1%
2 · Long enough stretches?
54 per run
51 per batch
34 per batch
25 per batch
670 per period
3 · Enough independent data?
+327 to +946
−24
+12
+35
+823
What each method foundtrue causes beyond a random picktrue causes a random pick would also holdconsequences of the targetto check, fewer is betterthe full scale: every problem or candidate
Correlation
0of 9 first24.2to check
14 + 7of 21
14 + 7of 21
14 + 7of 21
3of 3 causes126tags to check
Granger
1of 9 first22.2to check
15 + 7of 22
15 + 7of 22
14 + 6of 20
2of 3 causes37tags to check
PC
1.1of 9 first4.1to check
2 + 2of 4
3 + 2of 5
5 + 1of 6
1of 3 causes2tags to check
DYNOTEARS
nothing
nothing
nothing
nothing
1of 3 causes1tag to check
PCMCI+
3of 9 first5.3to check
3 + 1of 4
5 + 0of 5
5 + 0of 5
1of 3 causes5tags to check
SvelaroCS
6of 9 first2.0to check
4 + 0of 4
6 + 0of 6
9 + 4of 13
1of 3 causes2tags to check
Check 3 shows independent observations minus the terms the analysis estimates (variables times
time steps); below zero, the data cannot pin them all down. The
line for check 2 near 30 points is drawn from this one dataset and should be treated as a rough guide. Below the checks, what each method found. Tennessee Eastman: problems, of the nine above the 3% limit, where the method names the true cause
first, and how many variables it returns per problem to do so. IndPenSim: bar length is the variables returned (of 22), green the true causes and red the
consequences of the target. Pale green is the part a random pick of the same number of variables would
also have held; solid green is what the method found beyond that.
Cryoplant, first target: documented causes found, and tags to check out of 150. Methods respond to the checks differently: SvelaroCS goes wrong at 8 hours, where check 2 fails, while PC and PCMCI+ barely change.
The steadiest period is the least informative. The stretch an engineer would
naturally pick (a clean, stable month with no upsets) is exactly the one that
cannot answer a causal question. The periods worth analysing contain changes: grade changes,
start-ups, disturbances.
The checks tell you when to stop, not when success is guaranteed. Tennessee Eastman passes all
three, and still ten of its nineteen problems have no recoverable answer (section 03).
07 · What it adds up to
What this means for root-cause work on a plant
Check the data before choosing a method. How much the historian can answer depends on whether the plant moved, how long each stretch is, and how much independent information it holds. Those checks need no knowledge of the true causes.
Judge a method by how many variables it hands over and how many of them are right. Ask how long the list is, how often the first variable is the true cause, how far the mistakes land, and whether it beats random picking of the same number of variables.
Where the data can answer, causal methods can earn their place, but they are not all equal. DYNOTEARS names nothing; PC returns short lists whose misses land far from the cause; PCMCI+ and SvelaroCS both return short lists and err close to the cause, ranking it first in a third and two thirds of the problems respectively.
Limitations. The method comparison rests on nine Tennessee Eastman problems and one penicillin process. On the cryoplant only one of the three documented causes could be recovered from the data at all, so that dataset separates the methods weakly.
PCMCI+ was run with its standard partial-correlation test, and PC and DYNOTEARS with standard settings; other tests or settings might change their numbers. None of this replaces a
process engineer; it tells that engineer where to look first.
Method notes
How the numbers were produced
Tennessee Eastman. Each variable with exactly one documented direct cause in the published mechanism graph is one problem: the variable is the target, its cause the answer, and the other 26 measured variables the candidates (the target itself is excluded). Twenty variables qualify. The first of them run, X20, served as the pilot on which the time resolution (51-minute bins, matched to its correlation time) was calibrated before the other nineteen were run, so it is left out and the comparison rests on nineteen problems at that resolution. The nine problems
“above the limit” are those whose cause accounts for at least 3% of the
target’s movement, measured within each run so that differences between runs cannot
inflate it.
Scoring. Every method is scored on the list it returns, in its own order. For PC and PCMCI+, a variable is on
the list when the method draws an arrow from it into the target, or a link between the two that it could
not orient; a link the method points away from the target does not count. PC returns a set with no
order, so its first picks and depth curves are averages over random orderings of the list. List
lengths are averages per problem; per-ten precision averages each problem’s own share of true
causes over the problems where a list is returned.
Distances and chance. Steps are shortest paths in the published mechanism
graph, ignoring direction. Random baselines draw uniformly from the same candidate lists.
IndPenSim. Each control strategy is analysed separately; the figures in section 04 use the automatic-feedback-control batches at 6-hour resolution, the analysis that passes all three checks.
ESS cryoplant. The expert graph is drawn between subsystems, so answers are scored at subsystem level. The two targets are separate analyses, each with its own candidate pool drawn from the same archive, 151 tags and 221; within each, all six methods saw the same tags.
Settings. Each method’s settings were fixed for each dataset before any scoring. PCMCI+ used its standard partial-correlation test, PC a significance level of 0.05, and
DYNOTEARS penalties of 0.05 and a weight threshold of 0.3 on standardised variables.
Sources
References
J. J. Downs and E. F. Vogel. A plant-wide industrial process control problem.
Computers & Chemical Engineering 17(3):245–255, 1993.
doi:10.1016/0098-1354(93)80018-I
L. H. Chiang, E. L. Russell and R. D. Braatz. Fault Detection and Diagnosis in
Industrial Systems. Springer, London, 2001.
doi:10.1007/978-1-4471-0347-9
E. L. Russell, L. H. Chiang and R. D. Braatz. Fault detection in industrial processes
using canonical variate analysis and dynamic principal component analysis.
Chemometrics and Intelligent Laboratory Systems 51(1):81–93, 2000.
doi:10.1016/S0169-7439(00)00058-7
G. Menegozzo, D. Dall’Alba and P. Fiorini. CIPCaD-Bench: Continuous Industrial
Process datasets for benchmarking Causal Discovery methods. IEEE 18th International Conference
on Automation Science and Engineering (CASE), pp. 2124–2131, 2022.
doi:10.1109/CASE49997.2022.9926420
S. Goldrick, A. Ştefan, D. Lovett, G. Montague and B. Lennox. The development of an
industrial-scale fed-batch fermentation simulation. Journal of Biotechnology
193:70–82, 2015.
doi:10.1016/j.jbiotec.2014.10.029
S. Goldrick, C. A. Duran-Villalobos, K. Jankauskas, D. Lovett, S. S. Farid and B. Lennox.
Modern day monitoring and control challenges outlined on an industrial-scale benchmark
fermentation process. Computers & Chemical Engineering 130:106471, 2019.
doi:10.1016/j.compchemeng.2019.05.037
S. Goldrick. Data for: Modern day monitoring and control challenges outlined on an
industrial-scale benchmark fermentation process. Mendeley Data, version 2, 2019. CC BY 4.0.
doi:10.17632/pdnjz7zz5x.2
S. W. Mogensen, K. Rathsman and P. Nilsson. Causal discovery in a complex industrial
system: A time series benchmark. Proceedings of the Third Conference on Causal Learning and
Reasoning (CLeaR), PMLR 236:1218–1236, 2024.
proceedings.mlr.press/v236/mogensen24a
K. Rathsman, P. Nilsson and S. W. Mogensen. Causal Learning at ESS: A Time Series
Benchmark [dataset]. Zenodo, 2024. CC BY 4.0.
doi:10.5281/zenodo.10641289
C. W. J. Granger. Investigating causal relations by econometric models and
cross-spectral methods. Econometrica 37(3):424–438, 1969.
doi:10.2307/1912791
J. Runge. Discovering contemporaneous and lagged causal relations in autocorrelated
nonlinear time series datasets. Proceedings of the 36th Conference on Uncertainty in Artificial
Intelligence (UAI), PMLR 124:1388–1397, 2020.
proceedings.mlr.press/v124/runge20a
P. Spirtes and C. Glymour. An algorithm for fast recovery of sparse causal graphs.
Social Science Computer Review 9(1):62–72, 1991.
doi:10.1177/089443939100900106
R. Pamfil, N. Sriwattanaworachai, S. Desai, P. Pilgerstorfer, K. Georgatzis, P. Beaumont and
B. Aragam. DYNOTEARS: Structure learning from time-series data. Proceedings of the 23rd International
Conference on Artificial Intelligence and Statistics (AISTATS), PMLR 108:1595–1605, 2020.
proceedings.mlr.press/v108/pamfil20a
About the author
Angelo Ziletti is the founder of Svelaro, where he works on causal
analysis of manufacturing process data. A theoretical physicist by training (PhD, Boston University), he led an AI
research team at the Max Planck Society and has spent more than ten years building AI systems that run in
production. He has 18 publications and over 2,900 citations.
