Forem: Ertugrul

PromptLedger v0.3 — Turning prompt history into a practical review workflow.

Ertugrul — Sat, 28 Mar 2026 13:37:59 +0000

Devlog — Part 3

Turning prompt history into a practical review workflow.

In Part 1, I introduced PromptLedger as a deliberately small, local-first tool for treating prompts like code.

In Part 2, I added release semantics: labels, label history, and status views that made it easier to answer questions like what is in production right now?

With v0.3, the next question became harder:

Even if I can diff two prompt versions, can I review them in a way that feels closer to a real release workflow?

That is the focus of this release.

PromptLedger v0.3 adds a small but practical Prompt Review layer on top of the existing history model — while still staying local-first, SQLite-backed, and intentionally limited in scope.

Why a third part?

After the release semantics work in v0.2, the project could already answer questions like:

Which prompt does prod currently point to?
When was that label changed?
How does prod differ from staging?

But another gap became obvious.

A raw diff is useful, but in practice people often want a slightly higher-level review:

Did the prompt become stricter?
Did the tone change?
Was the output format changed from bullets to JSON?
Did safety or refusal wording get stronger or weaker?
Is this a release change or a likely regression risk?

Those are not execution questions. They are not observability questions either.

They are review questions.

So instead of adding prompt execution, external APIs, or any hosted layer, I kept the project focused and added a review workflow built entirely on top of the existing local data.

The main addition: `review`

The new command is:

promptledger review --id onboarding --from prod --to staging

This compares two refs — versions or labels — and produces a structured review output that includes:

resolved refs and versions
a semantic summary
metadata changes
label context
warning flags
a few conservative notes

This is deliberately not an evaluation system. It does not score prompts. It does not call a model. It does not guess too much.

It simply makes a prompt diff easier to interpret.

From line diff to semantic summary

Traditional diffs are still useful, and PromptLedger keeps all previous diff modes.

But v0.3 adds a new summary-oriented mode:

promptledger diff --id onboarding --from 7 --to 9 --mode summary

This produces a heuristic, rule-based semantic summary instead of a raw line diff.

The important design decision here is that the summary is:

local
deterministic
transparent
intentionally conservative

In other words: it only says something when the change looks clear enough.

Current summary categories include:

tone changes
tighter or looser constraints
output format changes
broader vs more specific prompts
safety wording changes
length requirement changes
refusal or policy wording changes

This is not meant to replace reading the actual prompt.
It is meant to make review faster and more structured.

Why heuristics instead of an LLM?

Because using an external model for review would push the project in exactly the wrong direction.

It would introduce:

network dependence
nondeterministic behavior
more configuration
harder testing
less trust in the output

PromptLedger is supposed to be inspectable.
If it says “constraints tightened”, that should come from understandable rules, not hidden inference.

That made a heuristic system the better fit.

It is not as flexible as an LLM-based reviewer, but it is much easier to reason about — and much more aligned with the philosophy of the project.

Reviews now export cleanly to markdown

Another practical gap in earlier versions was sharing review output.

Reading a diff in the terminal is fine.
Sharing it in a PR, issue, or internal document is another matter.

So v0.3 adds markdown export for reviews:

promptledger export review --id onboarding --from prod --to staging --format md --out review.md

The exported markdown is deterministic and structured.
It includes:

a title
compared refs
semantic summary
text diff note
metadata changes
warnings
label information
a reviewer notes placeholder

That makes PromptLedger more useful in real workflows without adding any collaboration backend.

The file is still just a file.
You can paste it into GitHub, attach it to docs, or keep it locally.

Metadata changes are now first-class in reviews

Prompt text is only part of the story.

A release change may also involve metadata updates:

reason
author
tags
env
metrics

Earlier versions could already diff metadata, but v0.3 makes metadata changes part of the review object itself.

That matters because some changes are metadata-only.
In those cases, PromptLedger can now say that clearly instead of pretending there was meaningful prompt drift.

This is a small feature, but an important one.
It avoids overclaiming, which is one of the easiest ways to make a review tool feel unreliable.

Warning flags and likely drift hotspots

Prompt review is not just about summarizing what changed.
It is also about drawing attention to changes that deserve extra care.

v0.3 adds simple warning flags for cases such as:

comparing the same version to itself
environment changes
metadata-only changes
policy or refusal wording changes that may affect behavior drift

These warnings are not meant to be dramatic.
They are meant to make the review output more useful in practice.

For example, a wording change around refusal or safety does not automatically mean the prompt got worse — but it probably means a reviewer should read it more carefully.

The Python API now returns structured review objects

The review workflow is not just a CLI feature.

The Python API now exposes review results as structured domain objects rather than just formatted strings.

That means callers can programmatically access:

resolved refs
semantic summary items
metadata changes
warnings
notes
label context

This keeps the CLI and the API aligned while also making formatting a separate concern.

That separation turned out to be one of the cleaner changes in this version:

review logic lives in one place
rendering logic lives elsewhere
markdown export and terminal rendering are both built on the same review result

Small project, but still worth keeping modular.

UI update: review without write access

The Streamlit UI is still read-only.
That did not change.

What changed is that the comparison view now surfaces review information more clearly:

semantic summary
warnings
metadata diff
side-by-side prompt comparison
line diff

This keeps the UI aligned with the CLI review flow without turning it into an editor.

That constraint still matters.
The UI is there to inspect history, not to mutate it.

What did not change

Just as important as the new features is what was left out.

v0.3 does not add:

a hosted registry
prompt execution APIs
agent tooling
telemetry pipelines
tracing dashboards
cloud sync
automatic scoring
evaluation harnesses

There are already plenty of tools going in those directions.

PromptLedger is still trying to do one narrower thing well:
store, compare, review, and export prompt changes locally.

No schema expansion was needed

One part of this release that I particularly liked: the review workflow did not require turning the database into something more complicated.

SQLite remains the single source of truth.
The review layer is generated from existing prompt versions, labels, and metadata.

That kept the implementation smaller and the migration story simpler.

Not every useful feature needs a bigger schema.
Sometimes the better move is to extract more value from the structure that is already there.

Closing

v0.3 did not try to make PromptLedger smarter in a flashy way.
It tried to make it more reviewable.

The result is still a local tool.
Still inspectable.
Still deterministic where possible.
Still intentionally limited.

But now it is easier to answer a more realistic question:

Not just “what changed?” — but “how should I review this change before I move it forward?”

That is a better place for the project to be.

Links

PyPI: PyPI
GitHub: GitHub
LinkedIn: LinkedIn
Website: Website

