DEV Community: Alain Tural

Approval Is Not Publication

Alain Tural — Tue, 15 Sep 2026 22:58:56 +0000

The step everyone builds, and the step that actually moves work

The standard architecture for putting AI into a business is easy to draw. Data
goes to an agent, the agent produces a recommendation, a human approves it, the
action happens.

We built exactly that. Then I looked at the queue and found 37 pieces of work
sitting in it. Thirty one waiting for review, five with revisions requested, one
approved.

One approved, and nothing published.

The missing edge

The diagram has four boxes and everyone builds the first three. Data collection
is satisfying to build. The agent is the interesting part. The approval interface
is visible, so it gets attention and it gets a nice table.

The last arrow, from approval to action, is plumbing. It is also the only part
that produces an outcome. Without it, an approval queue is a place where
finished work goes to be admired.

We changed the meaning of the button. Approval is now a publish instruction, not
a status. When a reviewer approves, the item is handed to Postiz, the scheduler
that owns the calendar. If that
handoff fails, the failure is loud. Nothing sits in a green state while doing
nothing.

Why this happens

I think the reason is that approval feels like completion. A human looked at the
thing and said yes. Psychologically the work is done, so the system gets designed
around reaching that moment rather than passing through it.

There is a second reason that is less flattering. The approval step is where
responsibility transfers, and a queue full of approved items that never shipped
is nobody's fault in particular. The system has no owner for the last arrow.

What to check in your own setup

Count the items that have been approved and ask what happened to each one. Not
the approval rate, the outcome. If those two numbers differ, the gap is your real
throughput and nothing upstream of it matters.

Then check the reverse case. When the action does fire, does anything verify that
it landed? Our Postiz instance went quiet once without raising an error. Posts stopped going
out, the interface reported normal operation, and restarting the worker did not
bring the schedule back. Nothing was checking the destination, only the send.

An operator that recommends is a chatbot with a table in front of it. An operator
that acts, confirms the action landed and complains when it did not, is the thing
worth building. The difference is about twenty lines of plumbing and it is the
only part that pays.

A Task Without A Check Command Is Not Automated

Alain Tural — Tue, 15 Sep 2026 22:53:45 +0000

What eight stages of automated production taught me about the limits of agents

Our production line has eight stages and moves an idea to working software:
research, architecture, task breakdown, build, review, human approval. Multiple
engines run in lanes underneath it, chosen per task.

The rule that keeps it alive is one sentence. If a task has no command that
verifies its output, that task does not enter the pipeline.

Why the rule exists

An agent can produce something for almost any instruction. The output arrives and it looks plausible. Plausible is where the trouble starts. Without a verification
command there is no difference between finished and abandoned, so the pipeline
advances on the appearance of work.

The check does not have to be clever. A test suite, a build that must compile, a
parser that must not throw, a count that must match a known figure. It has to be
mechanical and it has to be able to fail.

Tasks that cannot be checked mechanically still exist in our work. Judgement about
tone, a design direction, whether a client will accept something. Those do not go
into the pipeline. They go to a person, and pretending otherwise just moves the
failure later.

Engines are not interchangeable

We run several engines and route work by lane. I assumed the routing could be
naive, and it could not.

One engine cannot run our verification commands at all in its sandbox, so every
task with a gate attached silently fell back to another lane and consumed a turn
doing nothing useful. Another engine cannot read from disk, which means it cannot
see the existing code, which means giving it a modification task produces a
confident rewrite of something it never saw.

Both of those look like model quality problems in the output. Neither is. They
are routing problems, and they are only visible if you measure which lane did the
work and whether that lane could physically do it.

The limit I keep running into

The pipeline is good at anything with a mechanical definition of done. It is
useless at deciding what is worth doing, and it degrades quietly when the
definition of done is soft.

That is the honest boundary of an agentic setup today. Not the model's
reasoning, and not tool access, which is now routine. The boundary is how much of
your work can be stated as a condition a machine can check. In our case that turned
out to be most of the production and almost none of the direction.

A Gate The Model Writes Is A Gate The Model Loosens

Alain Tural — Tue, 15 Sep 2026 22:48:34 +0000

Three ways our automated quality checks passed while the work was broken

Our production line runs in stages with quality gates between them. Research,
build, review, publish. A stage cannot advance until its gate returns green. That
architecture is correct and I would build it again. It also gave me the three
most expensive failures of the year, all of the same shape: the gate was green
and the work was wrong.

One: the gate could not see the data

We had a check that verified our published archive for anachronism, meaning an
article dated before a tool existed cannot mention that tool. It returned clean.

Clean meant nothing, because I had not verified that the check could match
anything at all. When I instrumented it, the term table did match: 26 terms and
over 340 occurrences across the corpus, with no violations. That was a real pass.
But it was luck that I checked, and a green light from a rule that cannot see the
data is worse than no rule, because it stops you looking.

The gate now warns when zero terms match. A check that finds nothing has to say
whether it found nothing or saw nothing.

Two: the gate had a rule that rewarded gaming

An early quality gate asked whether the output existed and had the required
sections. Output always existed. Sections always appeared. The gate was
satisfiable by producing the shape of the work rather than the work.

When a model writes its own gate, this is the default outcome, not the edge case.
The gate gets written to be passable, because passing is the visible objective.

We changed how we test gates. Every gate now gets a deliberate violation injected
before we trust it. If the red light does not come on, the gate does not exist.
The anachronism check above was verified that way: a fabricated article dated
January 2024 mentioning a model released in August 2025, plus a link pointing
forward in time. Both rules fired, exit code 1.

Three: the counter said there was capacity

Our pipeline tracks engine quota locally so it can pick a lane. The counter said
capacity was available. The engine had been failing silently for some time, and
the pipeline kept assigning work into a lane that could not run it.

