Ask Before Botie Creates the Inspection Job

Botie proposes inspecting pump P7. The technician approves, then a follow-up message changes the asset to P9. If the program remembers only approved = True, it may apply the old decision to a job nobody reviewed.

We need a record of the particular proposal the person saw. Then the execution service can compare that record with what it is about to do. A pause in the interface is useful only if the permission survives that comparison.

Compare the action fields, check the expiry and require the reviewer’s current permission. Change one field to see which check stops execution.

authorised for this action

Reading a manual and drafting a proposed inspection can happen before anyone grants permission to create a work order. Keep the proposal as data that a technician can inspect. The final write should be a distinct operation with a clear permission check.

Our proposal names requestId, asset, operation and revision. A real proposal would also include every consequential argument, such as timing, assignee and affected site. If a field can change what the action does, it belongs in the reviewed snapshot.

A description such as perform maintenance is too vague to bind to a later write. Show the concrete action the receiving system will get.

The approval record includes the proposal’s identity and revision, the decision, and an expiry. The service also records the authenticated reviewer and evaluates their authority. These records come from the review service, not from text generated by Botie.

If the reviewer edits a proposal, the application needs a new approved snapshot for those edited values. Do not approve the old object and quietly mutate it afterwards. Store immutable versions or compare a canonical digest of the complete approved payload.

A digest can identify a payload, but it is not a signature and it does not authenticate who approved it. The trusted server record is still required.

reviewed = {"asset": "P7", "operation": "inspect", "revision": "1"}
current = {"asset": "P9", "operation": "inspect", "revision": "2"}
fields = ("asset", "operation", "revision")
changed = [key for key in fields if current[key] != reviewed[key]]
print(changed)

['asset', 'revision']

Our toy gate requires matching action fields, an unexpired approval and a reviewer who is currently permitted. It treats a missing or mismatched condition as a request for review. The current time comes from the server; the model cannot extend expiry by supplying its own clock.

A production write should bind this check to the exact action being committed. Otherwise another request could change the proposal between checking it and creating the job. Use an immutable action version and a transaction or equivalent concurrency control in the service that owns the effect.

Approved asset = P7
Current asset = P9
Action match = false
Unexpired = true
Reviewer permitted = true
Route = request review

Remaining time and an authorised reviewer do not repair a mismatch in the action itself.

An approval can become inappropriate while a workflow waits. The pump may have been serviced already, the reviewer’s role may change, or the proposed time may pass. Decide which facts must be checked again at execution.

In this lesson, expiry is exclusive: an approval is expired at its expiry timestamp. A revoked reviewer permission also blocks the action even if the recorded decision remains yes. Keep a reason code so the interface can tell a technician whether to refresh the proposal or request another review.

Do not ask for the same decision again after a successful execution simply because the response was lost. That is an idempotency problem, which needs a stable operation identity.

Command(resume=...) delivers a value to a paused LangGraph node. The application decides who is allowed to provide that value and which pending action it refers to. A publicly reachable resume endpoint with no access check would let another person supply the decision.

Keep the reviewer identity and permissions outside model-controlled state. Check ownership of the thread and the pending review record, then pass a validated result into the workflow. Never accept a generated sentence saying that a technician approved as a substitute for that record.

The paused graph coordinates the conversation. The service that changes the work-order system remains responsible for authorisation.

After approval, the job-creation request can still time out. Use a stable idempotency key derived from the intended action identity, and have the receiving service enforce it. Reusing a key for changed arguments should be rejected rather than silently treated as the earlier job.

Test both halves: an approved unchanged action creates one job across retries, and an altered action cannot reuse the earlier approval. Also check rejected decisions and expired records. These cases often reveal more than a successful approval click.

The worksheet implements the decision gate only. A complete service also needs trusted storage, authenticated review, concurrency control and an idempotent effect.