DataLens: A Read-Only Image Dataset Sanity Checker

Ertugrul — Tue, 20 Jan 2026 13:43:50 +0000

DataLens: A Read‑Only Image Dataset Sanity Checker

Training a model rarely fails loudly.

Most of the time, it kind of works — loss decreases, accuracy moves, but the results feel unstable, brittle, or just wrong.

In my experience, when that happens, the root cause is often not the model, but the dataset.

So I built DataLens: a lightweight, read‑only sanity checker for image datasets.

The Problem: Silent Dataset Failures

Before training even starts, datasets often contain issues like:

Corrupted or unreadable images
Duplicate or near‑duplicate samples
Broken CSV → image mappings
Large numbers of orphan images
Severe class imbalance
Extremely small images or extreme aspect ratios
Mixed image modes (RGB / RGBA / grayscale)

None of these necessarily crash training.
They just quietly degrade everything downstream.

Why Read‑Only Matters

Many tools try to auto‑fix datasets.

I deliberately didn’t.

DataLens follows a simple rule:

Inspect, don’t mutate.

No files are moved
No labels are rewritten
No assumptions are silently applied

The tool’s job is to surface problems clearly, so you can decide what to do next.

What DataLens Does

DataLens is a Streamlit‑based audit tool with two modes.

Mode A — Images Only

For raw image folders:

Recursively scans images
Detects corrupted files
Finds exact and near‑duplicate images
Optionally infers classes from subfolders
Correctly handles unlabeled datasets (no fake “missing label” warnings)

Mode B — Images + Labels (CSV)

For supervised datasets:

Robust CSV reading (UTF‑8 with fallback)
Automatic filename & label column detection
Support for IDs without file extensions
Optional label normalization
Coverage analysis:
- How many CSV rows actually resolve to images?
Orphan analysis:
- How many images are never referenced by the CSV?

Duplicate Detection That Actually Helps

Exact duplicates are easy.
Near‑duplicates are not.

DataLens supports three methods:

sha256 — byte‑exact duplicates
quick hash — fast approximation
pHash — visually similar images (resized, recompressed, slightly cropped)

This is especially useful for datasets collected via scraping or merging multiple sources.

Data Hygiene Warnings

Beyond basic checks, DataLens flags issues that usually show up too late:

Very small images (e.g. <64px)
Extreme aspect ratios
High RGBA share (alpha channel surprises)
High image mode variance
Extension mismatches between CSV references and actual files

These are the kinds of things that quietly break training pipelines or augmentations.

Outputs You Can Share

After a run, DataLens produces:

An interactive dashboard (Streamlit)
A deterministic dataset_report.md
An issues.csv containing:
- missing images
- orphan images
- corrupted files
- duplicate groups

The report is designed to be:

commit‑friendly
reviewable
attachable to issues or PRs

Design Principles

I kept the scope intentionally tight:

Read‑only
Deterministic
Transparent
Pre‑training focused

This is not a dataset cleaning tool.
It’s a dataset inspection tool.

When I Use DataLens

Before starting any new training run
When receiving datasets from external sources
When debugging unstable or suspicious training behavior
As a lightweight QA step before investing GPU hours

Final Thought

We spend a lot of time tuning models.

But models are only as good as the data we feed them — and bad data usually doesn’t announce itself.

DataLens is my way of making datasets talk.

PromptLedger v0.2 — Labels, Status, and Better Diffs

Ertugrul — Tue, 13 Jan 2026 14:44:54 +0000

Devlog — Part 2

What changed after the first release, and why those changes matter in practice.

In the first part, I introduced PromptLedger as a deliberately small, local-first tool for treating prompts like code.

Since then, the project has moved from a minimal prompt history tracker to something closer to a prompt release ledger — without adding servers, agents, or execution layers.

This post covers what changed in v0.2, why those changes exist, and how they affect real prompt workflows.

Why a second part?

After publishing Part 1, the most common follow-up questions were:

Which prompt is actually in production right now?
How do I compare prod vs staging without remembering version numbers?
Can I see when a release pointer changed?

Answering these questions required release semantics, not more prompt editing features.

That is the focus of v0.2.

Label history: prompts need an audit trail

In v0.1, labels existed as movable pointers, similar to git tags. However, once a label moved, its previous state was lost.

In v0.2, every label update is recorded in an append-only history log.

This means you can now answer questions like:

What prompt was in production yesterday?
When did prod move from version 7 to version 9?

promptledger label history --id onboarding

Under the hood, label history is implemented as a separate label_events table. Label pointers remain mutable, but the history is immutable.

This keeps the system simple while adding real auditability.

Label-based diff: stop thinking in version numbers

Version numbers are great for storage, but humans think in environments.

v0.2 allows diffs to be expressed in terms of labels:

promptledger diff --id onboarding --from prod --to staging

This resolves labels to their underlying versions and performs a normal diff.

The important detail is that nothing new is stored. Labels are only references; diffs always operate on immutable prompt versions.

Status command: a one-line overview

Another recurring problem was simply understanding the current state of prompts.

The new status command provides a concise, git-style overview:

promptledger status

For each prompt, it shows:

The latest version number
The timestamp of that version
Active labels and the versions they point to

This is intentionally read-only and summary-focused. If you need details, you still drill down using list, show, or diff.

Better diff modes

Prompt changes are not always best reviewed line-by-line.

v0.2 introduces multiple diff modes built on top of Python’s difflib:

unified — the default, git-style view
context — useful for wider structural changes
ndiff — character-level insight for small edits
metadata — diff only metadata (reason, tags, env, metrics)

promptledger diff --id onboarding --from 1 --to 2 --mode metadata

Metadata diffs are always rendered in unified format to keep them readable and deterministic.

UI update: history without write access

The Streamlit UI remains strictly read-only, but v0.2 adds label history visibility.

You can now:

Inspect prompt timelines
See which labels point where
Review label movements over time

All mutations still go through the CLI or Python API.

This constraint is intentional: the UI is for inspection, not experimentation.

What did not change

Several things were deliberately left out:

No prompt execution or playground
No agent framework
No cloud sync or backend service
No automatic evaluation or scoring

PromptLedger is still a ledger, not an environment.

Migration and compatibility

v0.2 introduces a database schema migration, but it is fully backwards compatible.

Existing databases are upgraded in place, with no data loss.

The new tables add information, but do not change existing semantics.

Closing

v0.2 did not make PromptLedger bigger — it made it clearer.

By adding release semantics, auditability, and better inspection tools, prompts can now be reviewed and promoted with the same discipline as code.

