An AI’s ability to suggest an improvement is different from permission to change a company record now. I wanted a reviewable difference and a stop when the approved basis changes.
The proposal uses fixed synthetic values. No external model is called and no company records are transmitted. Author and reviewer identifiers are trusted test inputs, not a real authentication or approval service.
A sentence is not an execution command
proposal can change only quantity and memo. It rejects attempts to alter company scope or revision. Quantity uses a bounded integer and memo uses a restricted synthetic character format. There is no natural-language execution or evaluated code fragment. The first decision is a small, explicit contract for the kind of change under consideration.
If a real model is connected, its output still cannot be trusted beyond this contract. A persuasive explanation does not replace field allowlists or authorization. The example does not evaluate model judgment quality; it implements stages for handling supplied proposal values. It does not delegate business permissions to an AI sentence.
Fingerprint the difference and its basis
A proposal contains company, expected_revision, author and diff. Each changed field has before and after values, and a no-change proposal is rejected. SHA-256 covers those values. The fingerprint helps compare the material reviewed with the material later offered for application.
A fingerprint is neither a secret nor a signature. Someone can construct new contents and hash them again, so it cannot independently establish trustworthy approval. A production service needs server-held proposal and review provenance. I describe hashing as a content-agreement tool rather than present its presence as proof of completed security.
Review leaves the original unchanged
review requires a different reviewer with the declared reviewer role and recomputes the proposal from current state. A mismatch rejects the review. Success returns a receipt value containing fingerprint, reviewer and approval. Tests verify that the original quantity is unchanged at this stage, separating agreement from application.
Role and receipt must come from trusted server context. A service allowing clients to assert reviewer or manufacture receipts is not secured by these functions. Durable review storage and access control are not implemented. Publishing the trusted-input assumption prevents a pure-function example from being mistaken for an authenticated workflow.
Invalidate review when the basis changes
apply_reviewed rechecks the same review against current state. A changed revision or altered proposed quantity fails. A valid application calculates a new copied value and revision while preserving the source; it still does not write a database. A real store must prevent two competing applications through its own conditional transaction.
Local checks reject both a changed base version and modified proposal contents after review. A cross-module scenario confirms that such failure does not erase a person’s newer draft. Approval at one moment does not become unlimited permission for later changes, and the tests exercise that principle at both boundaries.
Expand the AI role from a bounded proposal
The package includes separate proposal, review and calculated-application records with complete code. It connects no live AI service, operational approval or company mutation. Adopters can decide which differences to show and where to reconfirm them for their own workflow. The relation between reviewable content and authority matters before the model’s name.
Real integration needs authenticated reviewers, server-held proposals, a fresh version check and change history. Confirmed application and completion of external follow-up work also remain distinct. I share a reviewable proposal and bounded execution conditions rather than let “AI handles it” obscure who agreed to which change.