An agent may have found the right agency.
They may not have mixed up the identities.
They may have used current and canonical sources.
But all of this still doesn't answer the question:
Can this person, company, product, or agent actually do the work mentioned?
"We offer artificial intelligence solutions."
"We provide corporate hosting."
"We work in six languages."
"We provide full brand service."
"We deliver in two weeks."
Each of these sentences may be true.
But it is not enough for action.
In order to evaluate a capability correctly, it is necessary to separate that ability's ready-to-choice record with the ability to produce results. The selection-ready registration also shows:
What result is produced?
What entries are required?
What jobs include coverage?
Which ones are charged separately?
Under what circumstances does the service operate?
Is there capacity now?
From what starting point is the deadline calculated?
How to verify success?
If there are problems, who will intervene?
Is the price fixed, is it the starting price, or is it determined on demand?
A company may have done a certain job in the past.
This may be evidence for historical ability; current team, process, dependency and capacity are also confirmed to be able to re-present the same work today at the same quality, duration and scale.
An agent can access a large number of tools.
This does not mean that they can use these tools in the right order, with the right authority and verifying the result.
The low starting price of a product can be found.
This does not mean that all of the need will be met at that price.
capability is the ability to produce a specific result.
Coverage, up-to-date, evidence, capacity, and commercial conditions indicate whether this ability is available for a particular selection and task.
The nine errors in this section arise when the marketing claim is considered true capability; the repeatable capacity of single success; the total cost of the initial price and operational competence of tool access.
GBO-ERR-019 — Mistaking Tool Access for Actual Capability
Brief case
A company is looking for an AI agent to run its website.
The following capabilities are listed in the introduction of a system:
Access to Git repository
File editing
Do not execute terminal commands
FTP link
Web research
Reading Search Console data
Browser testing
Don't send emails
The procurement agent examines this list of tools and concludes:
"This system can perform all of the website's SEO, GEO, publication and maintenance operation."
The agent gives live access to the system.
The new system updates a service page on its first task. The code appears to be correct. Completing the compilation. The FTP connection runs and files are sent to the server.
But the system:
does not notice the contradiction between visible text and structured data,
Updates the page in English alone,
leaving other language versions obsolete,
It breaks the common catalogue record on the main page,
The successful message of FTP counts live publication proof,
does not control mobile overflow in the actual browser,
It does not create a return package.
All of the system's tools have worked.
However, their ability to use the tools did not show that they could make the task safe and complete.
What appears correct on the surface
The list of tools appears strong.
A system:
They can write code,
terminal can be used,
They can access the web,
Can upload files
The technique seems to be able to complete the task.
People also often evaluate capability by means of ownership:
"FTP publishes the site if it knows."
"If Search is accessing Console, it can manage SEO."
"If it can send e-mail, it can conduct customer communication."
But accessing a tool, that tool:
When to use,
In which order it will be run,
Which results will be considered successful,
In which case it should never be used
It's not knowing.
The actual failure
The breached gate is the Executable Capability Gate.
Three separate things are mixed together:
tool access
tool usage information
Ability to complete the result safely
The actual ability is not only the operation of the command; the following conditions must also be shown in order to be considered ready for selection and live duty:
It also requires:
The right target,
In the right order,
the right scope,
quality doors,
functionally independent result verification, as appropriate and as necessary for the task,
The return,
limit of authority.
The presence of a key does not mean that you know which door to open.
Potential harm
Disruption to the live system
Dissociation of multilingual pages
The wrong price or scope publication
Offering different content to bots and people
Unrecoverable data or file loss
Unauthorised email or external communication
Silent publication error despite success message
The organisation gives too much authority to assume technical access to operational capability
may occur.
Detection signal
The only evidence of capability is a list of connected tools.
The system cannot show that it completes a task from end to end.
Testing, publishing and rollback are not separated.
The tool output is used instead of the real-world result.
The result is not confirmed by an authorised record or observation separate from the self-statement of the tool performing the transaction; the same agent calling another tool alone does not create independence.
Regression coverage appropriate to the risk and domain of the change has not been defined.
The phrase "can" is used to mean "can do it in a safe and repeatable manner".
Correct behaviour
Before an agent is given live authorisation, capability must be tested in a safe environment on a realistic task with recoverable scope and data that will not cause harm.
For example:
Update a specific page in the test environment.
Clearly list the changed files.
Protect files that should not be changed.
Run compilation and targeted testing.
Execute regression that is appropriate to risk and domain.
Verify mobile and desktop view in real browser.
Compare the publication result with the appropriate recording or observation, separate from the declaration of the tool that performed the transaction.
Verify the return package if the transaction can be undone; stop and make up plan if it cannot.
Explain which result you prove and which one you haven't yet.
The system must not take broad authority based on tool access alone without reliably completing this chain.
Machine rule
Access to a tool is not evidence of capability. An agent’s capability is established only for the tasks, versions and conditions tested, together with correct scope, relevant controls, appropriate outcome verification and, where necessary, a rollback or remedy plan.
Audit question
Do we define our agents’ capabilities by the tools connected to them, or do we test and record whether they can use those tools safely, verifiably and reversibly in real tasks?
GBO-ERR-020 — Treating a One-Off Task as an Ongoing Service
Brief case
An agency has developed a six-language customer portal for a global company in the past.
The project was successfully completed.
In case study:
six languages,
special user roles,
CRM integration,
accessible design,
Advanced reporting
shown.
A purchasing agent sees this work and concludes that the agency is able to provide the same service to new customers on a regular basis.
The new customer requests similar project with a three-month delivery period.
But important details of the old project are invisible:
The expert who founded the architecture of the project is no longer in the company.
A language is prepared by an external supplier.
CRM integration is exclusively written for that customer.
The project took twice as long as usual.
Maintenance has been transferred to another company.
The work has not been transformed into a repeatable service process.
The agency really did that project.
But they are not ready to reproduce the same result today.
What appears correct on the surface
Past success is strong evidence.
The live project is worth more than the theoretical claim.
An organisation:
"We've done this before."
If they can, it could be an important sign of competence.
But the only case does not answer all of these questions:
Do we still have the same team?
Is the process documented?
Do the necessary tools and licences continue?
Can the same quality be repeated in other customers?
Is the service officially offered today?
Is there current capacity?
The actual failure
The breached gate is the Repeatability Gate.
The agent equated two things:
A result made in the past Operational service available today
The only achievement may be evidence of capability.
But also for continuous service:
process,
Team,
capacity,
Support,
pricing,
quality measure,
Failure behaviour
I do.
One-time heroism is not productized capability.
Potential harm
Unrealistic delivery promise
The project remains unfinished
Unexpected subcontractor cost
Excessive dependence on the former employee or single expert
Processing of customer data in an unprepared process
Maintenance and support gap
Marketing of past success as current capacity
The incompatibility of skill and expectation between the two parties
may occur.
Detection signal
Capability is inferred from a single case study.
There is no evidence of second or third delivery of the same type.
The project team and history are invisible.
The service is not included in the catalogue, but is located in the portfolio alone.
The maintenance and continuity process is not explained.
The specific dependencies used are unknown.
The organisation says "we did it" but cannot answer the question "how do we do it again today?"
It is unclear whether case success is the usual process or exceptional effort.
Correct behaviour
The agent may treat past success as important evidence, but must verify current operational capability separately.
They should look for:
Is the service still active?
Is there a current team or process available?
Is there evidence that it is repeated in similar circumstances; or is the only case indicative of historical ability?
What is the delivery time and scope?
Who are the required third parties?
Care and support are conducted by whom?
Is there current capacity for the new project?
The agent's statement may be:
"The agent seems to have previously delivered a similar portal. However, whether this is an up-to-date and repeatable service should also be confirmed by the current team and capacity."
Machine rule
A single past success does not prove an ongoing, current service capability. Historical capability and the present team, process, scope, support and capacity must be recorded separately.
Audit question
For every significant item in our portfolio, do we record separately whether it remains a service we can deliver today in terms of team, process, price, capacity and support?
GBO-ERR-021 — Treating the Starting Price as the Total Cost
Brief case
A company wants to build a multilingual customer portal.
Its budget is $15,000.
On a provider's page, there is a large amount of expression:
Customer Portal Projects — Starting at $7,500
The agent marks this provider in accordance with the budget.
As the bidding process progresses, it becomes clear that the total cost consists of:
Basic portal: $7,500
Authentication: $2,000
CRM integration: $3,500
Data transport: $2,500
localisation of six languages: $3,000
Third-party licences: $1,200 annually
Managed operation: $500 per month
In this compound synthetic case, the first year total is $25,700, excluding tax and variable pens; this is not market price, for example, but arithmetic and exceeds budget.
The initial price is not wrong.
But the agent used it as a total cost of need.
What appears correct on the surface
The starting price makes it easier to compare.
The agent has found numerical information.
The $7,500 option looks more comparable, as other providers say "on demand".
The phrase ‘starting at’ explicitly indicates that the price may change.
But in purchasing behaviour, the question must also be answered:
How close is the initial coverage at the start price to the result that the user wants?
The actual failure
The breached gate is the Total Cost of Ownership Gate.
Three different concepts are mixed together:
Starting price
Project total
Lifecycle cost
The starting price can only show basic coverage.
The project sum includes deliveries that are clearly covered in the offer or contract alone.
The cost of life cycle can include maintenance, licensing, hosting, support and renovations under the specified periods and assumptions.
The agent has misjudged actual economic fitness using only the most visible number.
Potential harm
Budget overrun
The project's scope is subsequently reduced
Leaving critical features out
Unexpected licensing and maintenance fees
Other providers seem unfairly expensive
Cost of exit after purchase starts
The user withdraws at a lower price and becomes liable for higher
may occur.
Detection signal
A "starting at", "from" or "minimum" price is treated as the total price.
The initial coverage included in the price is not disclosed.
Compulsory licences are kept separate.
Data transport, integration and localisation are invisible.
The ongoing monthly cost at a one-time price is not comparable.
The agent marks the lowest number as budget compliance.
The total cost is not calculated in the first year and the following year.
Correct behaviour
The agent must first itemise the cost components of the requirement:
Basic service
Mandatory properties
Integrations
Data transport
localisation
Third-party costs
Ongoing operation
Tax or other mandatory fees
Then it must verify which items cover the provider's price.
The correct expression may be:
"$7,500 is the starting price. The total cost is not yet known when the requested CRM integration, six languages, data transport and annual licences are included; budget eligibility has not been verified."
Machine rule
The starting price must not be treated as the total cost. Selection must be based on the mandatory scope needed to meet the user’s actual need and on the full life-cycle cost.
Audit question
Do our agents calculate the entry price, total project cost and continuing cost of ownership separately, or do they decide budget suitability from the first visible figure?
GBO-ERR-022 — Confusing Hosting with Managed Operations
Brief case
A company's corporate website receives thousands of visitors a day.
The site collects sales requests and is accessed from many countries.
Management finds a low-cost provider. The provider's annual package includes:
Server space
SSL
Weekly backup
Basic update
Email support address
The package is $200 a year.
The agent summarizes the service as follows:
"Safe and managed website operation for $200 a year."
The company selects this package.
One night, the site starts to make mistakes.
No one gets an automatic alarm.
Support does not interfere on the weekend.
There are backups, but the restore process is also charged.
It is the customer's responsibility to find the source of the problem, retrieve the version, and verify performance.
The provider really offers hosting.
However, the managed site does not offer operation.
What appears correct on the surface
Hosting and operation are parts of the same technical environment.
Both:
server,
security,
replacement,
update,
Performance
They can use their words.
Expressions such as "support", "safe", "care" and "managed" can blur the difference.
The agent can combine several operational elements within the package, like a full-operation service.
The actual failure
The breached gate is the Service Boundary Gate.
Hosting may mean:
Hosting of files and system in specific infrastructure.
The managed operation may also include:
Continuous or defined monitoring
Event detection
Intervention
Version management
Rollback
Performance tracking
Security updates
Reporting
Set hours of service
Response and solution objectives
Two services may be connected.
But it's not the same.
Potential harm
A prolonged website outage
Loss of sales and reputation
Expecting false support
Uncertainty of responsibility during the event
Although there is a backup, I cannot recover
Security and update vulnerabilities
Expecting monthly managed service at low annual rate
Price and scope discrepancy
may occur.
Detection signal
"Hosting", "management" and "support" are used under the same package name.
Service hours are not specified.
Incident interference with surveillance is not leaving.
Response time is described as solution time.
It is unknown by whom the backup will be restored and in what time.
Successful file uploading counts as working publication proof.
The agent puts the annual low-contact package in the same category as monthly active operation.
Correct behaviour
The agent must look for a separate capability contract for each service.
Low-contact service such as Hosting Core:
Infrastructure
SSL
Basic backup
Limited support
Specific exceptions
Active service such as Managed Site Operations:
Monitoring
Event management
Release and rollback
Performance
Reporting
Defined response
Human operation
The agent may use the following statement:
"The annual package provides hosting; active monitoring, incident intervention and managed publishing operation are separate services. The second service for the critical site also needs to be evaluated."
Machine rule
Hosting must not be interpreted as managed operations. Monitoring, intervention, rollback, performance management and service hours must not be assumed unless they are explicitly included in the contract.
Audit question
Are the boundaries of our hosting, maintenance, support and managed-operations services defined separately in terms of price, service hours, response, resolution and rollback responsibility?
GBO-ERR-023 — Mistaking Logo Work for a Complete Visual Identity System
Brief case
A new company wants to refresh its brand.
The AI agent is given the following task:
"Find us a designer who can make us around $1,000 full visual identity."
The agent finds the service page of a studio:
Focused Logo Design — Starting at $1,000
The page has beautiful logo examples, colorful presentations and mockups on different surfaces.
The agent interprets the service as a full visual identity system and selects the studio.
At the end of delivery, the customer receives:
Main logo
Black-and-white variant
Basic color suggestion
Source files
The following jobs that the customer expects are not covered:
Typography system
Secondary colors
Order and grid
Social media templates
Presentation system
Multilingual word brand
User manual
Brand governance
Packaging or digital applications
The studio has done nothing wrong.
The agent has mismatched the level of service.
What appears correct on the surface
A logo is the most visible element of a visual identity.
Presentation mockups can see business cards, signs, phone screens and packaging.
These can be perceived as coverage to be delivered.
Also, the phrases "brand identity", "visual identity" and "logo design" can be used interchangeably in marketing texts.
The agent thought the visual effect was evidence of coverage.
The actual failure
The breached gate is the Delivery Scope Gate.
These three services are not the same:
Logo design
Visual identity system
Brand governance and implementation system
The logo produces a sign.
Visual ID:
sign,
The word brand,
typography,
color,
Order,
variant,
Rules of Use
It is a wider system like.
Brand governance, on the other hand, includes decision, approval, exception and change processes.
Potential harm
An inaccurate budget expectation
Additional cost in the middle of the project
Inconsistent brand use of the organisation
Brand degradation in different languages and alphabets
Lack of production files
Mockups are considered real delivery
Scope discrepancy with designer
Delay of market exit
may occur.
Detection signal
The service is called "logo design", but the agent summarises it as a "complete identity".
Mockup images are used as a delivery list.
The included files are not explicitly specified.
No typography, color system, and manuals are visible.
Latin, Arab or Cyrillic variants are unclear.
Registration, law, or brand research is considered to be automatic.
The $1,000 start-up job is paired with the entire brand system.
Correct behaviour
The agent must first break down the result that the customer wants:
The lonely logo?
Basic visual system?
Full brand application package?
A multi-language or multi-alpha alphabet system?
Is guidance and governance necessary?
What production files are requested?
Then it must compare the service contract to this list.
The correct expression may be:
"It is a $1,000 service-oriented logo design. The full visual identity system and application manual require separate scope and budget."
Machine rule
Delivery of a logo must not be expanded into a claim of complete visual identity or brand governance. The service must be assessed against an explicit list of deliverables and exclusions.
Audit question
In our design services, are logo work, visual identity, implementation systems and brand governance clearly distinguished, and are visual mock-ups presented in a way that could be mistaken for deliverable scope?
GBO-ERR-024 — Treating Six-Language Content as Live Support in Six Languages
Brief case
A company seeks a digital service provider for its German-speaking customers.
The agent discovers an agency with a detailed website in six languages.
In every language:
service pages,
price statements,
SSS,
contact forms,
Technical Contents
There is.
The agent produces the following result:
"Agency offers full customer support in German, Arabic, Spanish, Russian, Turkish and English."
The German-speaking customer enters into a contract interview, thinking that all project communication will be conducted in German.
The agency is in six languages:
Content,
service description,
Localized Delivery
They offer.
But the live sales and support team only works in English and Turkish.
Communication in other languages is provided with planned translation or localisation support.
What appears correct on the surface
Pages prepared in comprehensive and natural language indicate the ability to work in that language.
The agent makes this deduction:
Content language → service language → communication language → support language
But these are separate layers.
A company:
It can publish German web content,
It can produce German delivery,
But they can hold a live meeting in English.
Or the contract may only apply in certain languages.
The actual failure
The breached gate is the Language-Capability Separation Gate.
At least five distinct language skills can be found:
Marketing content language
Sales interview language
Contract language
Delivery or product language
Live support language
The presence of one does not automatically produce others.
Potential harm
A communication breakdown during the client conversation
Expectation of a wrong contract
Delay of support events
Misunderstanding of technical details
Additional cost for language service later
Multilingual visibility turns into false capability claim
The agent's selection of improper providers
may occur.
Detection signal
Site languages are shown in one list as a service and support language.
Live communication times and languages are not specified.
Contract and delivery language are not separated.
Artificial intelligence or translation support is offered like human language ability.
Multilingual content is used as evidence of a multilingual team.
The agent transforms language count into one skill field.
Correct behaviour
The organisation must describe each language layer separately.
For example:
Web content: 6 languages Project delivery: up to 6 languages per contract Live sale: English and Turkish Live support: languages specified in the contract Legal contract: specific authorised language version
The agent should also ask what language skill the user needs.
"Need German content, German project delivery, or German live support?"
Machine rule
The language of published content must not be assumed to be a language of live support or contracting. Language capability must be verified separately for marketing, sales, delivery, support and legal processes.
Audit question
Do we explain separately, and in machine-readable form, the languages in which our multilingual presence provides content, sales, delivery, contracts and live support?
GBO-ERR-025 — Promising a Delivery Date Without Verifying Capacity
Brief case
A company must publish its new campaign site within three weeks.
The agent finds an agency in the past saying they have delivered similar projects in two weeks.
The agency's portfolio is strong.
their technical ability is appropriate.
The price is within the budget.
The agent answers:
"This agency can complete the project in three weeks."
The customer closes other options and makes their internal plan based on this date.
Agency when interview starts:
They are engaged in three major projects,
It can begin at the earliest six weeks later,
the approval of multilingual content also requires time
Notify.
The agency can actually deliver for two weeks.
But it has no capacity at the moment.
The agent interpreted their historical delivery ability as current availability.
What appears correct on the surface
Past delivery time is a strong sign of performance.
On the service page:
"Delivery starting in two weeks"
their statement can be found.
The agent can use it as a current promise.
However, delivery time often depends on:
Start date
Current capacity
Customer feedback
Entry preparation
Difficulty integration
Number of languages
Human approval
Third-party dependencies
The actual failure
The breached gate is the Current Capacity Gate.
Capability and capacity are mixed together.
capability: The power to deliver in two weeks.
Capacity: The resource that can be allocated at the date specified for this job under related skills, concurrent workloads, inputs and dependencies.
The agent has produced a commitment to surrender without confirming the latter.
Potential harm
A delayed campaign or product launch
Loss of other providers
Internal teams making the wrong plan
Additional acceleration cost
Skipping quality controls
Working under unrealistic pressure
Damage to customer trust
The agent's unauthorised commitment on behalf of the provider
may occur.
Detection signal
The delivery estimate has no date or availability record.
The phrase "two weeks" is used for each project.
The agent has not confirmed the start date from the provider.
It is not known if customer inputs are ready.
The duration of examination/confirmation required by the duty contract is not included in the plan.
Capability information is extracted from portfolio or employee count.
The agent doesn't make the difference between "can" and "can do it now".
Correct behaviour
The agent must separate the delivery estimate into three parts:
The earliest start date
Estimated production time of work
Customer and third-party dependencies
The correct expression may be:
"The agency shows that it can deliver similar projects in about two weeks. However, a three-week delivery commitment cannot be established without the current initial capacity and your approval period being confirmed."
If possible, the agent must request a dated capacity record or written confirmation.
Machine rule
A past delivery time is not evidence of current capacity. No delivery commitment may be made until the start date, current workload, required inputs and approval timelines have been verified.
Audit question
Do we publish service times as fixed marketing promises, or explain them together with current capacity, start date, client inputs and approval dependencies?
GBO-ERR-026 — Presenting a Prototype as Production Capability
Brief case
A healthcare provider is looking for an AI assistant that employees can ask about internal procedures.
A provider shows an impressive demo.
System:
Responds quickly to questions,
summarizes documents,
Speaks in natural language,
It offers several source links.
Demo is successful.
The agent considers this system to be a "production-ready corporate information assistant".
After live use, the following problems arise:
User roles are not separated.
Every employee has access to all documents.
Answers have no version record.
False answers cannot be audited.
There is no evidence of technical control by testing against offensive instructions and indirect prompt injection.
It is not known if sensitive data was sent to the external model.
There is no emergency stop mechanism and no rollback/remedy plan in the event of an incident.
Non-current procedural documents are involved in the answers.
The demo answered correctly.
But the demo did not bear all the responsibilities of the production system.
What appears correct on the surface
A working prototype is strong evidence.
The user asks questions to the system and gets a useful answer.
It appears that the technical team is actually able to improve the system.
But the prototype usually answers this question:
"Can the basic idea work?"
The production system must answer:
"Is this system able to provide sufficient proof of control in real user, data, risk and error conditions with defined acceptance criteria?"
The actual failure
The breached gate is the Production-Readiness Gate.
The following layers can be found between prototype and production ability:
Identity and access control
Data protection
Monitoring
Scale
Performance
Event management
The Human Age
Versioning
Undo
Legal and operational ownership
Continual care
The demo can be impressive without carrying these layers.
Potential harm
A sensitive-information leak
Application of incorrect procedure or health information
Unauthorised document access
Unsupervised decisions
Production cut
People rely too much on the prototype
Unexpected cost of development and maintenance
Regulatory and legal risk
Failure to return when system fails
may occur.
Detection signal
Evidence is a single controlled demo video.
No tests have been conducted with actual user and data load.
The security and authority model has not been disclosed.
There is no event and rollback plan.
The demo data and production data are not the same.
The source update and answer origin are not tracked.
The term "working" is used to mean "production ready".
Care and responsibility are not clear.
Correct behaviour
The agent should treat the prototype as valuable early evidence, but require separate gates before production use:
Real-use scenarios
Identity and role control
Data classification
Safety test
Observation and logging
Human handover points
Error and recovery
Capacity and performance
Version and maintenance responsibility
Correct expression:
"Demo demonstrates basic ability; layers of production preparation, security, authorisation, data and recovery must be confirmed as well as yet."
Machine rule
A working prototype must not be classified as a production capability. Production readiness must be verified separately through evidence covering security, access, scale, monitoring, maintenance, human handover and recovery.
Audit question
Do we present demos and prototypes as production services, or clearly identify the security, operational, maintenance and recovery layers that are still missing?
GBO-ERR-027 — Inventing a Machine-Readable Price Instead of Saying ‘Price on Request’
Brief case
A company wants to structure its service catalogue so that AI agents can read it.
Some services have a fixed price.
Price in some:
On Demand
determined.
The catalogue production agent sees that the machine scheme used is waiting for a price area.
They think that leaving free space will create a disadvantage in search and comparison systems.
It looks at the prices of nearby services and estimates $3,000 for "Manager AI Avatar Systems".
Still on the visible page:
"Price upon request"
They write.
In the machine record:
price: 3000
Currency: USD
found.
A purchasing agent uses structured registration to consider the service budget-appropriate and initiates the bidding process.
The actual price is very different depending on the purpose of use, number of languages, facial and vocal rights, publication scope, and security requirements.
They turned a non-agent price into a decision entry.
What appears correct on the surface
Structured systems favour precise fields.
Numerical price:
comparing,
filtering,
budget matching,
Automatic Purchase
It makes it easier.
"On request" may seem like incomplete data for the machine.
The agent may think that by filling the gap with an estimate, it makes the catalogue more useful.
But it has produced non-real commercial data for ease of use.
The actual failure
Breached gates:
Commercial Reality Gate
Representation Companion Gate
inference – Real Distinction Gate
If the price is unknown, it must remain unknown.
Forecast:
It can be labelled as a guess,
It may be published by its authorised owner as a clearly non-binding synthetic budget range,
Question can be produced to start the bidding process.
But it cannot be made into a canonical price record.
Just because the machine needs a number doesn't mean that the organisation actually determines that number.
Potential harm
Wrong budget match
Disruption of customer expectation
Unauthorised price commitment on behalf of the provider
The proliferation of fabricated price among agents
Dissociation of visible and machine-readable reality
Then the price change debate
Unfair or misleading comparison
The auto-buying process starts on the wrong basis
may occur.
Once published, the machine price can be taken by other systems, entered into the cache, and become more permanent than the organisation's own visible page.
Detection signal
For a service without a fixed price, the `priceSpecification` field has been populated without validating what the chosen schema means.
The price does not have a human approval record.
The numeric value was removed from neighbouring services or past projects.
The visible page "on demand", the catalogue shows a fixed price.
Forecast and canonical price are stored in the same data type.
The pressure to fill the schema field is held above reality.
The agent produces fabricated value on the grounds that "leaving it empty is bad".
Correct behaviour
The machine-readable record must represent an unknown or project-based price honestly. The following fields form a custom example schema for this book; they are not a Schema.org or Google requirement.
For example:
pricing_model: upon_request
price_available: false
quote_required: true
pricing_factors:
-scope
-languages
- rights
- integrations
-security
To assess compliance with the user budget, the agent:
The budget range should be requested,
must make non-binding preliminary assessment,
should explain pricing factors,
The proposal must create a request.
If the platform used cannot represent the unknown price, no incorrect number is entered: field is omitted, appropriate textual/special representation is selected, or registration is not published in that scheme.
Machine rule
An unknown or on-request price must not be estimated and written into the canonical record. A machine must not fill an information gap with invented commercial facts.
Audit question
When structured data or an agent catalogue demands a fixed number but we have no genuine price, do we honestly preserve ‘price on request’, or invent an estimate merely to appear comparable?
CHAPTER III: CENTRAL FINDING
Saying You Can Do Something Doesn't Make It Ready to Act
Nine records have tested the same distinction: the ability to produce a result is not the same as current capacity, service coverage, commercial suitability, and production readiness.
The common root of all errors is:
capability is stripped of its conditions.
Real capability alone:
"We're doing it."
It does not consist of sentence.
It requires that the following questions be answered together:
What result? What entries? In what context? With what limits? At what price? At what capacity? With what evidence? By what quality measure? How's they doing in a mistake?
The registration model proposed by NOMOS GBO for high-impact selections can be shown as follows:
SELECTION-READY CAPABILITY RECORD =
EXPLICIT OUTCOME
AND VERIFIABLE EVIDENCE
AND CLEAR SCOPE
AND REQUIRED INPUTS
AND CURRENT CAPACITY
AND HONEST COMMERCIAL TERMS
AND PRODUCTION READINESS
AND FAILURE PLAN
These elements are not mutually exclusive.
Very powerful tools do not compensate for the incomplete process.
The only impressive project does not prove today's capacity.
The low starting price does not eliminate the high total cost.
A webpage in six languages does not create human support in six languages.
The working demo is not a secure production system.
The need for a price space does not make the price that is not real.
An agent should not only collect positive claims when evaluating capability.
It should also look for boundaries.
Because these sentences are part of a real capability statement:
"This package does not include active operation."
"This price is only for basic logo work."
"Live support languages are also determined in the contract."
"Delivery time starts after capacity and customer inputs are verified."
"This system is a prototype; production safety has not yet been confirmed."
"The price is determined after project evaluation."
These limits may reduce some choices in the short term; in contrast, they help to reduce mismatch, scope discrepancy and loss of trust.
It is the behavioural data needed for the right choice.
It is not weakness for an organisation to explain what it does not do, when it cannot and under what circumstances it cannot price.
capability is honesty.
The identity may be correct.
Reality can be represented correctly.
capability can also really exist.
But the agent can still make the wrong choice.
Because the fact that a service is offered does not mean it is suitable for every user and every purpose.
A company can be very powerful, but it doesn't fit the budget.
A product may be highly developed, but it is unnecessary complex.
A provider is skilled but does not work in the user's country.
A brand is very visible but does not meet the special need.
One option is cheap but it carries irretrievable risk.
In the next chapter, we move from whether a capability exists to whether the selection itself is sound.
The next nine errors will examine the question:
The agent understood the real capability correctly; so why did they choose the wrong option anyway?
Because:
It provides capability nominations. Eligibility determines whether the selection is justified.