Most data problems are not modelling problems. They are provenance problems.

I design enterprise data platforms and the AI built on top of them. The interesting decisions are almost never about which model to use. They are about where the data comes from, who is allowed to see it, what fails the build when a schema drifts, and whether anyone can reconstruct a figure six months after the person who produced it has left.

That bias comes from the route in. I studied law and mechatronics before computer science, and came to architecture through the work rather than through a title. It leaves you sceptical of systems whose correctness rests on someone remembering a convention.

I keep the specifics of who I have worked for off this site. The titles, the shape of the career and the capabilities are all here; the client list is not, and the project write-ups are anonymised.

I still write code, and I intend to keep doing so. An architect who cannot read the pipeline they specified is guessing, and the guesses compound quietly until someone has to rebuild the thing.

I prefer enforcement to convention. A rule that lives in a document nobody opens is not a rule. Put it in the build — a schema test, a contract, a lineage check that fails — and it holds without anyone policing it.

The same instinct is why I ended up co-authoring work on governed coding agents: the question of how you prove a system did what it was asked is the same question, one layer up.

I am most useful where a platform strategy has to survive contact with a real migration — regulated industries, manufacturing, finance, the public sector. Places where a wrong number has a cost attached and someone eventually asks to see the derivation. Austria-based, on-site or remote. If that sounds like your problem, here is how engagements usually start.