No servers. No dashboards. No magic.

Just history, diffs, and intent — stored locally.

Links

Pypi : Pypi
Github : Github
My Linkedin : Linkedin
My Website : Website

Hysteresis in Neural Networks — Part 1

Ertugrul — Fri, 09 Jan 2026 14:09:14 +0000

Training Order Is Not Innocent

What if seeing the same data is not enough?

A common, almost implicit assumption in machine learning is that if a model is trained on the same dataset with the same architecture and optimizer, it should end up learning essentially the same thing. Training order is usually treated as an implementation detail — a convenience, not a defining factor.

In this post, I show a simple but striking counterexample:

Even when two neural networks see exactly the same data, the order in which the data is presented can determine what the model permanently remembers and what it completely forgets.

This is the first part of a short series on hysteresis in neural networks. Here, I focus only on observable behavior (accuracy and forgetting). In the next part, we will look inside the model and explain why this happens geometrically.

The Core Question

Assume we have two datasets, A and B.

We train the same model in two different ways:

SAB: first on A, then on B
SBA: first on B, then on A

Crucially:

The architecture is identical
The optimizer and hyperparameters are identical
The random seed is fixed
The union of the data is the same: A ∪ B

The only difference is chronological order.

The standard intuition is that this should not matter.

This intuition is wrong.

Experimental Setup (Intentionally Simple)

To avoid hiding effects behind complexity, I used a deliberately minimal setup.

Dataset: MNIST
Split:
- A = digits {0,1,2,3,4}
- B = digits {5,6,7,8,9}
Model: small CNN + MLP head
Training: 20 epochs total (10 per phase)

Several things were explicitly disabled:

No Batch Normalization
No data augmentation
Deterministic initialization (fixed seed)

This ensures that any difference we observe is not an artifact of randomness or regularization, but a consequence of training order alone.

What Happens During Training?

Let’s start with the SAB scenario: the model learns A first, then B.

SAB: A → B

Observed behavior:

During the first phase, accuracy on A quickly rises to ~99%
Accuracy on B remains near 0% (expected)
After switching to B:
- Accuracy on B rises to ~99%
- Accuracy on A collapses to 0%

SBA: B → A

The mirror experiment produces the mirror result:

Observed behavior:

During the first phase, accuracy on B rises to ~99%
Accuracy on A remains near 0%
After switching to A:
- Accuracy on A rises to ~99%
- Accuracy on B collapses to 0%

Accuracy Curves

SAB accuracy over epochs

Description: Line plot showing acc_A, acc_B, and acc_full across epochs. A vertical dashed line marks the phase transition (A → B). Accuracy on A drops sharply after the transition.

SBA accuracy over epochs

Description: Same plot as above, but for SBA. Accuracy on B drops sharply after switching to A.

A Subtle but Important Observation

Despite the dramatic forgetting, overall accuracy on the full test set remains around ~50% in both cases.

This is not a contradiction.

Each model performs extremely well on half of the classes and completely fails on the other half. Aggregated metrics hide this asymmetry.

Two models can have similar overall accuracy while representing fundamentally different worlds internally.

Quantifying the Effect: Hysteresis Loss

We can define a simple, order-dependent metric:

[\mathcal{L}_{\text{hyst}}(A) = |\text{Acc}_A(SAB) - \text{Acc}_A(SBA)|]

In this experiment:

Acc_A(SAB) ≈ 0.00
Acc_A(SBA) ≈ 0.99

This yields a hysteresis loss close to 1.0, i.e. the maximum possible difference.

The same holds symmetrically for dataset B.

Hysteresis summary

Description: Bar chart showing absolute accuracy differences between SAB and SBA.
Hysteresis for the individual subsets A and B is near-maximal, while hysteresis in the aggregate (full test accuracy) is close to zero and visually compressed due to the shared scale.

This highlights a key point: global performance metrics can remain almost invariant, even when class-conditional behavior is maximally path-dependent.

What This Means

This result shows that training order is not just an optimization detail.

The network does not converge to a single, order-independent solution
Learning leaves path-dependent traces in weight space
Once the model commits to one subset, returning to a balanced representation is not trivial

This behavior is strongly reminiscent of hysteresis in physical systems, where the final state depends on the path taken, not only on the endpoint.

What This Post Does Not Explain (Yet)

This post only shows that hysteresis exists.

It does not explain:

Whether the two final models lie in different basins of attraction
Whether their internal representations are aligned or incompatible
Whether one can smoothly interpolate between them without loss spikes

These questions require looking at the geometry of the weight space, not just accuracy curves.

That is exactly what Part 2 will address.

Reproducibility

All experiments were run with a fixed configuration and deterministic setup. The code used for this post (FAZ 1) is available on GitHub:

Hysteresis in Neural Networks

The geometric analysis (weight trajectories, representation similarity, interpolation barriers) will be released together with the next post.

Closing Thoughts

If training order alone can erase entire subsets of knowledge, then:

Curriculum learning has hidden costs
"Same data" does not imply "same model"
Optimization is not just minimization — it is a history-dependent process

In the next post, we will open the model and examine how these irreversible choices are encoded in the geometry of neural manifolds.

Part 2: Inside the Weight Space — Geometry of Hysteresis

Links

Linkedin: Linkedin
Github: Github
Website: Website

Deterministic Decision Making in Non-Deterministic Environments: Why all my projects fight the same problem

Ertugrul — Sun, 04 Jan 2026 02:34:46 +0000

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

PromptLedger: Local-first prompt version control

Ertugrul — Sat, 03 Jan 2026 21:18:11 +0000

Treat prompts like code: version them locally, diff them, label releases, and inspect history — without any backend services.

Prompt engineering has quietly become production work. Prompts evolve, regress, get tuned for edge cases, and eventually land in “prod”. Yet most teams still track them in scratch files, notebooks, or chat logs.

PromptLedger is a deliberately small tool that fixes this by treating prompts like code: every change is versioned, diffable, and labeled — all stored locally in a single SQLite database.

This post is a technical deep dive into how PromptLedger works, what data it stores, and why its design is intentionally boring.

Design goals

PromptLedger is built around a few strict constraints:

Local-first: no server, no SaaS, no telemetry
Single source of truth: one SQLite file
Git-aware: works naturally inside repositories
Read-only UI: all writes go through the CLI/API
Deterministic output: exports are stable and diffable

If you are looking for an agent framework or a prompt playground, this is not it.

tecture overview

The codebase is intentionally small and split by responsibility:

