An agent may have figured out the correct identity.
It may have been based on current and canonical knowledge.
It may have set the option that really suits the user's need.
Valid consent, authority and approval can also be found.
Despite all this, action can again be wrong.
Because:
The right decision is not a guarantee of proper execution.
The agent can find the correct customer address, but only update the CRM record and leave the shipment system obsolete.
It can calculate the correct return amount; but it can apply the payment to another customer's order.
A API can receive the answer HTTP 200; however, the method and API may miss out on the fact that the real-world result of the successfully processed request is not yet complete.
When the network response is delayed, it can make the same payment a second time.
They can publish five of the six languages and consider the entire publication complete.
It may not rely on the "successful" message of the file transfer tool and check what is actually found in the live system.
It can proceed without understanding at what point the process cannot be undone.
It can use overly personal, commercial, or confidential data for a simple task.
And in the end, there may be no record of what they did, who they did it for, and what evidence they were based on.
Driving is not just running a command.
Each action carries at least the following questions:
On which system? What target? With what data? How many times? On what completion? With what independent verification? By what means of return? Under what record?
The nine errors in this section examine the deterioration of valid authority due to the wrong system, wrong target, incorrect success interpretation or incomplete executive discipline.
GBO-ERR-046 — Performing the Right Action in the Wrong System
Brief case
A customer would like to change the delivery address of their order, which has not yet been shipped.
It instructs the customer service agent to:
"Send my order to my new office address. I no longer have access to the old address."
The agent confirms the client's identity.
Gets the new address in full.
Opens the customer card on CRM system and updates the address.
Then they give the customer this answer:
"Your delivery address has been successfully changed."
However, the delivery address is not taken from CRM while the order is being prepared, but from a separate record in the order management system.
The new address appears at CRM.
The shipping system continues to carry the old address.
The package is sent to the address where the customer can no longer access it.
The agent used the correct information for the right customer.
However, they did not apply the change to the system that actually governs behaviour.
What appears correct on the surface
CRM has an "address" field.
The customer card has been successfully updated.
The system has not made any errors.
New address appears on the agent's screen.
Therefore, the process appears to be complete.
But the same fact can be found in different systems:
Contact address at CRM,
delivery address in the order system,
Legal address in the billing system,
Shipping address at the cargo provider.
Just because domain names are similar does not mean that their function is the same.
The actual failure
The breached gate is the System-of-Action Gate.
The agent answered the question:
"Where is the address kept?"
But they didn't answer the question:
"What system determines the physical delivery of this order?"
The behaviour does not change when the correct data is written into the wrong recording system.
It's different things that an information can control the outcome in the real world by appearing.
This error is especially common in the following situations:
Keeping the same data in multiple systems,
Working together of old and new platforms,
a system that carries only the purpose of imaging or reporting,
lack of visibility of actual transaction source.
Potential harm
Delivery to the wrong address
Wrong bill or tax record
Contradiction of customer information between systems
Return and reship cost
The secret product reaches the wrong person
User not taking any further measures relying on the answer "changed".
Next agents missysteme canonical source
The organisation's acceptance of technical achievement as a real change of behaviour
could occur.
The same error can be seen in the webcast:
The agent writes the correct price to static HTML file, but the site reproduces the old price from the canonical service catalogue in the next compilation.
The change appears to be correct.
It is not permanent because its source is incorrect.
Detection signal
The same information is found in multiple systems.
It is not defined which system is the source of processing.
The agent changes the area that appears to be alone.
Real behaviour after change is not controlled.
CRM, order, accounting and cargo records are independent of each other.
The message "recorded" is used as evidence of results.
The appearance derived from the canonical source is not separated.
The next synchronization can reverse the change.
Correct behaviour
The agent must first understand the life cycle of data:
In what system is this information born?
Which system governs it canonically?
What record does the actual transaction use?
How to transfer to other systems?
To what point does change have to be achieved?
How will the result be confirmed?
The agent in address example:
should update the order management record,
The shipment should check if it is not locked yet,
Confirm the last address on the cargo system,
If CRM registration is required, it must also equalize it.
Only after the actual result is confirmed to the customer:
"The shipping address of your order has been updated as your new office address."
It should.
Machine rule
A transaction is not complete until the correct information has been applied to the canonical system that controls the behaviour. Display records and execution sources must be distinguished.
Audit question
When the same information exists in several systems, do our agents know which record is display-only, which can execute the transaction and which is the canonical source?
GBO-ERR-047 — Performing the Right Action on the Wrong Target
Brief case
A customer reports being charged twice.
The financial agent examines transactions.
Two payments have been received for the same order.
The agent correctly calculates the amount that must be returned:
$480.
There are two people in the customer database with the same name:
Mehmet Kaya — Order NK-481872
Mehmet Kaya — Order NK-48127
Order numbers are very similar.
The agent initiates the extradition with the correct amount.
But they choose the wrong order record.
$480 is sent to the other Mehmet Kaya.
The real customer can't take their money.
The wrong customer sees an unexpected return.
The calculation is correct.
The type of operation is correct.
The amount is correct.
The target is wrong.
What appears correct on the surface
The agent sees the customer's name, amount and type of transaction correctly.
When choosing between similar records:
name,
close order number,
similar history,
same product
Signs like this may seem adequate.
The human interface may also be showing records closely together.
Once the agent has selected the target, they complete the rest of the process flawlessly.
Therefore, the error occurs at the moment of target binding, not at the end of the execution chain.
The actual failure
The breached gate is the Target Binding Gate.
An action must connect four elements together:
CORRECT ACTION
+ CORRECT ENTITY
+ CORRECT RECORD
+ CORRECT TARGET ACCOUNT
A person's name may be correct.
But it is not the right order, account, or file.
A server may belong to the right company.
But change is not the production environment that needs to be made.
An employee is in the right department.
But it is not an interlocutor of the message.
The accuracy of the action is not independent of goal accuracy.
Potential harm
Transferring money to the wrong person
Continued victimization of the original customer
Connecting personal or financial information to the wrong person
Disruption of accounting records
The problem of collection
Loss of customer trust
Changes to the wrong server, file, or user account
The correct correction becomes a new error
could occur.
In some areas, the wrong target can produce a much heavier result:
medical records for the wrong patient,
Closing the wrong employee's account,
Paying for wrong company account,
Deleting the wrong database,
Publish on wrong social media account.
Detection signal
There are records of the same or similar name.
Identity is based on one area only.
Orders or customer numbers are visually close together.
The agent does not show the target summary prior to the operation.
There is no second target verification in high-impact operation.
The interface keeps the last selected record by default.
The system uses the first record that comes with a search result by name.
The transaction receipt does not contain the target's unique identity.
Correct behaviour
Before a high-impact action, the agent must verify the target using multiple unique identifiers:
Customer ID
Order number
Payment ID
Email or account
Date of operation
Reason for return
A brief goal summary can be shown before the process:
Return target: Mehmet Kaya Order: NK-481872 Payment: PAY-992014 Amount: 480 USD Source account: End 7421 Why: Reciprocal collection
The agent must stop action or request human verification if there is a similar record uncertainty.
Machine rule
The correct operation must not be performed until the unique target identity has been verified. A name, a similar number or position in an interface is not sufficient proof of the target.
Audit question
For actions involving money, data, access or external communication, do we verify the target with unique identifiers proportionate to the risk and, where needed, present a human-readable target summary?
GBO-ERR-048 — Treating HTTP 200 as Real-World Success
Brief case
A travel agent is assigned to cancel the user's hotel reservation.
The agent sends a cancellation request to the hotel's reservation API.
The system answers:
HTTP 200
Request received
Cellularity processing
The agent interprets this as a success and informs the user:
"Your reservation has been cancelled. There will be no charge."
In this response, HTTP 200 indicates that the request has been successfully processed according to the relevant method and API agreement; but the phrase "Cancellation processing" in the body clearly states that the reservation cancellation has not yet been finalized.
The process is run on a separate system in the background.
A few minutes later, the cancellation fails because the reservation has exceeded the free cancellation period by an hour.
The user does not contact the hotel by relying on the agent's answer.
The next day, the full fee is collected from the credit card.
The agent HTTP has widely interpreted the success status of the request, ignoring the ongoing business process in the response body.
But they confused technical acceptance with the result of work.
What appears correct on the surface
Under RFC 9110, HTTP 200 means that the request was successfully processed according to the selected method; the API contract and response content determine what that means for the business outcome.
Developer tools can show green signs.
API call did not give an error.
The agent's request was conveyed correctly.
But success at the technical protocol level is not the same as business-level outcome.
In this case, the response body says that the cancellation is not complete and that the final situation will occur later.
Request received.
The process is in line.
Confirmation has begun.
At one point, the result came back.
The final situation will occur later.
The same problem is seen in the following examples:
Counting acceptance of IndexNow declaration as a guarantee of scanning, indexing or sorting
Delivering the email server's acceptance of the message, falling into its inbox, or counting proof of reading
Counting receipt of payment request as finalization of collection
Interpreting file upload response as live streaming is correct
To assume that the candidate is admitted to the system of employment application
The actual failure
The breached gate is the Outcome Verification Gate.
The agent did not separate the following levels:
REQUEST SENT
→ TECHNICALLY ACCEPTED
→ TRANSACTION STARTED
→ TRANSACTION COMPLETED
→ REAL-WORLD OUTCOME VERIFIED
Evidence in one stage does not spontaneously indicate that the next stage has occurred.
Protocol success is not goal achievement.
Potential harm
Unauthorised booking or subscription
Unexpected fee
Failure of the user to perform the necessary tracking behaviour
Misconfirmation report
More display of search engine visibility than is
Misunderstanding of payment, shipment or publication status
The subsequent agents are based on incomplete processing
Kidnapping of the return window
could occur.
Detection signal
The agent only looks at HTTP status code.
The expression "pending", "accepted" or "processing" in the response body is ignored.
There is no final status query for the transaction.
The business result does not carry a separate identification or approval number.
Asynchronous operations are considered instant completion.
The language of "declaration accepted" and "consequence has occurred" is confused.
Clear uncertainty persists while the user is informed of the final result.
Correct behaviour
For every tool and operation, the agent must know the completion contract, any intermediate states and the authoritative verification source.
For example, for booking cancellation:
cancellation_status = confirmed
cancellation number
Wage Status
refund information
Hotel's final confirmation
It may be.
The agent must say after the initial response:
"The request for cancellation was received by the system; the reservation is not considered cancelled yet. I'm checking the final approval."
When the process is complete:
"The cancellation has been approved. Confirmation number C-7721. Cancellation fee 0 EUR."
They might say.
Machine rule
Technical acceptance or a protocol success code must not be interpreted as real-world completion. The action must be verified against an authoritative status record appropriate to its risk and, where necessary, by a method functionally separate from the acting tool.
Audit question
Are ‘request received’, ‘processing’, ‘completed’ and ‘outcome verified’ separate states in our systems, and at which stage may an agent use definitive language of success with the user?
GBO-ERR-049 — Performing the Same Action Twice
Brief case
A purchasing agent buys a $2,400 server licence for the company.
The payment sends the request to API.
The network connection is disconnected for a few seconds.
The agent can't get a response.
The system has:
"The request has expired."
The agent does this:
"Payment did not happen."
It interprets in form and returns the same request.
The second process gives an answer to success.
An hour later, the financial team receives two separate $2,400 collections.
The first request reached the payment provider and was completed.
Only the success response could not return to the agent.
The agent has achieved the same goal twice.
What appears correct on the surface
If a process has not responded, it is natural to try again.
Network and tool errors are common.
Retesting makes the system durable.
The agent wanted to keep the task unfinished.
But:
No response received
With:
Operation not carried out
It's not the same thing.
The external system received a request, but there may have been problems with the response path.
The actual failure
The breached gate is the Uniqueness and Idempotency Gate.
Transactions such as finance, messages, orders, bookings and broadcasts:
unique transaction ID,
Protecting again,
final status query
It must carry.
In the context of HTTP, the idempotent method is that the intended effect of multiple identical requests made for the same purpose on the server is the same as the effect of one request.
The practical requirement is:
When the same purpose is accidentally resend, the system must not produce a second unwanted side effect; it determines method semantics and implementation contract how this is achieved.
Potential harm
Duplicate charging
Ordering the same product twice
Sending the same email twice
Recording a user twice
The proliferation of the same reservation
Two different invoices or contract registration
Stock, budget and accounting disruption
Loss of user trust
Failure to undo the second transaction
could occur.
In sending messages, double processing is not a solitary inconvenience. Reaching the same person over and over again can become a problem of spam and reputation.
Detection signal
After a timeout, the agent immediately resends the same request.
There is no transaction ID.
The external system cannot question the previous request.
The state of "no response" is classified as "failed".
The policy of repetition is the same in all tools.
Payment, e-mail, and reading operations use the same retry logic.
The user sees two similar action receipts.
A second call is made without checking the transaction history.
Correct behaviour
A retryable, high-impact write operation must carry a unique idempotency key agreed between client and server, or equivalent replay protection:
operation_id: PURCHASE-2026-004872
The external system must connect this key to the same processing intent and prevent retry with the same key from producing second side effects during the safe period; it is not enough to write a ` operation_id ` on the client alone.
When the response is lost, agent first:
It should question the situation with its transaction ID
Check the order or payment record
If the outcome is uncertain, it should inform you.
Should not start new and independent operations
Side-ineffective readings can be tried more safely in most cases; however, the rate limit, cost and consistency effects should be evaluated.
Side-effect operations such as money, sending, data erasing, publishing, and commitment require tighter replay protection.
Machine rule
Failure to receive a response does not mean that no transaction occurred. High-impact actions must not be retried without a unique transaction identifier and an idempotency safeguard.
Audit question
Do our payment, ordering, email, booking and publishing systems technically prevent the same request from being executed twice because of a network failure or retry?
GBO-ERR-050 — Reporting Partial Success as Full Success
Brief case
A company publishes its new service page in six languages:
English
Turkish
German
Arabic
Spanish
Russian
The agent runs the production compilation.
All six source files are accepted by the compiler.
After live publication:
It opens in English.
Opens in Turkish.
It opens in German.
It opens in Spanish.
It opens in Russian.
The Arabic route gives 404 due to misdirection.
In the agent general test report:
"The publication is successful. The service is live in six languages."
author.
Because:
The main language page works,
Six source files have been produced,
Most of the total tests have passed,
The only route alone is a failure.
In reality, the publication was completed in five languages.
The sixth language is not alive.
Only five of the six mandatory language routes work; at this gate, the result is 5/6. This does not mean that the publication is 83 percent successful in all quality dimensions.
What appears correct on the surface
In large systems, it can be difficult for all components to be flawless.
A single error should not make general progress invisible.
The agent might think, "The main task is successfully completed, there is little error left."
Also, language that fails may represent a small portion of total traffic.
But the task is clear:
publication in six languages
The result in five languages is not complete success.
Partial success is valuable.
It should not be misnamed.
The actual failure
The breached gate is the Completion Accuracy Gate.
The conditions for completion of a task must be defined prior to action.
For example:
6/6 languages
12/12 mobile and desktop view
6/6 canonical and hreflang
0 critical error
System if one of these conditions is not passed:
partial success,
disabled,
Waiting for approval,
retrieved
It should use the right situation.
Majority success does not change the integrity requirement in the contract.
Potential harm
A missing language or user group remaining invisible
Reporting broken URL to search engines
Client assumes unfinished project completed
Misapproach of receipt or acceptance of delivery
Next agents based on incomplete system
Loss of critical minority errors in total success percentage
Accessibility, RTL or lack of importance for regional issues
Decreased confidence in the organisation's language of evidence
could occur.
Detection signal
The report only shows a total success percentage.
Failed components are not named.
The phrase "Build passed" is used instead of "live publication complete".
The task is shut down when five of the six targets have passed.
A language or user group that receives low traffic is considered unimportant.
The conditions for completion were not written before the task.
The agent doesn't make the difference between progress and completion.
The remaining risk is not shown separately.
Correct behaviour
The agent must clearly report the result:
Status: Partial success Live: 5/6 languages Failed: Arabic route Reason: Routing error Affected: Mobile and desktop Arabic users Next step: Route correction, recompiling and 12 view verification Completion: Not yet
It is not necessary to underestimate the partial result.
But it should not be presented as a complete result.
Machine rule
A task must not be reported as complete until every predefined mandatory completion condition has passed. A partial result must state the measured coverage, missing components and open risks.
Audit question
Do our agents report progress, partial success and full completion as separate states, and can low-volume but mandatory components be concealed within the overall percentage?
GBO-ERR-051 — Failing to Independently Verify Tool Output
Brief case
A web agent uploads 38 updated files to the live server.
FTP tool gives the following report:
38/38 uploaded successfully
The agent considers the publication successful.
But on the live site, users continue to see the old page.
Then there are the following problems:
Files are loaded into the wrong directory.
The CDN offers the old copy.
Two files have been corrupted during the transfer.
The common acet of the main page remains in the old version.
FTP tool has confirmed the single transfer, not checking the public result.
The tool did not lie.
They have actually transferred 38 files to the specified location.
But it has not proven that the correct files are served in the right position, to the outside world in the right way.
What appears correct on the surface
The system running the tool has strong knowledge of its own operation.
FTP client:
The link,
number of files,
Transfer Responses
They see.
The success report is technically correct.
Controlling the same system in another way can seem like unnecessary repetition.
A tool's own measure of success covers the technical step it performs alone in most cases.
The FTP transfer does not measure the output of HTTPS, which is presented to the user.
The compilation test does not measure the actual browser view.
Email API may indicate the provider's acceptance or delivery signal; it does not prove alone that the recipient has seen or read the message.
The actual failure
The breached gate is the Independent Verification Gate.
Common silent failures may remain invisible if the evidence confirming the outcome with the tool that did the action comes from the same narrow technical layer.
Depending on risk and impact, the verification chain can be set up as follows:
TOOL PERFORMS THE ACTION
→ A SEPARATE CHANNEL READS THE ACTUAL OUTCOME
→ COMPARES IT WITH THE EXPECTED OUTCOME
For example:
FTP loads, HTTPS downloads back.
The code is compiled, the actual browser is executed.
Payment is sent, order and bank record are read.
The message is sent; the provider receipt and authorised posting record are checked. If there is a claim to surrender or be read, separate evidence is sought in accordance with that claim.
Authority is applied, the current contract version is rechecked.
Potential harm
The old or corrupted file remaining live
Publication of incorrect price and coverage
Success notification to the user about failed operation
Kidnapping of the return window
Reporting incorrect URL or content to search engines
Separation of payment and order records
The agent creates a self-confirmed closed loop
The difference between actual result and report during audit
could occur.
Detection signal
The tool that performs the operation is also the sole source of success confirmation.
There is no readback from the public or external system.
Local testing is used instead of live verification.
There is no comparison of remote hash or version.
The same agent makes the change and approves their own conclusion alone.
The user surface is not tested.
The tool report is stored with the title "real result".
The silent rate of failure is unknown.
Correct behaviour
In high-impact transactions, result verification must be mandatory; the functional independence and depth of the method must be determined based on risk, reversibility, and possible impact.
For webcast:
Create local manifest
Export files
Read back files via live HTTPS
Compare Hashs
Check live HTML
Test real mobile and desktop view
Run critical performance and access doors
If independent verification fails, the action must not be considered complete.
Machine rule
A tool’s own success report is not final proof of a broader outcome than that report actually establishes. A high-impact result must be read back and verified through an authoritative record, channel or method that reduces the risk of a shared failure mode.
Audit question
For payments, publication, communication and data operations, do we verify the outcome from the outside world, or rely on the acting tool’s own ‘successful’ message?
GBO-ERR-052 — Proceeding Without Recognising the Point of No Return
Brief case
A company moves from its old customer relationship system to a new platform.
The agent:
carries customer records,
Matches companies,
It relays sales history,
It creates user accounts.
The first checks appear to be successful.
The record numbers are largely matched.
To reduce storage cost and shut down the old system, the agent conducts the remaining operations:
It disables accounts in the old system.
Deletes storage space.
Reduces reserve retention time.
Cancels the old licence.
A few days later, it is noticed that some important attachments and customer confirmation records are not being moved to the new system.
The old licence has been revoked.
Storage deleted.
There are also no last month attachments in the current backup.
The agent did not realize that they had moved from the repatriable stage of migration to the irreversible stage.
What appears correct on the surface
Migration seems to be successful.
The total number of records is close.
The new system works.
Keeping the old system open:
cost,
safety surface,
employee confusion
can create.
The agent wanted to complete the work and prevent waste of resources.
But there is a separate threshold of verification between "the new system works" and "we can safely destroy the old system".
The actual failure
The breached gate is the Reversibility and Remedy Gate.
In every important action, the following questions must be asked:
To what point can we easily go back?
After what process does the cost of return increase sharply?
What data or rights can be permanently lost?
What authority, review, or approval is required before we get to this point?
Has the proof of return really been tested?
The fact that an action technically has a "sil" or "imittal" button does not mean it is easily reversible.
Potential harm
Permanent data loss
Customer consent and loss of contract records
Loss of legal evidence
Stopping operation
Re-licence and recovery cost
The inability of people to access past work
Subsequent agent decisions based on incorrect or incomplete data
Direct reflection of error on people because no return can be made
could occur.
Other irreversible points include:
The big pay,
public identity publication,
the export of confidential data,
The signing of the contract,
The activation of the physical system,
Legal action with a missed deadline.
Detection signal
The operation's stages have not been classified by how difficult they are to reverse.
Prior to deletion or cancellation, the authority or approval required by the risk class has not been verified.
There is a backup but the restore has not been tested.
Control is based on the number of records alone.
Data types and attachments have not been compared separately.
The agent quickly shuts down the old system due to its goal of "complete".
The return window is not visible.
The recoverability of completed external effects is not assessed.
Correct behaviour
The agent must mark clearly where reversal or repair becomes substantially more difficult in the action plan:
STAGE 1: COPY — REVERSIBLE
STAGE 2: COMPARE — REVERSIBLE
STAGE 3: SHADOW USE — REVERSIBLE
STAGE 4: ACTIVATE THE NEW SYSTEM — PARTLY REVERSIBLE
STAGE 5: CLOSE OLD ACCESS — HIGH-IMPACT THRESHOLD
STAGE 6: DELETE DATA AND REVOKE THE LICENCE — HARD-TO-REMEDY THRESHOLD IN THIS CASE
Before the final stage:
data integrity,
Additions,
permit records,
user tests,
a restore exercise,
Authority or approval required by the duty contract
It must be completed.
Machine rule
Before crossing a point that is irreversible or difficult to remedy, the threshold must be clearly marked, risk-proportionate verification completed and the authority or approval required by the task contract demonstrated.
Audit question
For operations involving money, data, publication, contracts and identity, do we know where reversal or remedy becomes sharply more difficult and apply appropriate technical and managerial gates at that threshold?
GBO-ERR-053 — Using More Data Than Necessary
Brief case
A customer support agent is given the following assignment:
"Find out why the customer's order is late and draft appropriate response."
The information required for this task are:
Order number
Post date
Cargo status
Product
Customer contact address
But the agent can access the company's entire CRM database.
When reviewing the customer record, it also uses:
All past purchases
The last four digits of the payment card
Complaint notes
Internal comments by employees
Marketing profile
Estimated income level
Former phone call dumps
Records associated with other family members
Even if the agent does not show all of this information in the answer, it sends them all into the context of the external model.
For a simple cargo issue, the client's extensive personal and commercial profile has been processed.
What appears correct on the surface
More context can produce better answers.
If the agent knows about the client's past experiences:
More personal,
more understanding,
more complete
They can respond.
The system has technical access to data.
The organisation may have general data processing authority to offer support to the customer.
But finding access does not require the use of all data in each task.
More data produces not only the possibility of quality, but also greater damage.
The actual failure
The breached gate is the Data Proportionality Gate.
There are four separate questions in an agent's use of data:
Is this information necessary to perform a task?
Is there a legal basis, permission and organisation policy that applies to this purpose?
Does it need to be shipped to an external tool or model?
How long will it be stored after the procedure?
Technical access:
"You can technically access this recording."
It could mean.
But:
"You can process, export and store all areas in any task."
It doesn't mean.
GBO uses the following principle:
Minimum Required Data
Data needed for the right behaviour; nothing more.
Potential harm
Unnecessary personal data processing
Transfer of sensitive information to external provider
Wider damage to data leak
Use of user profile out of context
Discriminatory or unrelated inferences
Employee internal notes unfairly affect customer behaviour
Data retention and the growth of legal obligations
Creating an invisible profile that the user does not know
The agent's use of irrelevant information in future decisions
could occur.
Detection signal
The agent uploads the entire recording by default.
There is no data area limit per task.
The context sent to the external model is not visible.
The assumption that "more data is better answers" is not questioned.
Reading authority is used as sharing and storing power.
General data is not separated by sensitive data.
When the process is complete, temporary data is not cleared.
The user's old and unrelated information affects the new behaviour.
Correct behaviour
The data fields required for the task must be defined in advance.
In the example of cargo delay, agent only:
Order ID,
status of shipment,
expected date,
customer's communication preference
It can work with.
If additional information is really necessary, the justification should be visible.
Data access can be designed layered:
support_basic
support_shipping
support_billing
support_sensitive
The agent must use the layer suitable for their solitary task.
In external model or tool use:
personal data must be reduced to a limited and necessary level for the purpose,
anonymisation or pseudonymization should be applied if appropriate; it should be known that the two do not provide the same protection,
Non-essential records should not be sent.
Machine rule
Technical access does not grant authority to use every available datum for every purpose. Within the applicable legal basis and organisational policy, the agent must process only the smallest data set necessary for the specific task; sharing and retention must be restricted separately.
Audit question
Do our agents use only the data fields genuinely required for each task, or process every accessible item of client, employee or company data as default context?
GBO-ERR-054 — Failing to Generate an Action Receipt
Brief case
One morning, a company notices that the price of a major service on its website has changed.
The old price is $500.
The new price appears to be $350.
Change:
On the English page,
On the Turkish page,
to machine-readable catalogie,
the sales agent's knowledge base
reflected.
No one knows who made the change.
Possible sources include:
Web agent
Sales agent
Human editor
Night running automation
publication system that restores old price file
The git record shows only an automatic service account.
The service account is used by more than one agent.
The following questions cannot be answered:
Who wanted the change?
What source was it based on?
Who was authorised to change the price?
What files have changed?
What tests did it run?
When did the publication take place?
How to return to the old version?
Has the sales agent sent customers messages at this price?
The change may also be true.
And wrong.
But there is no chain of evidence.
What appears correct on the surface
Technical logs may exist across the systems involved.
Command executed.
The file has changed.
Server time is saved.
Therefore, an additional "macose" can be viewed as an unnecessary document.
But technical logs often do not answer the following questions together:
Human purpose
Authority
The canonical source used
Destination
Financial change
Real-world verification
Return status
A command line does not explain the meaning of behaviour alone.
The actual failure
The breached gate is the Action Traceability Gate.
An agent's action should not occur alone; it must be re-installed later.
The receipt of action is not a private chain of thought.
It is not necessary to record the entire internal reasoning of the agent.
What is required is a trace of observable responsibility:
What did they do? Who did they do it for? By what authority did they do it? What input did they use? Which result did they confirm? What can be retrieved?
If there is no receipt of action, neither can success nor error be fully audited.
Potential harm
Being unable to identify who made an unauthorised change
Return to wrong version
Repeating the same error
Interference of human and agent responsibility
Not knowing that the customer has been given false information
Loss of evidence in incident review
Authority laundering and shadow agent behaviour remain invisible
The organisation's asylum in the phrase "AI"
Not even the right behaviour can be repeated
could occur.
Detection signal
Multiple agents use the same service account.
There is no transaction ID.
Technical log and human demand are not linked.
The authorisation version is not recorded.
There is no changing file or list of records.
The independent verification result is not added to the receipt.
There is no evidence other than the agent's "completed" message.
It cannot be found which sub-agent took action at the time of the incident.
The point of return is unknown.
Correct behaviour
A material action must produce a receipt containing fields proportionate to its risk and sector obligations; the following list is the example proposed in this book:
action_id
requested_by
performed_by
agent_instance
purpose
authorization_version
target_system
target_entity
inputs_used_refs_or_hashes
data_classes
changes_made
started_at
completed_at
technical_result
independent_verification
approval_or_standing_authority_basis
rollback_point
open_uncertainties
status
The simple version available to people may be:
Action: Managed operation start price updated Claimant: Commercial authority Performed by: Web agent WEB-OPS-17 Source: Confirmed price record PRICE-v4.2 Changing surfaces: 6 languages, catalogue, FAQ Live verification: Defined manifest 38/38; passed financial price-comprehension match in six languages Authorisation basis: Registered publication authority for PRICE-v4.2 Return: release-20260908-01 version Open uncertainty: Search indexes not measured outside this verification scope
The receipt is not for successful actions alone:
Rejected,
stopped,
Partly remaining,
retrieved
It must also be created for actions.
Machine rule
For every material action, create an audit record covering identity, purpose, authority, target, material change, verification and rollback or remedy. The receipt alone does not prove that its contents are accurate; it must link to the relevant sources.
Audit question
For every significant agent action, can we later reconstruct with sufficient evidence what was done, by whom, under which authority or required approval, and on the basis of which source and version?
CHAPTER VI: CENTRAL FINDING
An Authorised Action Can Still Be Executed Wrongly
The nine records in this section have tested the executive chain between decision and real-world outcome: correct system and target, re-protection, honest status declaration, risk-proportioned verification, rollback/remedy, data minimization, and action trail should work together.
The common root of all errors is:
The agent has lost the difference between "I did the procedure" and "I produced the right result in a safe and demonstrable way".
A tool command can work.
But they may have worked in the wrong system.
A payment may be correct.
But they may have gone to the wrong account.
A API request is acceptable.
But the actual process may fail.
Most of a task can be completed.
However, one mandatory piece may be missing.
A publishing tool can be a success.
But the outside world may be seeing the old version.
A data migration can work.
But when the point of return is passed, incomplete records can be permanently lost.
An agent may be in charge.
But it can act disproportionately using more than enough data.
And even if the system has produced the right result, it cannot be known what needs to be repeated, what needs to be corrected, if there is no receipt.
The executive model proposed by NOMOS GBO evaluates the following elements together:
QUALIFIED EXECUTION =
CORRECT SYSTEM
AND CORRECT TARGET
AND ACTUAL TRANSACTION OUTCOME
AND UNIQUE TRANSACTION
AND HONEST COMPLETION STATUS
AND RISK-PROPORTIONATE OUTCOME VERIFICATION
AND AWARENESS OF REVERSIBILITY
AND MINIMUM NECESSARY DATA
AND ACTION RECEIPT
The basic provision of this section is:
An agent must apply the action to the correct system and the right target, with appropriate replay protection and with the minimum amount of data required; verify the result in accordance with the risk of the claim, indicate a return or compensation situation, and leave an auditable receipt.
Because the responsibility for behaviour that leaves a mark in the world does not end with the command running.
The claim to completion requires that the target, the resulting situation, open uncertainties and reversibility be supported by evidence consistent with the impact of the task.
But even if a single agent enforces all of these rules completely, another risk begins.
The task may be transferred to another agent.
Limits may be lost during transfer.
The authority that the main agent does not have may be granted to the sub-agent.
One agent may assume that the output of another is independent evidence.
Two agents can change the same file at once.
When the main agent stops, the queue and sub agents may continue to work.
And with each turnover, the task can grow a little bit.
The next nine errors will examine the question:
A single agent can act correctly; but when agents begin to work with each other, is the chain of identity, authority, reality and responsibility protected?
An agent error can only stay at one point. Multiple agent error can multiply throughout the system.