Skip to content
[email protected] : ~ $

// initialising …

// session ok

NAME
Ali Uyar
ROLE
Applied AI Engineer · EU
LOCUS
Vienna, Austria · UTC+01

I work on problems
that look simple until you get close.

run projects start a thread

[ signature interaction ]

The constraint is gravity. Everything else orbits it.

Three authored Pretext bands orbit the same constraint. Evidence keeps receipts, judgment names the tradeoff, and execution stays usable after the handoff.

Drag the amber core. The prose does not follow it; each lane parts, tightens, and breathes like field material around the thing that actually matters.

  • constraint core
  • evidence close
  • judgment visible
  • execution simple
  • failure readable
  • eval feedback
§ 01 Principles [ 03 · invariant ]

01/03

Find the constraint

A model problem may be a data problem. A dashboard problem may be a question problem. A strategy problem may be an avoided tradeoff. I like getting to the layer where the work actually changes.

02/03

Keep the evidence close

If a system makes a claim, routes a case, blocks an action, or changes a workflow, there should be something to inspect afterwards. Otherwise people are guessing politely.

03/03

Cut the machinery

Complexity has to earn its place. Sometimes the right move is a model, sometimes cleaner data, sometimes a better decision loop, and sometimes not adding AI at all.

§ 02 How I think [ operating notes ]

// the layer where the problem lives

I care about the layer where the problem actually lives.

The visible failure might be the model, the data, the workflow, the metric, the incentive, or the decision nobody wants to make. The work is finding the real constraint, then making the answer simple enough to use.

01

The first answer is useful, but it is often incomplete.

02

Do not fix a data problem with a prompt.

03

Do not fix an ownership problem with a dashboard.

04

Do not fix a judgment problem by adding more automation.

05

Evals should answer product questions, not decorate dashboards.

06

Find the real constraint, then make the output simple enough to use.

§ 03 Start here [ read article → ]

[ flagship note ]

The First Answer Is Usually Not the Real One

The first answer is often useful, but incomplete. The real constraint may be the model, the data, the workflow, the metric, the incentive, or the decision nobody wants to make.

§ 04 Research [ all papers → ]
§ 05 Selected projects [ ls /projects → ]
№ 01

DecisionGraph.py

A small local-first library for keeping AI decisions replayable. Useful when someone asks, later, 'why did the system do that?' and hand-waving is not enough.

Python source
30.01.26
№ 02

SchemaPilot.py

A data-quality control layer for AI datasets. It keeps schemas, access rules, and pipeline steps boringly explicit before anyone tries to put a model on top.

Python source
19.02.26
№ 03

PECR.rs

A retrieval runtime with policy checks built in. The point is simple: if the model cannot see it, it should not pretend it did.

Rust source
19.02.26
№ 04

cost-watchdog.ts

A self-hosted cost monitor that catches weird spend before the monthly report ruins someone's morning.

TypeScript source
13.02.26
№ 05

VeilPack.rs

An offline privacy gate for data pipelines. It catches sensitive values, redacts them, and packages the result so teams can prove what happened.

Rust source
10.02.26
§ 06 Focus [ how i work ]

// after the demo, in the weather

I care about the moment when an AI idea stops being exciting and starts becoming operational. What should it be trusted to do? Where should it fail closed? What evidence would make a decision defensible later?

That usually sits between engineering, product, and delivery. I like clear questions, small loops, and work that leaves the system less mysterious than it was before.