cli.py – argument parsing and user-facing commands
core.py – domain logic (PromptLedger class)
db.py – SQLite connection, schema, migrations
ui.py – Streamlit-based read-only viewer

There are no background services and no long-running processes. PromptLedger runs when you invoke it and exits.

Storage and path resolution

PromptLedger always stores data locally in promptledger.db.

Resolution rules are deterministic:

Inside a git repo: <repo_root>/.promptledger/promptledger.db
Outside git: <cwd>/.promptledger/promptledger.db
Override with PROMPTLEDGER_HOME=/custom/path
Hard override via PromptLedger(db_path="/abs/path/to.db")

This avoids accidental duplication when running commands from nested directories and keeps prompt data out of git history by default.

SQLite schema

Two tables make up the core of PromptLedger:

prompt_versions: immutable prompt history
labels: mutable pointers to specific versions

Each prompt version stores:

prompt_id
version
content (the prompt text)
content_hash (SHA-256)
created_at (UTC ISO timestamp)
optional metadata: reason, author, tags, env, metrics

Labels store:

prompt_id
label (e.g. prod, staging)
version
updated_at

This separation lets you move release pointers without creating new versions.

Versioning algorithm

When you add a prompt, PromptLedger:

Normalizes newlines (CRLF/CR → LF)
Hashes the normalized content
Fetches the latest version for that prompt
Skips insertion if the hash matches (no-op)
Otherwise inserts a new version with incremented number

This keeps history clean and avoids formatting-only noise.

Newline normalization

Cross-platform newline differences are a common source of useless diffs.

PromptLedger normalizes line endings before hashing and diffing, which means:

Windows CRLF and Unix LF content are treated as identical
Diff output focuses on real textual changes

Metadata model

PromptLedger supports lightweight metadata for each version:

reason – why the prompt changed
author – who made the change
tags – arbitrary labels for grouping
env – dev, staging, prod
metrics – JSON blob (accuracy, latency, cost, ratings)

This turns raw text history into something closer to an audit trail.

Labels: release-style pointers

Labels are the feature that pushes PromptLedger beyond simple history tracking.

Think of labels like git tags that move:

promptledger label set --id onboarding --version 7 --name prod
promptledger label set --id onboarding --version 9 --name staging

Now you can answer questions like:

What prompt is currently in production?
Which version was deployed last week?

Without copying or duplicating prompt content.

CLI workflow

Core commands:

init – create DB and .gitignore entry
add – add or skip a version
list – list versions
show – show content + metadata
diff – unified diff between versions
search – content + metadata search
export – deterministic JSONL / CSV
label – manage release pointers
ui – launch Streamlit viewer

A typical flow:

promptledger init
promptledger add --id demo --text "Hello"
promptledger add --id demo --text "Hello World"
promptledger diff --id demo --from 1 --to 2
promptledger label set --id demo --version 2 --name prod

Streamlit UI (read-only)

The UI is intentionally non-destructive:

Timeline view of versions
Filters by prompt id, tags, env
Full content preview
Unified diff and side-by-side comparison

All writes remain in the CLI/API path.

Export and determinism

Exports are designed for reproducibility:

JSONL uses sorted keys
CSV has a fixed column order
Repeated exports of the same data are byte-for-byte identical

This makes PromptLedger suitable for audits, reviews, and downstream tooling.

Security notes

PromptLedger never sends data anywhere.

It includes a minimal warning for common secret patterns (sk-, AKIA, -----BEGIN). This is advisory only and can be disabled. The responsibility remains with the user to avoid storing secrets in prompt text.

What PromptLedger is not

Not an LLM framework
Not an agent system
Not a hosted service
Not a playground

It is a local ledger for prompt evolution.

Workflow for those interested

Closing

If your prompts matter enough to review, promote, and roll back, they matter enough to version properly.

PromptLedger keeps that history local, inspectable, and boring — which is exactly the point.

Contact and Links

Pypi : Pypi
Github : Github
My Linkedin : Linkedin
My Website : Website

I Intentionally Built a Bad Decision System (So You Don’t Have To)

Ertugrul — Fri, 19 Dec 2025 11:00:00 +0000

A tiny benchmark that exposes silent failure modes in AI and ML pipelines

Most AI blog posts show best practices: clean architectures, neat abstractions, and impressive demos. I decided to do the opposite.

I intentionally built a bad AI system — one that works, produces outputs, and even looks reasonable at first glance — and then compared it to a boring, well-designed version of the same pipeline.

The goal was not performance. The goal was to understand how systems fail silently when design principles are ignored.

The task: same problem, two implementations

Both systems solve the exact same problem:

Input text → extract keywords → compute a score → recommend an action

The action space is deliberately small:

WAIT_AND_SEE
BUY_MORE_STOCK
PANIC_REORDER

Keeping the task simple allows us to focus entirely on system behavior, not model quality.

The benchmark idea

The benchmark is intentionally minimal:

Take a single, fixed input text
Run it multiple times through the system
Observe whether the outputs stay stable

Why this matters:

A system that only works once is not a system — it’s a coincidence.

If the same input produces different outputs, something is fundamentally wrong at the system level.

Benchmark results: BAD vs GOOD

The following results were produced by running the same input five times through both systems.

BAD system output (excerpt)

The BAD system gradually escalates its decisions:

Run 1 → score 14, action WAIT_AND_SEE
Run 3 → score 42, action BUY_MORE_STOCK
Run 5 → score 74, action PANIC_REORDER

Same input. Same keywords. Completely different decisions.

Aggregated benchmark summary

BAD system

Runs: 5
Unique scores: 5
Scores: [14, 28, 42, 58, 74]
Unique actions: 3

GOOD system

Runs: 5
Unique scores: 1
Scores: [14, 14, 14, 14, 14]
Unique actions: 1

The GOOD system behaves like a function. The BAD system behaves like a memory leak.

Failure Taxonomy: How the BAD System Breaks

The bad system does not fail in a single obvious way. Instead, it exhibits multiple interacting failure modes that are common in real-world AI and data systems. Naming these failure modes makes them easier to detect—and harder to accidentally ship.

1) Drift

Definition: The system’s output changes over time even when the input stays exactly the same.

Root cause:

Global score accumulation across runs
State that grows monotonically without reset

Why this is dangerous:

Business logic mutates without any explicit change
Historical execution order influences current decisions
Monitoring dashboards often miss the problem because values remain “reasonable”

Drift is especially dangerous because it looks like learning—but it isn’t.

2) Non-determinism

Definition: Identical inputs produce different outputs.

Root cause:

