Implement and Verify an AI-Assisted Change Against a Model

A coding agent can produce a convincing patch while missing the property that motivated the change. Revision checks can run outside a transaction. A receipt can be saved only after a remote write, leaving a crash window. A retry helper can turn an unresolved operation into a second publication.

Use the agreed model as a review map: connect each important transition to implementation evidence and a check that could fail. Tests and diagrams help different parts of that review; neither removes the need to inspect the code and its operating assumptions.

Define the change and the evidence

The teaching system is a release-note agent. Its new publication path accepts an authenticated maintainer's approval of a draft revision, captures the approved text, reserves one operation, and sends that snapshot through a gateway. A timeout after sending remains unresolved until the outcome is established. The application is fictional; the examples below are implementation sketches, not a runnable library or a claim about a particular provider.

Before editing, record the inspected code commit and the agreed model reference. Ask the implementer to identify the actual handler, persistence boundary, worker or dispatch path, and adapter. If the model assumes an immutable revision table but the code overwrites a single text field, resolve that mismatch before building more code on top of it.

Separate two questions: does the model describe the intended policy, and does the patch implement that policy? A perfectly matching patch can still implement a poor decision.

Implement the local decision atomically

Start with the local state transition. The following pseudocode assumes reserve_approved_snapshot performs the existing-operation lookup, revision comparison, immutable snapshot capture, and unique reservation in one database transaction. Naming the method does not provide those guarantees; review its implementation.

def request_publication(actor, command):
    authorize_publication(actor, command.tenant, command.target)
    return store.reserve_approved_snapshot(
        tenant=command.tenant,
        draft_id=command.draft_id,
        expected_revision=command.revision,
        target=command.target,
        request_id=command.request_id,
        approved_by=actor.id,
    )

The store returns the previously reserved operation for an equivalent repeat, rejects identity reuse with different parameters, and rejects a stale first approval. A uniqueness constraint on tenant, draft, revision, and target enforces this example's “one publication intent per approved revision and target” policy even when clients send different request IDs. Choose a different business key if your product intentionally allows repeated publication.

Also retain the immutable payload, approver, operation identity, and state. Do not regenerate release text during delivery. That would make the published content differ from what the person approved.

Separate reservation from delivery

A dispatch worker claims a reserved operation using concurrency control. A typical state progression is reserved → dispatching → published. A definitive rejection can lead to rejected; an ambiguous delivery leads to unresolved. A repeated client request reads this state rather than independently dispatching.

Do not hold a database transaction open across an arbitrary remote call to suggest that both systems share one transaction. They do not. If a worker crashes after the host applies the write but before the local receipt is stored, a dispatching record is left behind. Recovery must treat it as potentially applied.

Stable downstream identity, bounded retries, claim expiry, and reconciliation depend on the host's actual guarantees. A claim that expires while the original worker is still running can permit another worker to dispatch. A verified remote idempotency contract or an appropriately conservative recovery design must cover that window. A local lock alone is insufficient.

Choose checks that could expose the bug

Evidence for the model's critical boundaries

Property	Focused check	Limit of that evidence
Only an authorized maintainer can approve	Handler test with an unauthorized actor; no reservation occurs	Also inspect production authentication and tenant scoping
An edit before acceptance makes approval stale	Store integration test with controlled transaction ordering	An in-memory fake cannot establish database isolation
An edit after acceptance cannot change the payload	Capture revision 7, write revision 8, assert delivery uses revision 7	Does not cover all schema or migration errors
Concurrent approval creates one operation	Race two real store transactions and inspect persisted operations	Does not by itself prove one remote effect
A lost response does not create a fresh intent	Fake host applies the write then raises a timeout; repeat the request and inspect identities	The real host's deduplication and lookup still need contract checks
Interrupted delivery is recoverable	Restart between external application and receipt storage; reconcile the existing operation	Needs realistic persistence and a controlled environment

For the lost-response test, a fake that throws before doing anything is too weak. Make it record the side effect first. The assertion should cover the returned state, durable operation identity, and absence of a fresh publication intent. Add provider sandbox checks only where authorized and available; report unavailable checks as unverified.

Generated prose quality needs separate evaluation. Verifying snapshot delivery says nothing about whether a release note accurately summarizes a commit. Review representative generated drafts against source changes without mixing that evaluation into the deterministic approval tests.

Review the diff and report limits

Walk the model in both directions. For each critical step, locate the implementation. For each new durable write or external call in the diff, explain its place in the model. Look for hidden adapter retries, new privileges, and migration behavior that the sequence does not show.

Require an evidence report that distinguishes checks actually run from checks merely proposed. Include the code commit, model reference, commands or test identifiers, observed results, and remaining provider assumptions. “Tests pass” is not enough when the important integration test was skipped.

GitHub's responsible-use documentation for its agentic features describes reviewing and validating generated outputs. The same review discipline is useful here, without implying that any particular assistant is integrated with Unograph.

Try it in Unograph

In Unograph, trace approval through the store to the gateway, then trace the lost-response scenario. Beside your task, map each of those transitions to a real symbol and a check result. Investigate any new external call in the patch that has no corresponding modeled interaction.

Model Failure Paths Before an AI Agent Implements Them explains how to choose the scenarios. Continue with Keep Architecture Models and Code Aligned with an Explicit Task to maintain this evidence as implementation changes. The release-note agent learning path links all five lessons.