The real world is not deterministic.
Data is noisy.
Sensors drift.
Timing slips.
Humans are inconsistent.
Systems change quietly.
And yet, we expect systems to do one thing reliably:
make decisions.
Ideally, those decisions should be:
- repeatable,
- explainable,
- auditable.
This is the question that connects all of my work:
How can decision-making systems remain deterministic in a non-deterministic world?
This is not a project list.
It is a description of the problem I keep returning to.
The Model Fallacy
For a long time, I followed the standard recipe:
- more data
- larger models
- better metrics
Real systems challenged that belief.
The model can be correct.
The system can still fail.
The root cause is often not the loss function,
not the optimizer,
not the architecture.
It is the system design.
Hidden state.
Implicit dependencies.
Untracked changes.
Unmeasured timing effects.
At that point, one thing became clear:
Decision-making is not only an ML problem.
It is a systems problem.
One Question, Different Layers
That realization forced me to stop thinking in terms of single projects.
Instead, I began exploring the same question across different layers of the stack —
not to accumulate work,
but to expose failure modes.
Same Question, Different Layers
| Layer | Example Projects | What It Revealed |
|---|---|---|
| Prompt / Decision Logic | PromptLedger | If prompts are not versioned like code, decision logic becomes unreliable. |
| System Design | Bad Decision System | Determinism does not come from the model, but from design discipline. |
| Perception → Action | JumpNet (real-time latency failures) | A correct decision made at the wrong time is still wrong. |
| Hardware / Edge | Pico Trend Alarm, Sound Classifier, Mini SCADA | Noisy sensors and tight resources force explicit FSMs and hysteresis. |
| Data Control | Custom data collectors, viewers, logging tools | Data you don’t control will control system behavior. |
Decision Logic: The Prompt Layer
While building agentic workflows, I noticed a recurring issue:
Prompts behave like executable logic,
but are rarely treated as such.
Which prompt is in production?
Why did it change?
What behavior shifted as a result?
PromptLedger emerged from this gap.
Not as a prompt playground,
but as an attempt to make decision logic inspectable, versioned, and deterministic.
If the logic that guides decisions is unstable,
the system itself cannot be trusted.
System Design: When Correct Models Fail
To isolate system-level failure, I intentionally built a flawed decision pipeline.
Same inputs.
Same model.
Different outputs across identical runs.
The cause was not randomness in the model,
but global state, side effects, and hidden coupling.
That experiment reinforced a core principle:
Determinism is a property of design,
not of the model.
Perception → Decision → Action: Timing Matters
In JumpNet, offline metrics looked nearly perfect.
In real-time execution, the system failed.
A 50 ms delay was enough to alter behavior.
Minor prediction errors cascaded into visible mistakes.
The lesson was unavoidable:
A correct decision made at the wrong time
is still a wrong decision.
Determinism is about when as much as what.
Hardware: Constraints Shape Decisions
Deploying models on embedded hardware exposes assumptions that rarely surface in simulation.
Limited memory.
Noisy sensors.
Strict latency budgets.
Restricted numerical precision.
Models simplify.
Control logic becomes explicit.
FSMs and hysteresis replace soft heuristics.
Here, determinism is not optional.
It is required for the system to function at all.
Data: Control the Inputs or Lose the System
When a system behaves unexpectedly, I start by inspecting the data.
That led me to build custom:
- data collection tools
- logging pipelines
- dataset viewers
- synchronization and inspection utilities
Because one rule keeps repeating itself:
Uncontrolled data produces non-deterministic behavior.
This Is Not a CV
This text is not a list of skills or frameworks.
It is a stance.
I am not optimizing for larger models.
I am not chasing more impressive demos.
I am interested in one problem:
Reliable decision-making under real-world uncertainty.
Conclusion
Deterministic Decision Making in Non-Deterministic Environments
This is not a slogan.
It is a filter.
It determines:
- which problems I choose to work on,
- which ones I deliberately avoid,
- and where I draw the line.
That is why the work spans multiple domains.
They all wrestle with the same question.
If you care more about building reliable systems than bigger models,
and about understanding failure modes rather than showcasing demos,
you may find the following useful:
- GitHub: https://github.com/ertugrulmutlu
- dev.to series: https://dev.to/ertugrulmutlu
- Try PromptLedger:
pip install promptledger
Top comments (0)