Random noise injected into scoring
Implicit dependency on execution history

Why this is dangerous:

Bugs cannot be reliably reproduced
Test failures become flaky and untrustworthy
A/B experiments lose statistical meaning

If you can’t reproduce a decision, you can’t debug it.

3) Hidden State

Definition: Functions rely on data that is not visible in their interface or inputs.

Root cause:

Global variables such as CURRENT_SCORE, LAST_TEXT, and RUN_COUNT

Why this is dangerous:

Code cannot be understood locally
Refactoring changes behavior in non-obvious ways
New contributors unknowingly introduce regressions

Hidden state turns every function call into a guessing game.

4) Silent Corruption

Definition: The system continues to run without errors while its decisions become increasingly wrong.

Root cause:

No explicit failure signals
No invariants or sanity checks

Why this is dangerous:

Incorrect outputs propagate downstream
Problems surface only through business impact
Rollbacks become difficult or impossible

Loud failures get fixed. Silent failures get deployed.

Why This Taxonomy Matters

These failure modes rarely appear in isolation. In the BAD system, they reinforce each other:

Hidden state enables drift
Drift amplifies non-determinism
Non-determinism hides silent corruption

Understanding these patterns is more valuable than fixing any single bug—because the same taxonomy applies to much larger and more complex AI systems.

A single metric: Stability Score

To summarize system behavior, I used a single metric:

stability_score = 1 - (unique_scores / runs)

1.0 → perfectly stable
0.0 → completely unstable

Stability results

BAD system → 0.0
GOOD system → 0.8

This one number already tells you which system you can trust.

Minimal Fixes: Four Small Patches That Change Everything

This is not a rewrite. These are surgical changes. Each patch removes an entire class of failure modes without introducing new abstractions or frameworks.

Patch 1 — Remove Global State

Before (BAD):

# global mutation + history dependence
GS.CURRENT_SCORE += base
return GS.CURRENT_SCORE

After (GOOD):

def score_keywords(keywords, text):
    return sum(len(w) % 7 for w in keywords) + len(text) % 13

What this fixes:

Eliminates score drift
Removes hidden history dependence
Makes the function deterministic and testable

A function that depends on global state is not a function — it’s a memory leak.

Patch 2 — Push Side-Effects to the Boundaries

Before (BAD):

def extract_keywords(text):
    print("Extracting keywords...")
    open("log.txt", "a").write(text)
    return tokens[:k]

After (GOOD):

def extract_keywords(text):
    return tokenize(text)[:k]

# side-effects handled explicitly at the edge
logger.info("Extracting keywords")

What this fixes:

Core logic becomes reusable
Logging becomes configurable
Unit testing becomes trivial

Side-effects inside core logic silently infect everything upstream.

Patch 3 — Make Dependencies Explicit

Before (BAD):

if GS.LAST_TEXT is not None:
    base += len(GS.LAST_TEXT) % 13

After (GOOD):

def score_keywords(keywords, text):
    base = sum(len(w) % 7 for w in keywords)
    return base + (len(text) % 13)

What this fixes:

No hidden inputs
Clear data flow
Safe refactoring

If a dependency isn’t in the function signature, it’s a liability.

Patch 4 — Name the Magic Numbers

Before (BAD):

if score > 42:
    action = "PANIC_REORDER"

After (GOOD):

@dataclass(frozen=True)
class Config:
    panic_threshold: int = 42

if score > cfg.panic_threshold:
    action = "PANIC_REORDER"

What this fixes:

Decisions become explainable
Parameters become reviewable
Behavior changes become intentional

Magic numbers turn engineering decisions into superstition.

Summary

These four patches:

Remove hidden state
Eliminate non-determinism
Make behavior explainable
Restore trust in the system

No agents. No frameworks. Just engineering discipline.

Final takeaway

The BAD system works. That’s the problem.

It fails in the most dangerous way possible: plausibly and quietly.

The GOOD system is boring, predictable, and easy to reason about — which is exactly what you want in production.

Working code is not the same as a working system.

Code & Reproducibility

All code used in this article — including the intentionally broken system, the clean implementation, and the benchmark — is available on GitHub:

👉 https://github.com/Ertugrulmutlu/I-Intentionally-Built-a-Bad-Decision-System-So-You-Don-t-Have-To

If you want to reproduce the results, run:

python compare.py

The benchmark will run the same input multiple times through both systems and show, in a few lines of output, why predictability matters more than flashy abstractions.

How Do You Actually Optimize Agents? It Depends on the Task

Ertugrul — Thu, 18 Dec 2025 18:28:14 +0000

After my recent talk on Agent-in-the-Loop systems, I was asked a seemingly simple question: How do you optimize agents?
Link for Talk: https://www.youtube.com/watch?v=HwCR59VuYn4&t=1888s

At first glance, this sounds like a technical question. Many people expect a concrete answer involving prompt engineering, temperature tuning, or model selection. My response, however, was far less satisfying — but far more honest:

It depends on the task.

This answer often feels like a cop-out. In reality, it reflects a deeper truth about agentic systems: you don’t optimize agents in isolation — you optimize the system they operate in.

The Common Misconception: Optimization Means Tuning the Model

When people talk about optimizing agents, they usually mean optimizing the underlying model. Adjust the prompt, lower the temperature, swap the model, and expect better behavior.

These adjustments can help at the margins, but they rarely address the root cause of failure. That’s because an agent is not just a language model.

An agent is a system composed of:

a task definition
an action space (what the agent is allowed to do)
constraints and boundaries
feedback and evaluation mechanisms
stop and escalation conditions

If these components are poorly designed, no amount of prompt tuning will make the system reliable.

Agent Optimization Is a Task Design Problem

In practice, most agent failures are task design failures.

Agents struggle when objectives are too broad, success criteria are vague, or responsibilities are overloaded. Instructions like “do your best” or “solve this end-to-end” leave too much room for interpretation and lead to unpredictable behavior.

Consider the difference between these two prompts:

Poorly framed task:

"Analyze this document and decide what to do."

This instruction hides multiple decisions inside a single step: analysis, prioritization, and action selection. The agent has no clear notion of success or failure.

Well-framed task:

"Summarize the document, estimate uncertainty, and escalate to a human if confidence falls below a defined threshold."

Here, the task is explicit, bounded, and testable. The agent’s role is clear, and human intervention is intentionally designed rather than left implicit.

Optimizing an agent often means narrowing the task:

defining what success actually means
specifying what the agent should not do
breaking complex goals into smaller, verifiable steps

A well-framed task reduces the need for aggressive model-level optimization.

