An AI agent approval workflow failed inside Eclipse Control Room at the approval boundary. A review carried a Reject recommendation, yet the journal could record approve.
The evidence comes from Nocturnal's internal product development. No client system or customer result is involved.
Three values traveled through the review: decision, rationale, and recommendation. The system treated them as loosely related text. Each value could look valid by itself while the combined record contradicted the review.
Proof scope: Internal product-development evidence checked July 28, 2026. The diagram reproduces the sanitized decision path and settled test counts. It makes no client-outcome claim.
The expected invariant
The workflow needed one enforceable rule:
Without an explicit, valid override, the journaled decision must equal the authoritative recommendation.
A Reject recommendation should produce a rejected journal entry. An approval can proceed only through a deliberate exception path with a distinct rationale and intact provenance.
That rule has to hold across the review screen, the submitted payload, backend validation, and the durable journal entry. A correct label in one layer cannot compensate for a contradiction in another.
The observed failure
The review artifact carried a clear Reject recommendation and a rationale explaining why the work should stop. The decision field could still carry approve. The journal accepted the approval because it validated the fields as separate pieces of text.
The renderer showed a recommendation. The form submitted a decision and rationale. The backend checked that expected text existed. No layer declared which field had final authority when the values disagreed.
That left a narrow but serious path through the workflow:
- The review recommends rejection.
- The submitted decision says approve.
- The rationale remains plausible in isolation.
- The journal records approval.
The record was complete according to field-presence checks. It was contradictory according to the approval contract.
Why the checks missed it
The original checks covered decision presence, rationale presence, recommendation presence, and journal serialization.
They skipped the system-level agreement check. The values could describe contradictory decisions and still pass.
Three gaps let the contradiction survive.
First, the workflow checked presence rather than agreement. A well-formed approve string passed even when the authoritative review said Reject.
Second, override intent had no separate contract. A caller could add Override: to text while leaving the recommendation unchanged. The label looked deliberate, but the data still described the original rejection.
Third, provenance and digest checks were split across projections. The renderer could display one representation while the backend validated another. Tests covered each projection's happy path without forcing both layers to prove they were bound to the same evidence.
The business consequence
An approval journal is a business record. Teams use it to release work, move a queue, send a message, change a system of record, or authorize the next automated action.
If the recorded action can contradict the recommendation that produced it, the journal cannot prove what the reviewer approved. An operator sees approve. The underlying review says Reject. Downstream software follows the journaled state.
That creates four practical costs:
- unsafe work can move forward;
- auditors receive a misleading decision history;
- incident review loses a reliable account of reviewer intent; and
- teams spend time reconciling the screen, payload, and backend record.
The impact scales with authority. A contradiction in a draft queue creates cleanup. The same defect beside customer messaging, access changes, publishing, or spend creates direct business exposure.
The implemented repair
The repair turned recommendation, override, provenance, and digest into one approval contract.
Recommendation became authoritative by default
The backend now derives the normal decision from the authoritative recommendation. Approve follows Approve. Reject follows Reject. A caller cannot reverse that result by supplying a conflicting decision string.
Rejection became the primary action
When the recommendation is Reject, the renderer presents rejection as the primary path. Approval moves behind the explicit override flow. This reduces accidental approval and makes the exception visible to the reviewer.
Override gained a distinct rationale
An approval against a Reject recommendation requires a separate override rationale. It must explain why the reviewer is departing from the recommendation. Reusing the recommendation rationale fails because it supplies no decision-specific reason for the exception.
The literal prefix Override: carries no authority. A request that adds the prefix while preserving the unchanged Reject recommendation is rejected.
Provenance became mandatory evidence
The validator rejects requests when the review provenance is stripped or changed. The decision must remain attached to the evidence the reviewer saw. A payload cannot substitute a different source description after review and keep the approval valid.
Renderer and backend share the authoritative digest
Both layers were rebound to the authoritative digest. The renderer uses it to identify the review shown to the human. The backend uses the same digest when validating and journaling the decision.
That closes the projection gap. The system now binds the visible review and the durable decision to the same evidence.
Adversarial tests that now define the boundary
The repair was tested against contradictions rather than polished examples. The sanitized verification summary is 101 renderer tests passed and 12 backend tests passed.
| Adversarial case | Required result |
|---|---|
Recommendation is Reject, submitted decision is approve, and no override is present |
Reject the request |
Rationale starts with Override: while the recommendation remains unchanged |
Reject the request |
| Override rationale copies the recommendation rationale | Reject the request |
| Review provenance is missing | Reject the request |
| Review provenance changes after the review renders | Reject the request |
| Renderer and backend receive different digests | Reject the request |
Reviewer accepts the Reject recommendation |
Journal rejection |
| Reviewer explicitly overrides with a distinct rationale and intact provenance | Journal the approved override |
These cases matter because each one attacks a relationship between fields. Conventional form tests usually prove that a field accepts a value. Approval tests must also prove that the values agree, or that the exception is explicit and traceable.
Evidence receipt: The left side reproduces assertions from the current Control Room execution-packet test. The right side records a fresh July 28, 2026 run: 101 Node tests passed with zero failures, and 12 backend tests returned OK. Source and test hashes are embedded in the SVG source. No client data appears.
What the repaired workflow guarantees
The repaired workflow has two legitimate outcomes.
The first follows the recommendation. The journal records the recommended decision against the same provenance and digest shown during review.
The second records an override. The journal preserves the original recommendation, the review rationale, the reviewer's contrary decision, the distinct override rationale, and the authoritative provenance.
The old workflow allowed contradiction to hide inside plausible text. The repaired workflow turns disagreement into a named, testable state.
A five-check buyer diagnostic
Use this diagnostic during a vendor demo or acceptance review. Score one point for each check the system can demonstrate with a controlled test. A production approval boundary needs all five.
- Authority check: Set the recommendation to
Rejectand submitapprove. The system should name the authoritative field and block the conflicting decision. - Override check: Attempt a deliberate approval against
Reject. The system should require a separate override action and a distinct rationale. - Provenance check: Remove or alter the review provenance after rendering. The submission should fail before journaling.
- Digest parity check: Compare the digest tied to the visible review with the digest validated by the backend. They should identify the same authoritative evidence.
- Adversarial evidence check: Ask for test results covering contradiction, prefix-only override, copied rationale, provenance tampering, digest mismatch, rejection, and a valid override.
A polished approval screen is not proof that the recorded decision matches the recommendation. Use the checks above when recommendation, decision, override, and provenance can disagree. For the wider operating boundary around ownership, fallbacks, logs, and stop conditions, run the AI agent handoff test.
When to repair the workflow
Run this review before adding more agents, tools, or write permissions. Start when any of these conditions appears:
- recommendation and decision can disagree;
- override intent lives in free text;
- reviewers cannot tell which evidence the backend will journal;
- provenance can disappear between review and submission; or
- front end and backend tests use different fixtures or digest inputs.
Nocturnal's AI Agent Workflow Repair service is designed for this class of failure. The fixed-term engagement traces the authority rule, rejection path, override contract, provenance, digest parity, journal transition, and adversarial acceptance tests.
What to measure after the repair
Do not reduce the repair to a green test count. Track the operating boundary after release.
| Measure | What it reveals | Healthy direction |
|---|---|---|
| Recommendation-decision contradictions presented | Whether incompatible states still reach review | Zero unhandled contradictions |
| Invalid overrides blocked | Whether the exception path is actually enforced | Every weak override blocked before journaling |
| Valid overrides with distinct rationale | Whether reviewers can still make accountable exceptions | Present when needed, always source-bound |
| Digest or provenance mismatches | Whether visible and durable evidence drift apart | Zero journal writes from mismatched evidence |
| Decision reconstruction time | Whether an operator can replay who approved what and why | Falls as receipts become complete |
BrandLab can evaluate whether an artifact follows a brand or evidence contract. Eclipse Control Room owns the separate authorization decision and journal. Keeping those jobs distinct prevents a quality score from quietly becoming permission.
Sources and methodology
This article is based on named, inspectable evidence from internal Eclipse Control Room product development. The evidence includes the review contract, rendered recommendation, submitted decision and rationale, approval journal transition, provenance rules, digest binding, and adversarial test results.
The test totals are sanitized suite summaries. They state only the completed result: 101 renderer tests passed and 12 backend tests passed. This article omits private identifiers, source locations, hashes, and internal execution records.
No client work, customer incident, testimonial, or revenue outcome is represented here. The technical conclusions come from the internal failure and repair. Google Search Central's guidance on helpful, reliable, people-first content informed the publication method and disclosure, rather than the approval architecture.
AI agent approval workflow FAQ
Bring us the contradiction
If your agent's recommendation, decision, and journal can disagree, Nocturnal can map the authority rule and repair the control boundary. We bind the digests, test the failure paths, and deliver the work through a fixed-term workflow repair engagement.
Repair the Approval Boundary