A local counter is a model of a remote system, and the model drifts. Any counter
maintained on your side of a network boundary needs to be reconciled against the
thing it claims to describe, or it will report health for a dead component.

What these have in common

None of these failures were visible in the output at the moment they happened.
They were visible only in the distance between what the check claimed and what
the check could actually observe.

If you take one thing from this: a rule being written down is not the same as a
rule being enforced, and the only way to know which one you have is to break it
on purpose and watch what the system does.

The Scoring Model Was Wrong And It Put The Worst Lead First

Alain Tural — Tue, 15 Sep 2026 22:40:16 +0000

What ranking 2,163 companies taught me about turning data into decisions

Most companies are not short of information. They are short of an interpretation
layer, and the interpretation layer is where the mistakes hide.

We built one this month and it failed in a way worth describing, because it
failed quietly and it looked correct while it failed.

The job

We had 2,163 companies in one US sector and needed to know which ones to
approach first. Two axes matter: can they pay, and do they have a problem worth
paying to fix. We measured both from public signals. Domain age, sitemap
presence, last publication date, mail provider, registry filings, site condition.

Coverage was uneven and we recorded that rather than smoothing it over. Mail
provider resolved for 95 percent of them. Domain age resolved for 24 percent.
Sitemap data existed for 12 percent.

The first failure was in the measurement

The 24 percent figure bothered me, so I sampled it. Of five companies marked
unmeasurable, four had archives going back more than a decade. One went back
twenty two years. The data existed. We had run eight parallel workers at the
archive and been throttled, then recorded the throttling as absence.

We reran it with two workers and waiting periods. Coverage went from 24 percent
to 88 percent. My time estimate for that rerun was fifteen minutes. It took 179.

The lesson is not about workers. Not measured and does not exist are two
different findings, and a pipeline that collapses them will report confident
nonsense.

The second failure was in the ranking

I scored the companies with a weighted sum. Ability to pay, plus severity of
problem, plus supporting signals.

The top of the list came back with a company scoring 100 on ability to pay and 3
on severity of problem. It ranked in the top twenty. A business with money and no
problem had been placed at the front of a sales list, because a high score on one
axis carried a near zero on the other.

A sum lets one axis substitute for the other. That is exactly wrong here, since
both have to be present or there is nothing to sell. Changing the core to the
square root of the product fixed it. The same company dropped to 40 points and
position 119.

What the data said once it could be trusted

1,680 of 1,912 measured companies have no sitemap
76 have a blog
205 show any publication date, ever
1,293 use Google Workspace or Microsoft 365, so these are real operating firms

Almost nobody in this sector publishes anything. That is the finding, and it only
became visible after the measurement layer stopped lying to us twice.

The part that generalises

An intelligence layer is not a dashboard. It is a set of claims about reality, and
each claim can be wrong in two directions: the data can be missing, or the maths
on top of it can be shaped so that a missing value looks like a good one.

Both failures here were mine, both looked like working software, and neither
would have surfaced without going back and sampling the rows the system had
already given up on.

Building Software Got Easy. Getting Value Out Of It Did Not

Alain Tural — Tue, 15 Sep 2026 22:39:40 +0000

What Aristo taught me about the gap between shipping and mattering

Building a working product is no longer the expensive part. I know this because
I built one. Aristo started as ChamberOne, a business communication platform that
answers customer questions from a company's own material, and it runs today as a
widget on a client's live production site. The build was fast. Everything after
the build was not.

That gap is the whole story, and almost nobody writes about it honestly, because
the build is the part that photographs well.

The measurement that changed how I work

When we took over a client's digital operation last year, I ran an inventory
before touching anything. The site had no analytics, no tag manager, no search
console verification, no pixel of any kind. Three plugins were installed and two
of them were inactive. The company had been publishing for months into a channel
nobody was reading, and nobody had noticed, because there was nothing in place
that could notice.

At the same time, our own publishing queue held 37 pieces of content. Thirty one
were waiting for review. Five had revisions requested. One was approved. Approval
existed. Publication did not. We had built the approval step and skipped the step
that makes approval mean something.

Neither of those problems was a software problem. Both were expensive.

What the sector looks like when you measure it

I wanted to know whether this was one bad case or a pattern, so we measured it.
We pulled the full web presence of 1,912 companies in one US business sector:
domain age, sitemaps, publishing history, mail infrastructure.

1,680 of them have no sitemap at all
76 have a blog
205 show any content publication date, ever
1,293 run corporate email, so these are operating businesses with staff and invoices, not shells

An entire sector of functioning companies publishes nothing. The tooling to fix
that has been cheap and available for two years. The tooling was never the
constraint.

Speed is a product decision, not a rendering decision

The same pattern shows up inside the engineering. We had a 3D product
configurator that looked correct and took about ninety seconds to produce a
result. Ninety seconds is not slow in rendering terms. It is fatal in product
terms, because nobody waits.

The fix was not a faster renderer. We moved the lighting out of the runtime and
baked it, then treated each option as an albedo swap. The same visual result now
arrives in about three seconds. Nothing about the model improved. We stopped
asking the machine to compute something at the worst possible moment.

Where the difficulty actually moved

Building Aristo took weeks. Getting a business to route its customers through it,
maintain the material behind it and trust the answers it gives is still in
progress, and that work has no shortcut. The technical barrier fell. The
behavioural barrier did not move at all.

This is why I am sceptical of AI product claims that lead with capability. A
capability demo tells you what the model can do in a controlled request. It tells
you nothing about what happens when a real company puts its name behind the
output, and that is the only question that decides whether the product survives.

The next generation of technology companies will not win on model access.
Everyone has model access. They will win on understanding why an organisation
with a working tool still does not use it.