Feedback Loops Matter More Than Prompts

Another common failure point is feedback design. Agents frequently evaluate their own outputs, but self-evaluation can be misleading or overly optimistic.

Effective agent systems rely on feedback loops that are:

timely
aligned with real objectives
capable of triggering escalation

If feedback arrives too late or measures the wrong thing, the agent may appear functional while gradually drifting away from its intended behavior.

Human involvement is most valuable here — not in validating every decision, but in designing how feedback is generated and when intervention is required.

Constraints Are Not a Limitation — They Are a Guide

One of the most overlooked aspects of agent optimization is constraint design.

Constraints define:

which tools an agent can use
how often it can retry
how much context it can consume
when it must stop or ask for help

Rather than limiting performance, constraints provide structure. They prevent runaway behavior and make agent actions easier to reason about.

Constraints don’t weaken agents — they guide them.

The Role of Humans in Optimized Agent Systems

In optimized Agent-in-the-Loop systems, humans are not prompt engineers or micro-managers. Their role is to design the system boundaries and supervision mechanisms.

Humans are best positioned to:

define goals and constraints
decide which failures are acceptable
interpret ambiguous situations

In other words, humans optimize the decision space, not individual decisions.

Key Takeaways

Agent optimization starts with task design, not model tuning
Prompts and temperatures are secondary levers
Feedback loops determine long-term behavior
Constraints increase reliability and predictability
Humans belong above the loop, not inside every step

Final Thoughts

Optimizing agents is not about making them smarter. It’s about making the system clearer.

When tasks are well-defined, feedback is meaningful, and constraints are explicit, agents don’t need to be aggressively optimized — they simply work better.

My First Public ML Talk: Human-in-the-Loop Agent-in-the-Loop (Dec 16, DataTalks.Club)

Ertugrul — Wed, 19 Nov 2025 11:08:08 +0000

About the Event

Modern ML systems are undergoing a significant shift: pipelines that once relied heavily on human-supervised feedback are gradually transitioning toward agent-driven, autonomous loops. In this session, we’ll walk through what actually changes—architecturally and operationally—when agents take on active roles inside ML workflows.

This will be my first public ML talk, and the focus is to deliver a clear, grounded, example-driven explanation of HITL → AITL transitions without unnecessary hype.

📅 Event Details

Date: 16 December 2025
Time: 12:30–13:30 CET
Registration: https://luma.com/d2o7pqt9

🔹 Outline

1. Human-in-the-Loop (HITL): Foundations and Limitations

What HITL means in practice (guided feedback loops, evaluation, corrections)
Key limitations: scalability, latency, reasoning gaps, context sensitivity
Where HITL still shines: accuracy, safety, human effectiveness

2. Agent-in-the-Loop (AITL): The Next Evolution Step

What changes when agents become active participants in the loop
Architectural view: planning, tool-use, continuous improvement, automation
Strengths: adaptivity, speed, scalable labeling, generalization

3. Real-World Comparison: When Each Paradigm Wins

HITL vs AITL across accuracy, trust, cost, transparency, and scalability
HITL-critical domains: medical, autonomous driving, manufacturing
AITL-favored areas: fraud detection, recommender systems, logistics

4. Transition & Future Outlook

Human-in-the-loop → human-on-the-loop → human-over-the-loop
Hybrid approaches combining human judgment with agent autonomy

🎤 Bio

Ertuğrul Mutlu is a Computer Engineering student at RWTH Aachen University and a Werkstudent Researcher at Fraunhofer IAIS (Enterprise Information Systems).

His interests lie in building reliable, lightweight AI systems, exploring agentic workflows, and combining classical methods with modern LLM-driven architectures. His work includes applied LLM engineering, evaluation pipelines, and signal-processing-inspired feature extraction.

He recently published a preprint on wavelet-based feature engineering and clustering, and writes technical articles on dev.to about ML systems, agentic design patterns, and practical AI engineering. This upcoming session will be his first public talk, marking the beginning of a broader effort to share practical insights and research explorations with the ML community.

🗓 Daily LeetCode Progress – Day 22

Ertugrul — Tue, 09 Sep 2025 11:06:50 +0000

Problems Solved:

#230 Kth Smallest Element in a BST
#236 Lowest Common Ancestor of a Binary Tree

This continues my daily series (Day 22: Inorder Traversal + Divide & Conquer). Today I solved two core binary-tree patterns: using an inorder traversal on a BST to extract sorted order and find the k‑th smallest, and a clean divide‑and‑conquer DFS to compute the LCA in a general binary tree.

💡 What I Learned

