Judgment Boundary

The more convincing an AI answer sounds, the more carefully it should be checked. Judgment Boundary compares task and response, tests what can be verified, and shows where human judgment is needed.

Comment

Inspiration

I kept running into the same thing while testing AI output: the answers that read best were often the ones hiding a problem. Fluency, confidence, a polished surface — none of that tells you whether the response actually did what it was asked. A reply can sound excellent and still miss an explicit requirement, ignore a constraint, add something nobody requested, or point at the wrong correction.

So I started from a deliberately narrow question: did the response actually follow the assignment it was given?

I started Build Week with exactly that question. The first version I built compared a visible assignment with a visible AI response. Then, while testing it, the question got harder in a way I hadn't expected. A review could be perfectly structured, carry valid references, and still land on the wrong conclusion. That's what reshaped the project.

What it does

Judgment Boundary compares an assignment with an AI response and shows how far each finding can safely go.

The app reconstructs the visible requirements and checks the response against them, sorting each one as fulfilled, changed, missing, assumed, or conflicting. It also flags additions that were never requested and, wherever evidence is required, ties the finding to an exact excerpt from the response.

That model result then gets checked again on the server. References, evidence excerpts, evidence positions, correction items, and result relationships all have to stay consistent before anything reaches the user.

The Build Week review layer sits on top of this. Its job is to determine how far each finding can safely proceed: whether it is supported by a direct check, holds up only within clear limits, still needs a human to decide, or has to remain withheld.

Direct checks cover registered rules such as word limits, exact list counts, required or forbidden exact phrases, weekdays, ISO dates, required exact endings, and price or currency prohibitions.

You see the outcome in four separate views. Raw is the original model judgment, untouched. Machine shows what the direct checks established and where they reached their limit. Human records the decisions that still required review. Effective is what's left as usable once every check and decision has been applied.

The interface puts those four layers next to each other in one requirement-centered matrix. That makes it possible to look across a single requirement and see the model judgment, the machine evidence, the human decision, and the effective result without merging them into one answer.

When a finding still needs judgment, the reviewer can resolve it manually. With Accept with limits, the accepted part and the part that remains withheld are recorded separately instead of being flattened into a vague yes or no.

The current review state can also be downloaded as a Markdown report. It includes the assignment, the AI response, Raw findings, Machine checks, Human decisions, Effective outcomes, correction status, unresolved items, and known limits.

One thing it deliberately won't do: when a required check can't be completed safely, it doesn't quietly fall back to the original result. The affected finding remains withheld or blocked, depending on the reason. And the whole review stays anchored to the visible assignment and response — it doesn't peer into hidden reasoning, doesn't verify external facts, and doesn't pretend to settle absolute truth.

How we built it

Judgment Boundary runs on Next.js and TypeScript. OpenAI models handle the first stage of the review by reconstructing the assignment requirements and returning structured review candidates.

Even the first Build Week version leaned on a strict result contract: every finding had to point to a requirement, use an allowed status, supply evidence where evidence was required, and stay consistent with its own correction items and guidance. That gave me dependable structure. What it didn't give me was correctness — the judgment living inside that structure could still be wrong.

The second layer, added as the project evolved during Build Week, is what addresses that. It leaves the original model result untouched and evaluates each finding on its own. Anything directly measurable gets checked against deterministic rules; anything that can't be confirmed that way goes to a manual review step or remains withheld.

Manual review uses signed, stateless tokens. Each sequential decision is validated against the original assignment, the response, the model result, the guidance, and the current review state, so the client can't silently drop or overwrite an earlier decision.

The final interface organizes the result by requirement across Raw, Machine, Human, and Effective columns. Longer reasons, evidence, and technical details are still there, but they stay folded away until the user opens them.

The review itself is not stored in a database. Instead, the user can download the current state as a client-generated Markdown report. That kept the submitted version stateless while still giving the reviewer something inspectable and archivable when the browser session ends.

Codex did a lot of the heavy lifting across Build Week — combing through the repository, implementing the new layer, writing tests, tracing failures, repairing the Guided Check, building signed manual review, adding Accept with limits, creating the Markdown export, reshaping the result interface, and running audit after audit.

GPT-5.6 sat inside the product workflow from the other side. It helped turn the product idea into explicit contracts, reviewed implementation work, analyzed failed live outputs, designed controlled comparison cases, and kept pulling apart model judgment, machine verification, human review, and the final effective result.

