The hidden cost of implicit preconditions in AI prompts

The problem nobody talks about

You write a prompt to an AI. It looks correct.
It's clear, detailed, well-structured. And yet
the output is inconsistent — sometimes it does
what you want, sometimes it doesn't, and you
can't figure out why.

The issue usually isn't the model. It's a
structural problem in how natural language
communicates intent.

The two-step instruction problem

Consider this instruction:

"If the product is not in the catalog,
tell the customer we don't have it."

Simple, right? But this single sentence
actually contains two steps:

Precondition: search the catalog and confirm the product is absent
Behavior: reject honestly

Natural language compresses both into one
sentence. Humans read it and instantly
understand the implied sequence.
AI models don't always.

Depending on the architecture, the model might:

Execute the rejection without checking first
Check but apply the rule in the wrong order
Resolve the ambiguity differently each time

The instruction was ambiguous before any
model ever read it. The model just revealed
the ambiguity.

Why this matters more than you think

Every time you write a prompt with an
implicit precondition, you're betting that
the model will infer the correct sequence.

Sometimes it does. Sometimes it doesn't.
And when it doesn't, you spend hours
debugging what looks like a model failure
but is actually a language failure.

Examples of implicit preconditions hiding
in plain sight:
"Only show the checkout button if the cart
is not empty"
→ Precondition: verify cart state FIRST
"Send a confirmation email after the user
registers"
→ Precondition: confirm registration SUCCESS first
"Reject the request if the user doesn't
have permission"
→ Precondition: check permissions BEFORE processing

All of these look unambiguous. None of them
explicitly tell the AI to verify the condition
before acting.

The solution: make preconditions explicit

What if preconditions weren't buried inside
natural language instructions? What if they
were a first-class citizen of the protocol?

That's the core idea behind the !! operator
in NEXUS — a minimalist Human-AI communication
protocol I've been building.

Instead of:
"Process the checkout if the cart is not empty
and the user is authenticated and stock is available"

You write:

Endpoint POST /checkout
  !! "Cart cannot be empty"
  !! cart.items.length > 0
  !! user.authenticated
  => OrderService.create()
  !error:400 -> /error/validation
  !error:401 -> /login

The model doesn't decide whether to reject.
It generates a response on the happy path,
and the protocol handles absence elsewhere.

The preconditions aren't instructions the
model interprets. They're contracts the
protocol guarantees.

What this changes

When preconditions are explicit:

A human can audit intent without running the model — just read the !! lines
The model has no decision to make about sequence — it's already encoded in the structure
Architecture sensitivity disappears — MoE or Dense, the structure is the same
Debugging becomes trivial — if something fails, you know exactly which precondition wasn't met

The asymmetry that makes it work

NEXUS separates two things that natural language
conflates:
!! precondition → what must be true to continue
!error:code → what to do when something fails

Preconditions fire before. Errors handle after.
The model never has to figure out which layer
it's in.