Kth Smallest in BST (#230): Because an inorder traversal of a BST yields values in non‑decreasing order, we can increment a counter during traversal and return when the counter hits k. This creates a simple early‑exit pattern.
LCA in Binary Tree (#236): A post‑order style DFS works neatly: if a subtree returns non‑null for both p and q, the current node is the LCA. If only one side is non‑null, bubble that node upward.
General tips:
- Don’t compare node.val to p/q objects—compare nodes directly for LCA.
- For BST inorder solutions, keep a mutable counter/state ( member variables in C++ or self fields in Python) and stop early whenfound.

🧩 #230 — Kth Smallest Element in a BST

C++ (Recursive Inorder with early stop, O(n))

/**
  * Definition for a binary tree node.
  * struct TreeNode {
  *   int val;
  *   TreeNode *left;
  *   TreeNode *right;
  *   TreeNode() : val(0), left(nullptr), right(nullptr) {}
  *   TreeNode(int x) : val(x), left(nullptr), right(nullptr) {}
  *   TreeNode(int x, TreeNode *left, TreeNode *right) : val(x), left(left), right(right) {}
  * };
 */
class Solution {
public:
    int count = 0;
    int result = -1;

    void inorder(TreeNode* node, int k) {
        if (!node || result != -1) return;
        inorder(node->left, k);
        count++;
        if (count == k) {
            result = node->val;
            return;
        }
        inorder(node->right, k);
    }

    int kthSmallest(TreeNode* root, int k) {
        inorder(root, k);
        return result;
    }
};

Python (Recursive Inorder, O(n))

# Definition for a binary tree node.
# class TreeNode(object):
#     def __init__(self, val=0, left=None, right=None):
#         self.val = val
#         self.left = left
#         self.right = right
class Solution(object):
    def kthSmallest(self, root, k):
        self.count = 0
        self.result = None

        def inorder(node):
            if not node:
                return
            inorder(node.left)
            self.count += 1
            if self.count == k:
                self.result = node.val
                return
            inorder(node.right)

        inorder(root)
        return self.result

Key idea: Inorder on BST == sorted order. Maintain a counter and return once k is reached.

Complexity: O(h + k) average when the early stop prunes (worst‑case O(n)), O(h) recursion stack where h is tree height.

🧩 #236 — Lowest Common Ancestor of a Binary Tree

C++ (Divide & Conquer DFS, O(n))

/**
  * Definition for a binary tree node.
  * struct TreeNode {
  *   int val;
  *   TreeNode *left;
  *   TreeNode *right;
  *   TreeNode(int x) : val(x), left(NULL), right(NULL) {}
  * };
 */
class Solution {
public:
    TreeNode* lowestCommonAncestor(TreeNode* root, TreeNode* p, TreeNode* q) {
        if (!root || root == p || root == q) return root;

        TreeNode* left = lowestCommonAncestor(root->left, p, q);
        TreeNode* right = lowestCommonAncestor(root->right, p, q);

        if (left && right) return root;   // p and q in different subtrees
        return left ? left : right;       // both in the same subtree or not found here
    }
};

Python (Divide & Conquer DFS, O(n))

# Definition for a binary tree node.
# class TreeNode:
#     def __init__(self, x):
#         self.val = x
#         self.left = None
#         self.right = None

class Solution:
    def lowestCommonAncestor(self, root: 'TreeNode', p: 'TreeNode', q: 'TreeNode') -> 'TreeNode':
        if not root or root == p or root == q:
            return root

        left = self.lowestCommonAncestor(root.left, p, q)
        right = self.lowestCommonAncestor(root.right, p, q)

        if left and right:
            return root
        return left if left else right

Key idea: Post‑order style recursion: return a non‑null pointer if p or q is found in a subtree; if both sides return non‑null, the current node is the LCA.

Complexity: O(n) time (each node visited once), O(h) recursion stack.

📸 Achievements

Implemented inorder traversal with early stopping to fetch the k‑th smallest efficiently on BSTs.
Solved LCA on general binary trees with a concise divide‑and‑conquer DFS.

📦 Complexity Recap

Kth Smallest (BST): O(h + k) average (worst O(n)), O(h) stack.

LCA (Binary Tree): O(n) time, O(h) stack.

📣 Join the Journey

I’m solving and documenting problems daily in both Python and C++, covering trees, graphs, stacks/queues, and classic traversal patterns. Follow along if you’re into clean patterns and cross‑language implementations!

Links:

LinkedIn: https://www.linkedin.com/in/ertugrul-mutlu
GitHub Series: https://github.com/Ertugrulmutlu/leetcode-series

🗓 Daily LeetCode Progress – Day 21

Ertugrul — Mon, 08 Sep 2025 10:27:34 +0000

Problems Solved:

#739 Daily Temperatures
#56 Merge Intervals

This continues my daily series (Day 21: Monotonic Stack + Interval Merging). Today I solved two fundamental interview patterns: using a monotonic stack to find the next warmer day, and sorting + single pass to merge overlapping intervals.

💡 What I Learned

For Daily Temperatures (#739), a monotonic decreasing stack of indices lets us pop and resolve days as soon as we encounter a warmer temperature: every index is pushed and popped at most once → O(n).
For Merge Intervals (#56), always sort by start, then sweep left→right. If the current start <= last merged end, they overlap → extend the end; otherwise, start a new interval.
Both problems demonstrate how the right data structure (stack) or preprocessing (sort) yields linear-time passes after a cheap setup.

🧩 #739 — Daily Temperatures

Python (Monotonic Stack, O(n))

from typing import List

class Solution:
    def dailyTemperatures(self, temperatures: List[int]) -> List[int]:
        n = len(temperatures)
        ans = [0] * n
        stack = []

        for i, t in enumerate(temperatures):
            while stack and temperatures[stack[-1]] < t:
                j = stack.pop()
                ans[j] = i - j
            stack.append(i)

        return ans

C++ (Monotonic Stack, O(n))

#include <vector>
#include <stack>
using namespace std;

class Solution {
public:
    vector<int> dailyTemperatures(vector<int>& temperatures) {
        int n = (int)temperatures.size();
        vector<int> ans(n, 0);
        stack<int> st;
        for (int i = 0; i < n; ++i) {
            while (!st.empty() && temperatures[st.top()] < temperatures[i]) {
                int j = st.top(); st.pop();
                ans[j] = i - j;
            }
            st.push(i);
        }
        return ans;
    }
};

Key idea: Keep indices of days with decreasing temperatures on the stack. When a warmer day appears, pop and fill the answer with the distance.

Complexity: O(n) time, O(n) space for the stack (worst-case strictly decreasing temps).

🧩 #56 — Merge Intervals

Python (Sort + Sweep, O(n log n))

from typing import List

class Solution:
    def merge(self, intervals: List[List[int]]) -> List[List[int]]:
        if not intervals:
            return []

        intervals.sort(key=lambda x: x[0])
        merged = [intervals[0]]

        for s, e in intervals[1:]:
            last_s, last_e = merged[-1]
            if s <= last_e:
                merged[-1][1] = max(last_e, e)
            else:
                merged.append([s, e])
        return merged

C++ (Sort + Sweep, O(n log n))

#include <vector>
#include <algorithm>
using namespace std;

class Solution {
public:
    vector<vector<int>> merge(vector<vector<int>>& intervals) {
        if (intervals.empty()) return {};
        sort(intervals.begin(), intervals.end(),
             [](const vector<int>& a, const vector<int>& b){ return a[0] < b[0]; });

        vector<vector<int>> merged;
        merged.push_back(intervals[0]);

        for (size_t i = 1; i < intervals.size(); ++i) {
            auto& last = merged.back();
            if (intervals[i][0] <= last[1]) {
                last[1] = max(last[1], intervals[i][1]);
            } else {
                merged.push_back(intervals[i]);
            }
        }
        return merged;
    }
};

Key idea: Sort by start; overlapping detection becomes local to the last merged interval. Touch each interval once after sorting.

Complexity: O(n log n) for sorting, O(n) sweep, O(1) extra apart from the output.

📸 Achievements

Implemented monotonic stack to solve next-warmer-day distances in linear time.

Merged arbitrary-ordered intervals correctly via sort + single pass.

📦 Complexity Recap

Daily Temperatures: O(n) time, O(n) space (stack).
Merge Intervals: O(n log n) time (sort), O(n) pass; O(1) extra space beyond result.

📣 Join the Journey

I’m solving and documenting problems daily in both Python and C++, covering arrays, stacks/queues, sliding windows, and classic interval problems. Follow along if you’re interested in

Links:

LinkedIn: https://www.linkedin.com/in/ertugrul-mutlu
GitHub Series: https://github.com/Ertugrulmutlu/leetcode-series

🗓 Daily LeetCode Progress – Day 20

Ertugrul — Sun, 07 Sep 2025 13:07:44 +0000

Problems Solved:

#162 Find Peak Element
#540 Single Element in a Sorted Array

This continues my daily series (Day 20: Binary Search mastery). Reaching a 20‑day streak 🔥 feels amazing — it marks nearly three weeks of consistent problem solving and deeper intuition for logarithmic‑time patterns.

💡 What I Learned

Today’s focus was on binary search beyond the basics:

For Find Peak Element, I learned how to leverage binary search on an unsorted array by comparing nums[mid] and nums[mid+1]. Depending on the slope, we can always guarantee the peak lies on one side, allowing logarithmic search.
For Single Element in a Sorted Array, the key trick is to use the pair alignment property: before the single element, pairs start at even indices; after it, pairs shift. Adjusting mid to be even ensures clean pair checks.

Both problems highlight how binary search can apply to more than just sorted lookups — it’s about shrinking the search space with a reliable invariant.

🧩 #162 — Find Peak Element

Python (Slope check)

class Solution:
    def findPeakElement(self, nums: List[int]) -> int:
        left, right = 0, len(nums) - 1
        while left < right:
            mid = (left + right) // 2
            if nums[mid] < nums[mid + 1]:
                left = mid + 1
            else:
                right = mid
        return left

Why it works: If nums[mid] < nums[mid+1], the slope goes upward, so a peak must exist on the right. Otherwise, the peak is on the left (possibly at mid).

Time: O(log n)
Space: O(1)

C++ (Same slope idea)

class Solution {
public:
    int findPeakElement(vector<int>& nums) {
        int left = 0, right = nums.size() - 1;
        while (left < right) {
            int mid = (left + right) / 2;
            if (nums[mid] < nums[mid + 1]) {
                left = mid + 1;
            } else {
                right = mid;
            }
        }
        return left;
    }
};

🧩 #540 — Single Element in a Sorted Array

Python (Even index pairing)

class Solution:
    def singleNonDuplicate(self, nums: List[int]) -> int:
        left, right = 0, len(nums) - 1
        while left < right:
            mid = (left + right) // 2
            if mid % 2 == 0:
                if nums[mid] == nums[mid + 1]:
                    left = mid + 2
                else:
                    right = mid
            else:
                if nums[mid] == nums[mid - 1]:
                    left = mid + 1
                else:
                    right = mid
        return nums[left]

Why it works: Before the single element, pairs align (even, odd). After it, alignment breaks. Checking nums[mid] with its partner tells us which side to keep.

Time: O(log n)
Space: O(1)

C++ (Adjust mid to even)

class Solution {
public:
    int singleNonDuplicate(vector<int>& nums) {
        int left = 0, right = nums.size() - 1;
        while (left < right) {
            int mid = (left + right) / 2;
            if (mid % 2 == 1) mid--; // make mid even
            if (nums[mid] == nums[mid + 1]) {
                left = mid + 2;
            } else {
                right = mid;
            }
        }
        return nums[left];
    }
};

Why it works: By forcing mid to even, we always check pairs (mid, mid+1). If they match, the single lies to the right; otherwise, it’s at or before mid.

📸 Achievements

Find Peak Element: Understood how slope comparison can adapt binary search for unsorted arrays.

Single Element in Sorted Array: Mastered the pair‑alignment trick — a very elegant use of index parity.

📦 Complexity Recap

Find Peak Element: O(log n) time, O(1) space.
Single Element in Sorted Array: O(log n) time, O(1) space.

📣 Join the Journey

Day 20 streak achieved 🎉. This milestone marks 3 weeks of coding discipline. Each day’s problems are adding new insights into how binary search can be generalized far beyond its textbook form.

Follow along if you’re into algorithmic deep dives and clean implementations in Python and C++.

Links

LinkedIn: https://www.linkedin.com/in/ertugrul-mutlu
GitHub Series: https://github.com/Ertugrulmutlu/leetcode-series

Forem: Ertugrul

PromptLedger v0.3 — Turning prompt history into a practical review workflow.

Why a third part?

The main addition: review

From line diff to semantic summary

Why heuristics instead of an LLM?

Reviews now export cleanly to markdown

Metadata changes are now first-class in reviews

Warning flags and likely drift hotspots

The Python API now returns structured review objects

UI update: review without write access

What did not change

No schema expansion was needed

Closing

Links

DataLens: A Read-Only Image Dataset Sanity Checker

DataLens: A Read‑Only Image Dataset Sanity Checker

The Problem: Silent Dataset Failures

Why Read‑Only Matters

What DataLens Does

Mode A — Images Only

Mode B — Images + Labels (CSV)

Duplicate Detection That Actually Helps

Data Hygiene Warnings

Outputs You Can Share

Design Principles

When I Use DataLens

Final Thought

Links

PromptLedger v0.2 — Labels, Status, and Better Diffs

Why a second part?

Label history: prompts need an audit trail

Label-based diff: stop thinking in version numbers

Status command: a one-line overview

Better diff modes

UI update: history without write access

What did not change

Migration and compatibility

Closing

Links

Hysteresis in Neural Networks — Part 1

Training Order Is Not Innocent

The Core Question

Experimental Setup (Intentionally Simple)

What Happens During Training?

SAB: A → B

SBA: B → A

Accuracy Curves

SAB accuracy over epochs

SBA accuracy over epochs

A Subtle but Important Observation

Quantifying the Effect: Hysteresis Loss

Hysteresis summary

What This Means

What This Post Does Not Explain (Yet)

Reproducibility

Closing Thoughts

Links

Deterministic Decision Making in Non-Deterministic Environments: Why all my projects fight the same problem

make decisions.

The Model Fallacy

One Question, Different Layers

Same Question, Different Layers

Decision Logic: The Prompt Layer

System Design: When Correct Models Fail

Perception → Decision → Action: Timing Matters

Hardware: Constraints Shape Decisions

Data: Control the Inputs or Lose the System

This Is Not a CV

Conclusion

PromptLedger: Local-first prompt version control

Design goals

Storage and path resolution

SQLite schema

Versioning algorithm

Newline normalization

Metadata model

Labels: release-style pointers

CLI workflow

Streamlit UI (read-only)

The main addition: `review`