The calls that actually shaped the product, the engineering, and the design stayed with me, though: fail-closed behavior, splitting the result into Raw, Machine, Human, and Effective, drawing the limits of direct verification, keeping the original model judgment intact instead of rewriting it after the fact, deciding what belonged in the public Build Week version, and deciding what did not.

Challenges

The hardest part didn't show up until I already had a version that worked. Valid schemas, internally consistent evidence references, well-formed structured output — none of it told me whether the judgment underneath was actually right.

That became obvious once I ran several OpenAI models against the same review contract. They didn't just vary at the margins; they reconstructed different requirements, flagged different unsupported additions, and occasionally landed on conclusions that contradicted each other. One model returned a completely valid result while insisting the response had blown past a 180-word limit it hadn't. Another read a vague closing sentence as a clear next step. Both sailed through every structural check I had, which is exactly what worried me — a result could satisfy the whole contract and still be wrong.

So the next question was what to do when the app simply couldn't confirm a finding. The tempting option was to leave the original model judgment in place; the interface would look finished and complete. But it would also be quietly papering over uncertainty, so I went the other way. Missing checks, invalid review state, incomplete evidence, a processing failure — any of these now stays visible and keeps the affected result withheld instead of resolving it on faith.

A separate audit workflow caught places where fail-closed behavior was missing, cross-object checks were incomplete, and manual-review tests had gaps. It also caught smaller things that looked harmless until they blocked the actual workflow — like a Guided Check requirement that could be added by mistake but not removed, or an Accept with limits decision whose text disappeared after submission.

The audit also surfaced a known transitive PostCSS advisory inside Next.js. I traced the relevant data paths and found no route by which user or model text could reach the affected CSS processing path. The remaining upstream risk is documented in the repository.

What we learned

Passing the schema tells you the output is well-formed. Whether the judgment behind it holds up is a separate question the schema never touches — structured output makes a result easier to inspect, but it can't prove the conclusion is right.

Evidence turned out to work the same way. An excerpt only helps if it actually covers the full scope of the finding. A short phrase might be enough to justify a narrow observation and still fall well short of supporting a claim about the whole response.

The bigger lesson was that uncertainty needs a state of its own. A system should be able to say, plainly, that a claim was checked, or supported only within limits, or left for a human, or withheld — and those shouldn't get blended back into one smooth answer.

The audit pushed me toward the same conclusion from a different direction. A big green test count is worth something, but it's one piece of evidence, not the verdict. For the record, the final Build Week build cleared 506 automated tests across 26 test files, along with linting, production build checks, and contract checks. It also came through a separate audit workflow with one upstream dependency risk documented.

How the project changed

Judgment Boundary was created during Build Week. Before the event, there was a product idea and separate internal research, but there was no existing Judgment Boundary application.

The first Build Week version could reconstruct requirements, compare them against an AI response, validate the returned structure, and produce findings, correction items, and guidance.

Then the model comparisons exposed the deeper problem. A result could satisfy the full structural contract and still make the wrong judgment. That is what led to the Claim Boundary layer.

The new layer keeps the original model result intact, checks directly measurable claims, sends unresolved judgments to human review, and keeps Raw, Machine, Human, and Effective outcomes separate instead of merging them.

Later Build Week iterations added signed sequential review, Accept with limits, fail-closed correction gating, the requirement-centered comparison matrix, a repaired Guided Check flow, and a downloadable Markdown review report.

The model comparison is what drove all of it. The models were genuinely useful — but their confidence and their tidy structure couldn't stand in for proof, and Judgment Boundary is where I made that limit visible inside the product instead of hiding it.

What is next

Right now the focus is assignment adherence and the checks that can be done from the visible task and response alone.

From here I want broader evaluation across models and task types, more complete review-session persistence, and a carefully bounded form of external verification for claims that can't be settled from the supplied text.

External verification is switched off on purpose in this version. Turning it on means building its own evidence rules, source handling, provenance controls, and review boundaries first, and I'd rather do that properly than bolt it on.

The aim underneath hasn't moved. Check whatever can actually be checked, hold back wherever the text doesn't support a conclusion, and make it obvious when a person still has to decide.

Built With

Share this project:

Updates