Skip to content
Protocolzone Protocolzone

Engineering

AI-generated proposals need an approval path

· Protocolzone

A language model can turn source material into a plausible proposal. The harder engineering question is what permits that proposal to enter the business system.

In an AI integration we have implemented, generation, review and publication are separate steps. This article describes the implementation and its test coverage in source; it is not a claim of a customer production rollout or a measured business result.

Generation creates a review item

The generator stores a draft with a pending-review status. Creating the draft does not publish it to the platform. That separation gives the application a place to validate the response and a person a place to make a decision.

The stored evidence includes the source item, the prompts used and the raw model response. Keeping those inputs matters: reconstructing a prompt later from the current code does not establish what the model saw when it produced the answer.

Approval is a state transition

The review operation records an approver identifier and changes only a draft that is still pending. If two reviewers act on the same item, the guarded update lets the application detect that the other decision has already happened.

Rejection is retained rather than deleting the item. When the same source is encountered again, the existing decision can be recognised instead of placing the rejected proposal back into the queue.

This workflow also needs an authenticated identity boundary before operational use. A supplied actor label is not proof of identity. The reviewed module keeps its administrative access closed by default while that integration is completed.

Publishing has its own failure handling

A separate publisher selects approved items. It waits for the message send to succeed rather than assuming that handing a message to an asynchronous client means the platform received it.

A failed send leaves the approval available for another attempt. Stable proposal identifiers support downstream duplicate handling. This is a retry design, not a blanket promise of exactly-once delivery across a database and message broker.

Test the boundary, not just the prompt

The source includes tests for pending drafts being withheld, approval requiring an actor, conflicting decisions, rejected drafts and failed message sends. These exercise the workflow around the model; they do not establish model accuracy or replace deployment validation.

The lesson is practical: specify what AI may propose, who may approve it, what evidence is retained and how interrupted work resumes. Those decisions are part of the implementation, alongside the model and its evaluation.

Discuss AI inside your existing workflow.

  • ai-implementation
  • human-review
  • event-driven-systems

Written by

Protocolzone

Engineering team

Platform and data engineering team behind Ashva, AnkEDGE and AmshPOS.

Got a version of this problem?

We would rather talk through a real architecture than send a deck.