Canonical Facts and the Evidence Chain

A company's sales agent sends a prospect this offer: ‘Our managed site operations service starts at 350 dollars a month.’ The customer says they are ready to accept. When the company's commercial director sees the message, they are surprised. The current starting price is 500 dollars a month. ‘Where did you get the 350-dollar figure?’ they ask the agent. ‘I found that price in the company's approved sales sources,’ the agent replies. They check the website. The service page clearly states: ‘Managed Site Operations — Starting at 500 USD/month.’ The director takes a screenshot and says: ‘The agent has produced incorrect information. The canonical price is already correct on the website.’

The incident looks like a simple model error. But the auditor does not stop at the current web page. They ask: what information could the agent access when it sent the message? The records are examined step by step. At 08:42, the approved price registry shows 500 dollars a month. At 08:51, an old quotation template in the sales CRM still shows 350 dollars. At 08:56, the sales agent's knowledge index was rebuilt from that CRM template. At 09:14, the agent sent the 350-dollar price to the customer. At 09:22, a human manager noticed the error and corrected the CRM template. At 09:31, the website screenshot was taken. At 09:45, the agent's knowledge index was updated again.

The screenshot supplied by the company supports the claim that the page displayed a price of 500 dollars at 09:31. It does not prove which record the agent used at 09:14. The auditor finds other evidence:

The email action receipt identifies the old CRM template as the source.

The agent's knowledge-index version does not include the current version of the price registry.

The old template originated in a temporary discount offered to one customer.

The discount record has no end date.

The person responsible for the CRM template no longer works at the company.

No machine rule states that the template is not a canonical price source.

The website showed people the correct price.

The sales agent used the old internal template, not the page intended for people.

We can no longer explain the incident simply by saying, ‘The agent quoted the wrong price.’ A more accurate account is:

The organisation's valid, authorised price was 500 dollars. But the old 350-dollar record remained active in the agent's operational information environment. People and machines worked from different facts. The agent could not determine which source was canonical. The current screenshot did not establish the situation at the time of the earlier action. The organisation had corrected the information but had almost lost the evidence chain leading up to the incident.

There are now three distinct realities to consider:

Authoritative facts

The valid price is 500 dollars a month.

The operational information available to the agent

The sales index shows a price of 350 dollars a month.

The outcome in the outside world

The customer was offered a price of 350 dollars a month. An audit that confuses these three realities cannot find the root cause. Looking only at the website, it says, ‘The agent made up the facts.’ Looking only at the agent's records, it may say, ‘The agent acted in line with the available source.’ Examining only the message sent to the customer, it may conclude, ‘The company announced a price of 350 dollars.’ Each sees part of the incident. None, on its own, shows the whole truth. GBO auditing therefore needs two separate structures:

Canonical Fact Registry

and

Evidence Chain

The first answers: which fact was authoritative and valid at a particular time and within a particular scope? The second answers: through which sources, transformations and verification steps did we reach that judgement?

Finding information is not establishing the facts

Information may exist online or in an organisation's systems. That does not mean it is:

correct,

current,

authoritative,

relevant to the scope,

sufficient to act on.

A price may be available but out of date. A service description may apply only to one customer. A record of a human role may remain available after that role has expired. A consent record may cover a different purpose. A comment may appear on many pages yet derive from a single self-reported claim. A screenshot may show the right content but have been taken after the incident. Comparing a file’s hash with a previous, reliably stored hash value helps check whether the file has changed. It does not establish that its contents are true. A digital signature may show that a document was signed by a particular person or system.

It does not automatically prove that the claim inside is true. A citation may lead to the right page, but that page may not support the sentence the model wrote. GBO auditing therefore rejects this shortcut:

INFORMATION FOUND = FACT VERIFIED

The proper chain is longer:

INFORMATION FOUND ↓ ENTITY VERIFIED ↓ SOURCE ROLE IDENTIFIED ↓ AUTHORISED OWNER IDENTIFIED ↓ TIME AND SCOPE MATCHED ↓ CONFLICTS DISTINGUISHED ↓ EVIDENCE PROVENANCE PRESERVED ↓ FACTUAL JUDGMENT REACHED

What are canonical facts?

Canonical facts are not the story an organisation likes or wants to repeat. Nor are they the sentence in the largest type on a web page. The term does not mean that an organisation can define itself however it wishes. In this protocol, canonical facts take the form of an auditable record concerning a specific entity and fact type. Its authorised owner, source role, scope, period of validity, exceptions and version history are defined; it specifies which value should govern human and machine behaviour. More simply, canonical facts identify which record is entitled to settle a particular question, within which time period and scope.

‘Settle’ does not mean establish an unlimited, immutable truth. An organisation's price can change. A human role can end. A service's scope can expand. Consent can be withdrawn. Capacity can be exhausted. A record may be valid today and invalid tomorrow. Canonical facts therefore amount to more than a value. They express a:

Value–Owner–Scope–Time relationship.

The eight core fields of canonical facts

A fact record must answer at least eight questions.

1. Which entity?

Which company?

Which person?

Which brand?

Which product?

Which agent?

Which account?

Entities with the same name must not be confused.

2. Which type of fact?

Price

Service scope

Capacity

Human role

Authority

Consent

Data retention period

Eligibility

Action performed

Publication status

Different fact types may have different authoritative sources.

3. What is the value?

For example: the starting price for Managed Site Operations is 500 USD/month. The value alone, however, is not enough.

4. What is its scope?

Does this price:

apply to new customers,

apply to existing customers,

apply to a particular country,

apply to a particular package,

include taxes,

cover only the entry-level service?

5. Who owns the fact?

Which authorised person or body determines whether this fact is correct and current?

6. Which source is authoritative?

The web page? The approved price registry? A signed contract? The CRM? The HR authority registry? The operations calendar?

7. When is it valid?

Start date

End date

Last verification

Review

Invalidating event

8. What exceptions apply?

A discount for a specific customer

A temporary promotion

A price preserved under an older contract

A particular country or language

A specific capacity commitment

Without these fields, simply saying, ‘The price is 500 dollars,’ leaves the fact incomplete.

A canonical source is not one vast database

Organisations often say, ‘We need a single source of truth.’ That is a useful idea. Misunderstood, however, it can become an attempt to squeeze the whole organisation into one file or database. Different types of facts can, in practice, have different authoritative sources.

A canonical system need not mean putting everything in one place. It requires clarity about which source is authoritative for each important type of fact. A service's price may come from the price registry. The visible web page may be the representation of that price for people. The agent catalogue may be its machine representation. The CRM quotation template may be a derived copy. These four records do not serve the same function.

Source roles

An audit must classify each source's role explicitly.

1. Authoritative source

A source with organisational or legal authority to determine the fact. An approved price registry is one example.

2. Operational source

The source the agent uses in practice. For example, the sales knowledge index.

3. Representation source

The surface through which the fact is presented to people or machines. For example, a web page or structured data.

4. Execution source

The system that controls the actual action. For example, the delivery address in an order system.

5. Archive source

A source that enables reconstruction of an earlier state. For example, a versioned document repository.

6. Independent verification source

A source that verifies the result separately from the system carrying out the action. For example, a live HTTPS readback or an audit inbox.

7. Secondary commentary source

A third-party source that summarises or evaluates primary data.

8. Agent inference

A conclusion derived from sources but not directly verified. These roles must not be treated as interchangeable. A web page may be a strong representation source without being authoritative for a customer's contract price. An agent report may be a useful operational summary, but it is not independent verification. A screenshot may be evidence of a past representation, but it is not the source that sets the price.

Canonical does not mean exactly the same as correct

An organisation may have entered an incorrect price in its authoritative registry. The record may be canonical within the organisation yet conflict with the actual commercial situation or a signed contract. The audit must therefore keep two questions separate: which record was the organisation's authoritative record? And was that record consistent with the binding transaction and the actual outcome? For example:

The price registry shows 500 dollars.

The contract signed with the customer shows 450 dollars.

For general pricing, 500 dollars is canonical. For this customer's transaction, the contract price of 450 dollars applies. These are not contradictory: they are two valid facts with different scopes. Preserving that difference is an important function of canonical facts.

General rule, exception and specific transaction

Many organisational facts exist at three levels.

General rule

The service starts at 500 dollars a month.

Temporary or limited exception

A 10 percent discount applies to existing customers from 1 to 15 September.

Specific transaction

The contract signed with Customer A sets the price at 430 dollars. Errors arise if the agent reduces all these records to a single price field. The 430 dollars offered to one customer may be mistaken for the general price. A temporary promotion may become indefinite. The general price may override the specific condition in a signed contract. A canonical registry must therefore carry relationships of precedence and scope, not just a single value. The correct interpretation can follow this logic:

A VALID, SPECIFIC TRANSACTION RECORD OVERRIDES THE GENERAL RULE ONLY WITHIN ITS OWN SCOPE

Not this logic:

THE NEWEST OR LOWEST VALUE IS THE NEW FACT FOR EVERYONE

The newest record is not always canonical

An employee may enter a new price in the CRM at 10:00. The approved price registry may have been created at 09:00. The CRM record is newer. But if the employee has no authority to change prices, recency does not make it canonical. A social media post may be newer than an old contract, but it cannot amend the signed contract. An agent summary may have been created today while summarising a source that is three years old. Source precedence must therefore not be determined by chronology alone. A sound assessment combines at least these four dimensions:

AUTHORITY + SCOPE + TIME + SOURCE ROLE

Time is part of canonical facts

An audit does not ask only, ‘What is true today?’ When investigating an incident, a more important question is: which fact was valid and accessible when the action took place? An agent may have used an old price on Monday. The price was corrected on Tuesday. Tuesday's page does not explain Monday's incident. Every material record must therefore carry these time fields:

effective_from effective_until created_at approved_at last_verified_at superseded_at invalidated_by_event

These fields are not interchangeable. A document may have been created on 1 September, approved on 5 September, valid from 10 September and replaced by another record on 20 September. The file's creation date alone is not enough.

Invalidating events

Some facts can cease to be valid before a specified date arrives. For example:

An employee leaving the organisation

Withdrawal of consent

Capacity being exhausted

A product going out of stock

Termination of a contract

Revocation of an agent token

A change to the company's legal entity

Detection of a security incident

A record must therefore not simply say, ‘Valid until 31 December.’ It must also include:

invalidate_on:
  - employee_termination
  - consent_revocation
  - contract_cancellation
  - security_incident

An agent must not act merely because the calendar says the record is still within its validity period. It must also check for invalidating events.

Freshness classes for facts

Not all information goes out of date at the same rate.

Slow-changing facts

Founding date

A past publication

The core name of the product architecture

Facts that change at a moderate rate

Human roles

Service scope

Support hours

Authority policies

Fast-changing facts

Price

Stock

Capacity

Flight availability

Promotions

Active tokens

Queue state

The audit must define a freshness threshold for each type of fact. For example:

price:
  refresh_required_before_action: true

capacity:
  maximum_age: 24_hours

legal_entity:
  verify_on_material_change

authorization:
  verify_at_execution

A capacity record may have been correct three months ago. It cannot be used to make today's delivery promise.

Three views of canonical facts

The same material fact can have three views within an organisation.

1. Authoritative internal facts

The value set by the person with decision-making authority within the organisation.

2. Facts presented to people

The value shown on the website, in a quotation or contract, or in customer communications.

3. Facts presented to machines

The value shown in an API, schema, agent catalogue, knowledge index or tool description. These three views need not be identical word for word, but they must be equivalent in material meaning. For example, the human-facing text might say: Managed operations start at 500 dollars a month. Hosting fees and third-party licences are considered separately. The machine record:

pricing_model: starting_price
starting_price: 500
currency: USD
billing_period: month
excludes:
  - hosting
  - third_party_licenses

The sentences differ. The commercial fact is the same.

Representation parity

We can call the material agreement between human and machine views:

Representation Parity

Representation parity must be tested in at least these areas:

Entity identity

Legal operator

Service outcome

Included scope

Excluded scope

The distinction between starting and total price

Consent requirements

Human approval

Capacity

Outcomes that are not guaranteed

Cancellation and withdrawal path

Sponsorship or commercial relationship

If an important limit in one view disappears from the other, the system is publishing different behavioural realities.

Multilingual canonical facts

A service description can be published in six languages, each with its own way of presenting the service. Languages are structured differently. The level of technical detail may vary with the reader and the text's purpose, not with the language itself. Arabic text is laid out right to left; the order of explanations and the sentence structure can follow the natural flow of Arabic. Spanish can convey the same meaning through forms of address and expressions that feel natural to its readers. This variation is not the problem. Changing material facts is. Suppose the English text says, ‘Every public avatar publication requires human approval.’ If another language conveys only, ‘Content is prepared in accordance with the approval process,’ the requirement for human approval of every publication may have been lost.

Multilingual canonical facts must therefore be managed at two levels:

A language-independent factual contract

Price

Scope

Consent

Authority

Prohibitions

Cancellation

Outcomes that are not guaranteed

Natural expression in each language

The same factual contract is expressed in natural, local language. Translated sources do not count as independent evidence. Seeing the same information in six languages does not give us six pieces of evidence. It gives us six representations of one canonical fact.

The governing language version

Some contracts or legal records may explicitly designate which language version governs if the texts differ. The legal effect of that choice is assessed separately. In such cases, other languages may be provided for:

information,

localisation,

accessibility.

Designating one language version as governing does not make material errors in other languages acceptable. If a user makes an important decision in another language, the following must be clear:

the translation's limitations,

the controlling text,

material differences.

An agent using a translated text must also know which version is binding.

Canonical facts are not subjective claims of superiority

A company can record this statement as canonical: ‘We provide service pages in six languages.’ If it really does, that is a verifiable fact. It cannot make this claim canonical simply by deciding to: ‘We are the best GBO company in the world.’ That statement requires:

a defined comparison population,

a comparison method,

data,

a date,

an independent assessment.

An organisation can make its own narrative official. It cannot turn an official self-declaration into an external fact of superiority. The registry must therefore distinguish these classes:

Verified organisational fact

Self-declaration

Marketing positioning

Measurement result

Independent assessment

Inference

Opinion

Publishing a claim as canonical does not automatically make it an objective fact about the outside world.

Conflicting canonical facts

During an audit, different sources may show different values for the same subject. For example:

Web page: 500 dollars

CRM: 350 dollars

Contract: 430 dollars

Agent catalogue: upon request

Old PDF: 400 dollars

The first step is not to choose one. First ask: do these really answer the same question? The contract price of 430 dollars may apply to a particular customer. The old PDF may no longer be valid. The CRM's 350-dollar entry may be erroneous and unapproved. The agent catalogue may not have updated its price. The web page may show the general price for new customers. There appear to be five different prices. Once properly classified, only one may be a genuine conflict.

Resolving conflicting facts

When a material contradiction is found, follow this process.

1. Stop the action according to the risk

A high-impact operation must not proceed while the price, authority, consent or target identity is uncertain.

2. Preserve all existing versions

Do not rush to correct a record and destroy the historical evidence.

3. Establish the fact type and scope

Is this a general price? A customer-specific contract? A temporary promotion?

4. Classify the source roles

Is it an authoritative source, a representation, a derived copy or an archive?

5. Establish when it was valid

Which version was active at the time of the event?

6. Identify the human owner

Who has authority to settle this question?

7. Distinguish an exception from an error

Does the difference reflect legitimate special terms, or a record that has not been updated?

8. Record the resolution

Which value was accepted as valid, for which scope and date?

9. Propagate the change to every representation

Web, API, CRM, agent directory, quotations and language versions.

10. Verify propagation independently

Saying that the source has changed is not enough; check that the systems using it have been updated.

11. Identify affected operations

Which messages, quotations, payments or decisions did the incorrect fact affect?

12. Retest

Does the agent now use the correct source in the same scenario?

Deleting the old record before resolving the contradiction

An organisation may want to correct an erroneous record quickly. The intention is good. But if the old record is deleted before the audit begins, these questions can no longer be answered:

Did the agent actually see this record?

How long had it been active?

Which operations did it affect?

Which agent directory did it reach?

Where did the underlying error arise?

Are other copies still active?

The correct approach:

Preserve the previous state.

Secure the evidence of the event.

Publish the new version.

Mark the old version as invalid or archived.

Examine the extent of the impact.

Preserving an incorrect historical record does not mean keeping it active. Historical evidence and operational facts must be kept separate.

Canonical propagation

Once an authoritative fact has been established, it must reach every surface that shapes behaviour. We can call this process:

Canonical Propagation

A price change, for example, may affect:

The human-facing web page

The machine-readable service catalogue

Structured data

The CRM quotation template

The email agent's knowledge index

Multilingual pages

The sales presentation

The contract template

Business directories

External platforms

If the change is made only in the canonical registry, the agent may continue using the old copy. The canonical source is correct. The operational reality is still wrong.

Propagation delay

We can call the interval between a change to a canonical fact and the update of every relevant surface:

Propagation Delay

For example:

Price registry updated: 09.00 Web page updated: 09.05 Agent catalogue updated: 09.20 CRM template updated: 11.30 Sales agent index updated: the following day

Throughout this interval, the organisation operates with more than one version of the facts. For high-impact changes, the relevant agent behaviour may be restricted until propagation is complete.

Measuring canonical coverage and parity

A single score is not enough. Some measures can, however, make gaps visible.

Canonical Ownership Ratio

Material facts with an identified human owner ÷ Total material facts

Representation Parity Ratio

Records whose material meaning matches across human- and machine-facing surfaces ÷ Total records compared

Language Parity Ratio

Language versions preserving the critical factual contract ÷ Total language versions

Freshness Compliance Ratio

Dynamic facts verified within the required period ÷ Total dynamic facts

Propagation Completeness

Surfaces carrying the current canonical value ÷ Total surfaces requiring an update

Count of Unresolved Material Contradictions

Open contradictions affecting action, such as price, authority, consent, scope or identity. These measures provide operational visibility only. A single critical contradiction must not disappear behind a high overall ratio.

What is evidence?

Repeating a claim is not evidence. A system saying, ‘I succeeded,’ is not evidence. An organisation saying, ‘That sort of problem does not happen here,’ is not evidence. The canonical definition is as follows: evidence is an observable record concerning a particular claim, configuration, behaviour or outcome, with a known origin, time, integrity, scope and acquisition method, which helps another evaluator reconstruct the judgement. Evidence is not always conclusive proof. Its strength can vary. A screenshot may show what appeared on a screen at a particular moment. It does not show the entire system behind it. A log may show a record of an operation. It does not show behaviour outside the logging mechanism.

A contract may provide evidence of authority. It does not prove that the technical system complied with that contract. Evidence must therefore be used with regard to its:

role,

limits,

strength.

Claim, observation, inference, decision and outcome

An audit must distinguish these five concepts.

Claim

The agent does not send messages without human approval.

Observation

In the scenario without approval, the sending tool was not called.

Inference

The system may be preventing sending without approval.

Decision

Within the defined test scope, the authority gate passed its test.

Outcome

No message reached the audit recipient, and the sending queue remained empty. Before moving from an observation to a broad claim, the sufficiency of the evidence must be assessed. The fact that no message was sent in one scenario does not establish that the agent ‘can never send one’. Likewise, non-delivery may not conclusively show that the agent made no attempt to send. A tool call may have failed. The audit must not confuse these layers.

What is an evidence chain?

The canonical definition is as follows: an Evidence Chain is a versioned trail showing where, by whom, when and how raw sources supporting or refuting an audit claim were acquired; what transformations, masking, classification and analysis they underwent; which observations and findings they were linked to; and how their integrity and retention status were maintained. Put simply, an Evidence Chain answers ‘How did you reach this conclusion?’ from beginning to end. It may show this path:

RAW SOURCE ↓ ACQUISITION METHOD ↓ TIME AND COLLECTOR ↓ INTEGRITY RECORD ↓ NECESSARY MASKING ↓ OBSERVATION ↓ MATCH TO CLAIM ↓ COUNTEREVIDENCE ↓ AUDIT JUDGEMENT

An evidence chain is not the agent's private internal chain of thought. The audit does not attempt to record all of the system's hidden reasoning. What is needed is an observable accountability trail:

Which source was read?

Which tool was called?

Which authority was exercised?

What external outcome occurred?

Which record verified it?

Ten attributes of evidence

Every piece of evidence must be assessed against these dimensions.

1. Relevance

Does the evidence genuinely concern the claim being made? A company's general security policy may not prove that a particular email was authorised.

2. Authority

Does the source have authority to speak about this type of fact? A social media comment cannot determine the current price.

3. Temporal alignment

Does the evidence represent the time of the event or the relevant validity period? Today's screenshot does not prove last week's behaviour.

4. Authenticity

Can it be verified that the source really came from the stated person, system or organisation?

5. Integrity

Has the evidence been altered since it was acquired? A file hash can help here.

6. Completeness and context

Does the record contain the necessary surrounding information? A cropped screenshot may conceal an important exception.

7. Independence

Is the evidence separate from the audited system's own statement?

8. Reproducibility

Can another evaluator reach a similar observation using the same method?

9. Specificity

Which user, task, version and operation does the evidence concern? A general log may not distinguish the particular behaviour.

10. Proportionality and privacy

Were unnecessary personal or organisational data collected for the evidence? Strong evidence does not mean unlimited data collection.

Types of evidence

Different classes of evidence can be used together in an audit.

1. Policy and contract evidence

Organisational policy

Agent task contract

Consent document

Authority record

Service catalogue

Shows what should happen. On its own, it does not show what actually happened.

2. Configuration evidence

Agent instructions

Tool permissions

Model and version record

API scope

Queue settings

Stopping policy

Shows how the system was configured.

3. Behavioural evidence

Tool call

Action receipt

Test execution log

Delegation to a subagent

Human approval record

Shows what the system did in a particular situation.

4. Outcome evidence

Message in the recipient's inbox

Bank or payment record

Live web output

Changed customer record

Actual API state

Shows what happened in the outside world.

5. Recovery evidence

Stop receipt

Queue cancellation

Token invalidity

Rollback result

Handover of control to a human

Restart record

Shows behaviour at the point of an error or withdrawal.

6. Human evidence

Statement by an authorised person

Conversation record

Explanation of approval

Objection by an affected person

Important, but it may not prove the technical outcome on its own.

7. Independent external evidence

Recipient confirmation

Third-party system record

Independent live readback

External measurement

Provides a result separate from the system's own report.

What does a screenshot prove?

Screenshots are useful in an audit, but their role is limited. A screenshot can show that particular text appeared on a screen at a particular moment. On its own, it does not prove that:

the page was genuinely the canonical source,

the content was the same at the time of the event,

the underlying data were the same,

other users saw the same thing,

the image was not cropped,

the agent used that page,

the action actually took place,

the page did not show different content to bots.

A screenshot is stronger evidence when accompanied by:

The URL or system identifier

The date and time

The time zone

The user role

The full-screen context

The relevant network or source record

The file integrity value

A second, independent method

A screenshot records an observation; it is not, on its own, an authoritative determination of the fact.

What does a log prove?

Logs can be strong evidence. But a log is not an unlimited account of reality. Ask:

Which system produced it?

Which events does it not record?

Are the clocks synchronised?

Can it be altered afterwards?

Is the logging level sufficient?

How many agents use the same service account?

Are failed and successful operations both retained?

Does the absence of a log entry mean the action did not occur?

If a message does not appear in a sending log:

the message may not have been sent,

the log retention period may have expired,

another tool may have been used,

the service account may have been different,

logging may have failed.

Therefore:

NOT IN THE LOG ≠ DEFINITELY DID NOT HAPPEN

An appropriate judgement might be: ‘No record was found in the logs examined; because of other sending routes and retention limits, that absence does not support a conclusive finding.’

What does a hash prove?

Comparing a file's cryptographic digest, or hash, with an earlier digest stored reliably helps check whether the file has changed. That is valuable. But a hash does not prove that:

the file came from the correct source,

its contents are true,

it includes all important context,

it was actively used at the time of the event.

An incorrect file can also have a correct hash. A fabricated report can be retained unchanged. Hash comparison helps check integrity. It does not establish truth. Four separate concepts must therefore be distinguished:

INTEGRITY: Has the file changed? AUTHENTICITY: Did the file really come from the claimed source? AUTHORITY: Does the source have authority to decide this matter? ACCURACY: Is the content consistent with the facts and context?

Strong evidence for one does not automatically establish the others.

What does a digital signature prove?

A valid digital signature, provided the requirements for the key used and the verification process are met, can show that:

the document was signed with the verified signing key,

the document has not changed since it was signed.

An ordinary approval record does not automatically carry the same cryptographic assurance. In either case, identity mapping, the scope of approval and decision-making authority must be assessed separately. The signatory may:

have incorrect information,

lack authority over the matter,

misunderstand the scope,

not have seen all the document's annexes.

A signature therefore helps answer ‘Who approved it?’ only when accompanied by reliable identity mapping and a clear approval context. On its own, it does not establish that the content is unquestionably correct.

What does a citation prove?

An AI answer may cite the correct web page. This can show that the model associated that page with the answer as one of its sources. It does not show that every claim in the answer appears on the page. The audit must compare at least these three elements:

The claim in the answer

The actual text of the cited source

The limits within which the source supports the claim

A citation is evidence of a connection. Whether the source supports the claim in substance must be verified separately.

Can AI output be evidence?

Yes, but it must be clear what it is evidence of. An AI answer may be evidence of what the agent said at a particular moment. It is not evidence that its claim about the outside world is true. An agent may explain, ‘I took this price from the website.’ That is the agent's own account. Actual source use must be verified through:

the retrieval record,

the source identifier,

the tool call,

the action receipt.

Several agents saying the same thing is not independent evidence either. They may all have used the same source or one another's outputs.

Raw and derived evidence

The audit must distinguish two types of evidence.

Raw evidence

The record closest to the source. Examples:

Original API response

Raw log extract

Signed contract file

Live HTML

Sent-message record

Consent registry

Derived evidence

This may take the form of:

a summary of raw evidence,

a classification of it,

a masked version,

a table,

a chart,

an agent's interpretation.

Derived evidence is useful, but it must be linked to its raw origin. A summary may say, ‘36/36 access tests passed.’ The auditor must be able, when necessary, to see which 36 tests were run, when, and with which user agent.

Evidence transformations

Evidence may be transformed during an audit. For example:

Personal data are masked.

Logs are filtered to the relevant time interval.

Different time zones are reconciled.

Files are converted to a common format.

AI is used to classify events.

Text is extracted from an image.

Multiple records are combined in one table.

Each transformation must be recorded. These questions must be answered:

Which tool was used?

Which version?

Which fields were removed?

Which values were masked?

Did the meaning change?

Is the raw source preserved?

Can the transformation be reproduced?

Transformed evidence must not be presented as a raw source.

Masking and redaction

Audit evidence may contain personal information or trade secrets. Parts of it may therefore be concealed. Redaction must not:

alter material context,

create confusion about the target’s identity,

distort the relationship between event times,

leave only favourable material visible.

A customer’s name could, for example, be replaced with the pseudonym Müşteri-017. But assigning the same pseudonym to two different customers could undermine an investigation into action against the wrong target. The redaction record must contain the following information:

redaction_applied: true
redacted_fields:
  - personal_name
  - email_local_part
reason:
  privacy_protection
performed_by:
  AUDITOR-02
raw_source_retained:
  secure_vault

The public report may be redacted while controlled access to the raw evidence remains available for an authorised re-examination.

Clocks and time zones in the evidence chain

Clocks may differ across systems.

The email service uses UTC.

The CRM uses local time.

The agent’s server clock is a few minutes slow.

The external platform uses another time zone.

These differences can put events in the wrong order. Human approval given after a message was sent might appear to have preceded it. Evidence records must therefore include:

an absolute timestamp,

the time zone,

the clock source,

any known clock offset.

Clock synchronisation may itself need to be audited.

Counterevidence

An auditor must not collect only records that support the initial hypothesis. There is another question to ask: what evidence challenges this judgement? Consider the claim that an agent sent a message without approval. Supporting evidence might consist of:

the sent message,

the absence of an approval record,

the tool call.

Counterevidence might include:

a human manager’s general campaign approval,

a claim that standing authority to send had already been granted,

an approval record held in another system.

The auditor assesses this counterevidence. General approval may indeed exist, yet its scope may not cover this particular message in terms of:

target,

the approval’s period of validity,

channel,

message type.

Making the counterevidence visible strengthens the judgement.

Missing evidence and uncertainty

Some events cannot be reconstructed with certainty. Logs may have been deleted, a former employee’s account closed, or an external provider may not retain records. The auditor must not fill these gaps with guesses. The following statuses may be used:

Verified

Strongly supported

Partly supported

Conflicting evidence

Insufficient evidence

Could not be verified

Evidence lost

‘Could not be verified’ does not mean ‘did not happen’. ‘Insufficient evidence’ does not mean ‘the system is safe’.

Loss of evidence is itself a finding

If an organisation cannot later reconstruct high-impact agent behaviour, the problem is more than a difficult audit. It is a governance gap in its own right. For example:

It is not known which agent sent the message.

There is no record of human approval.

The price source used cannot be found.

The token revocation date is unknown.

No stop receipt is retained.

Whether the event was favourable or harmful may remain uncertain. One thing is established, however: the organisation is not keeping auditable records of significant agent behaviour. Loss of evidence can be a finding in its own right.

Evidence independence

A system’s own records are not all worthless. But relying exclusively on them to verify that same system is risky. A web publishing agent might:

upload a file,

produce a log saying ‘Upload successful’,

read its own log and report ‘Live verification passed’.

All three steps share a single information source. Independent verification might use:

a read-back of the live site over HTTPS,

a different browser,

an external observation point,

a separate audit account.

Independence does not always require another company. A different system within the same organisation, separate from the action being checked, may also provide independent evidence.

Evidence packages

An evidence package can be assembled for each material audit claim.

Evidence Package

For example:

EVIDENCE PACKAGE — PRICE-INCIDENT-01

Claim: On 8 September 2026 at 09.14, the sales agent sent a message to a customer using the invalid price of 350 USD. Canonical fact: the valid general starting price was 500 USD/month. Raw evidence:

PRICING-REGISTRY-v4.2

The CRM template version in use at the time of the event

The sales agent’s retrieval record

The sent email

Approval from the human price owner

An archived version of the web page from before the event

Operational reality: the 350 USD record was active in the agent’s knowledge index. Action outcome: the customer received a message quoting 350 USD. Counterevidence: the company’s current web page shows 500 USD. Assessment of counterevidence: the current page shows the correct state after the event; it does not invalidate the record of the agent’s input at the time of the event. Integrity records:

File hashes

Email message ID

Timestamps

Archive version IDs

Unresolved uncertainty: who first entered the old CRM price could not be verified. Audit judgement: the authoritative price was 500 USD. The operational source used by the sales agent contradicted the canonical price. The event corresponds to GBO-ERR-012, GBO-ERR-016 and GBO-ERR-092.

This package does not rest the judgement on a single document or screenshot. It shows the entire behavioural chain.

Canonical Fact Registry

This chapter’s first required output is:

NOMOS GBO Canonical Fact Registry.

The registry brings together the material facts within the audit scope.

Human-readable example

CANONICAL FACT RECORD

Fact ID: CANON-PRICE-MSO-2026-04

Entity: NobleAxis Managed Site Operations

Fact type: General starting price

Canonical value: 500 USD/month

Scope:

New direct customers

Base managed site operations service

Hosting and third-party licences excluded

Taxes considered separately under the contract

Out of scope:

Hosting Core at 200 USD/year

Customer-specific maintenance contracts

Contracts retaining an earlier price

Human owner: Commercial Operations Lead

Authoritative source: Pricing Registry v4.2

Human-facing representations:

English service page

Turkish service page

Proposal template v5.1

Machine-facing representations:

Service Catalog v4.2

Structured Data v3.8

Sales Agent Knowledge Index v7.1

Valid from: 1 September 2026

Valid until: A new authoritative version is published

Invalidating events:

Approval of a new price

Change in service scope

Change in the applicable legal pricing policy

Exceptions:

A signed customer-specific contract

A dated campaign record

Superseded record: CANON-PRICE-MSO-2026-03 — 450 USD/month

Last verification: 8 September 2026, 08.42

Unresolved contradiction: The old price of 350 USD in CRM Template v2.8

Status: Active; operational propagation incomplete

Machine-readable Canonical Fact Registry

canonical_fact:
  fact_id: CANON-PRICE-MSO-2026-04

  entity:
    entity_id: SERVICE-MSO-001
    canonical_name: Managed Site Operations

  fact_type: starting_price

  value:
    amount: 500
    currency: USD
    billing_period: month

  scope:
    customer_type:
      - new_direct_customer
    included:
      - managed_site_operations_base_scope
    excluded:
      - hosting_core
      - third_party_licenses
      - taxes_unless_contractually_included

  owner:
    human_role: commercial_operations_owner
    approval_record: APPROVAL-PRICE-2026-104

  authoritative_source:
    source_id: PRICING-REGISTRY-4.2
    source_role: canonical_authority

  representations:
    human:
      - SERVICE-PAGE-EN-v6.1
      - SERVICE-PAGE-TR-v6.1
      - PROPOSAL-TEMPLATE-5.1
    machine:
      - SERVICE-CATALOG-4.2
      - STRUCTURED-DATA-3.8
      - SALES-KNOWLEDGE-INDEX-7.1

  validity:
    effective_from: 2026-09-01T00:00:00+03:00
    effective_until: null
    invalidate_on:
      - authorized_price_change
      - service_scope_change
      - applicable_legal_pricing_policy_change

  exceptions:
    allowed_only_when:
      - signed_customer_contract
      - approved_time_limited_campaign

  supersedes:
    fact_id: CANON-PRICE-MSO-2026-03

  conflicts:
    - source_id: CRM-TEMPLATE-2.8
      conflicting_value: 350
      status: obsolete_unresolved_copy

  status: active_with_propagation_gap

This record does more than store the value of 500 dollars. It shows that value together with its:

owner,

scope,

representations,

validity,

unresolved contradiction.

Evidence Registry

This chapter’s second required output is:

NOMOS GBO Evidence Registry.

Each evidence record identifies the claim or finding it supports and its own limitations. The pricing incident in this chapter is a teaching case separate from the outdated v3.7 pricing record in the customer-discovery example. Here, the identifiers are PRICING-REGISTRY-v4.2 and GBO-AUDIT-PRICING-2026-001. Evidence from the two files must not be combined as though it belonged to a single frozen scope.

Human-readable evidence record

Evidence ID: EVID-PRICE-INCIDENT-004

Audit ID: GBO-AUDIT-PRICING-2026-001

Evidence type: Agent action receipt and source trace

Source system: Sales Agent v2.4

Source role: Behavioural evidence

Related event: The 09.14 pricing email

Acquisition time: 8 September 2026, 10.12

Collected by: Auditor AUDITOR-02

Raw record: ACTION-EMAIL-8841

Integrity record: Hash and message ID recorded

What it shows:

The sales agent sent the email.

The message used a price of 350 USD.

CRM-TEMPLATE-2.8 was recorded as the source ID.

No human approval record was found.

What it does not show:

Who originally created the CRM template

Whether the human manager used another channel to give general approval for sending

Whether the customer legally accepted the offer

Transformations applied:

The customer’s email address was masked.

Personal signature details were removed while preserving the message body.

Raw record location: Encrypted evidence vault

Findings supported:

FINDING-AUTH-03

FINDING-CANON-02

Counterevidence:

The current web page shows 500 USD.

Status: Verified

Retention period: 180 days; reassess if a dispute is ongoing

Machine-readable Evidence Registry

evidence_record:
  evidence_id: EVID-PRICE-INCIDENT-004
  audit_id: GBO-AUDIT-PRICING-2026-001

  evidence_type:
    - action_receipt
    - source_trace

  source:
    system_id: SALES-AGENT-2.4
    record_id: ACTION-EMAIL-8841
    source_role: behavioral_evidence

  acquisition:
    collected_by: AUDITOR-02
    collected_at: 2026-09-08T10:12:00+03:00
    method: read_only_export

  integrity:
    hash_algorithm: SHA-256
    hash_value: recorded_in_secure_vault
    source_message_id: MSG-928472
    integrity_status: verified

  temporal_relevance:
    event_time: 2026-09-08T09:14:00+03:00
    time_alignment: direct

  observations:
    - email_was_sent
    - stated_price_was_350_USD
    - source_id_was_CRM_TEMPLATE_2_8
    - explicit_human_approval_not_present_in_record

  limitations:
    - does_not_identify_original_creator_of_CRM_template
    - does_not_exclude_approval_existing_in_unreviewed_channel
    - does_not_establish_contract_acceptance

  transformations:
    - customer_email_masked
    - personal_signature_removed

  supports:
    findings:
      - FINDING-AUTH-03
      - FINDING-CANON-02

  counter_evidence:
    - EVID-WEB-CURRENT-001

  storage:
    location: encrypted_evidence_vault
    access:
      - lead_auditor
      - authorized_client_reviewer

  retention:
    days: 180
    deletion_receipt_required: true
    review_on_ongoing_dispute_or_preservation_duty: required
    example_duration_not_universal_legal_rule: true

  status: verified

Evidence Registry statuses

Processing history, verification status, challenges and access conditions must be tracked separately. Several of the following labels may apply at once. A record can, for example, have verified integrity, restricted access and disputed content:

Collected

Integrity verified

Authenticity verified

Partly verified

Conflicting

Challenged

Invalidated

Superseded by new evidence

Expired

Evidence lost

Access restricted

Archived

Deleted and receipt created

If evidence later proves incorrect or incomplete, its record must not be silently deleted. Its status must be changed so that readers can understand why the earlier judgement changed.

Claim–Evidence Matrix

Every significant audit claim must be mapped to evidence that supports it and evidence that challenges it.

This matrix keeps the auditor’s statements within what the evidence can support.

Minimum evidence-package fields

Every high-impact finding must contain at least the following fields:

claim expected_state observed_state canonical_fact raw_evidence operational_evidence action_evidence outcome_evidence counter_evidence time_alignment transformations limitations uncertainties reviewer judgment

If a finding rests solely on a screenshot, a human statement or the agent’s own account, that basis must be made explicit.

Evidence retention and data minimisation

Audit evidence must not be kept indefinitely. Its retention period may depend on:

risk level,

the status of any dispute,

the contract,

data-protection requirements,

the need for retesting,

the incident’s closure status.

Where possible:

mask personal data,

remove unnecessary content,

restrict access to raw evidence,

keep the public report to a summary,

produce a receipt once deletion is complete.

But evidence minimisation must not strip away critical context. Suppose only the message body is retained, while the following are deleted:

recipient,

time,

source ID,

approval record.

That can make the event impossible to audit.

Evidence vaults and access

Critical evidence may be held in a separate evidence vault. This may provide:

access control,

a change log,

encryption,

integrity verification,

versioning,

a deletion policy,

a record of who viewed which evidence.

Auditors must not copy all evidence to a personal device or an unapproved cloud tool. AI tools used to analyse evidence must also be authorised.

AI-assisted evidence analysis

An audit agent can:

classify thousands of log entries,

build a timeline,

group similar events,

compare language versions,

flag conflicting sources.

This is useful, but there are limits:

AI output must not replace raw evidence.

The AI’s classification must not be treated as independent verification.

AI output must not determine the final finding on its own.

An audit agent might say, ‘This record appears to show a breach of authority.’ The human auditor must examine:

the actual authority agreement,

the scope of the operation,

the counterevidence.

The evidence chain must also show the following details of the AI system used in the audit:

version,

data access,

transformation method.

Evidence contamination

Synthetic records produced during an audit may become mixed with real operational data. For example:

A customer record created for the audit is added to the real customer list.

A test price is written to the sales catalogue.

An attack scenario remains in the agent’s memory as a genuine instruction.

An audit email address becomes a future sales target.

A synthetic consent record is linked to a real person.

We can call this:

Evidence and Test Contamination

Audit data must be clearly marked. At the end of the test:

remove it from the active system,

retain the necessary evidence copy,

remove the changes left in memory,

create a deletion or archiving receipt.

An audit must not change the system unnoticed while examining it.

Twelve steps for auditing canonical facts

1. Identify material claims

List facts that affect behaviour, such as price, authority, consent, scope, capacity and outcome.

2. Identify the entity uniquely

Prevent confusion with another person, company, service or agent.

3. Classify the fact type

Place each claim in the appropriate family of facts.

4. Identify the human owner

Who is responsible for keeping the fact current and accurate?

5. Identify the authoritative source

Which record has authority to make the final determination for this type of fact?

6. Find the operational sources

Which copy or index does the agent actually use?

7. Fix the time and scope

At the time of the event, which value applied to which user and operation?

8. Distinguish exceptions from contradictions

Is this a special contract, a campaign or a historical record?

9. Check parity across human, machine and language representations

Do all representations carry the same factual contract?

10. Build the evidence chain

Link the raw source, integrity, transformation, observation and counterevidence.

11. Verify propagation

Has the canonical correction reached every relevant system?

12. Retest the behaviour

Does the agent now take the right action on the basis of the right fact?

Canonical Facts and Evidence Chain Gate

Before a claim becomes an audit judgement, the following gates must be assessed:

1. Entity Gate

Does the fact concern the correct person, organisation, service or agent?

2. Fact Type Gate

Does the source have authority to decide on this subject?

3. Human Ownership Gate

Have we identified the human owner responsible for this fact?

4. Scope Gate

Have the general rule, exception and specific operation been distinguished?

5. Time Gate

Does the evidence align with the time of the event and the period of validity?

6. Representation Parity Gate

Do human-facing, machine-facing and different language representations convey the same material fact?

7. Operational Access Gate

Do we know which source the agent actually used?

8. Provenance Gate

Are the evidence’s original source and the chain through which it was derived visible?

9. Integrity Gate

Can it be verified that the evidence is unchanged and its transformations have been recorded?

10. Independence Gate

Does the outcome rely solely on the audited system’s own statement?

11. Counterevidence Gate

Have records that contradict the judgement been assessed?

12. Privacy Gate

Has more data been collected than the audit requires?

13. Reproducibility Gate

Could another evaluator reach a similar conclusion from the same record?

14. Retention and Validity Gate

How long will the evidence be retained, and under what access conditions? Put simply:

AUDITABLE REALITY = CORRECT ENTITY AND CORRECT FACT TYPE AND AUTHORISED HUMAN OWNER AND DEFINED SCOPE AND VALID TIME AND REPRESENTATION PARITY AND OPERATIONAL SOURCE TRACE AND EVIDENCE PROVENANCE AND INTEGRITY AND INDEPENDENT VERIFICATION AND COUNTEREVIDENCE REVIEW AND PROPORTIONATE DATA USE

Critical uncertainties about the facts

Some uncertainties may require behaviour to be suspended before scenario testing begins. For example:

The valid price is unknown.

There are conflicting accounts of who holds authority.

The consent record cannot be found.

The data source used by the agent is unknown.

Human-facing and machine-facing representations show different scopes.

It is not possible to establish which account produced the sending outcome.

There is reason to suspect that the evidence was altered after the event.

Subagent output is being used as an independent source.

Only a current screenshot is available for an operation approaching critical risk.

The appropriate audit response is not, ‘There is not enough evidence, but let us continue anyway.’ It may instead be: ‘The relevant high-impact behaviour must be restricted until the facts and the evidence path are clear.’

What should an agent do when canonical facts are unavailable?

When an agent encounters two conflicting price, role or consent records, it must not invent a new fact. The appropriate response may vary with the risk:

Low risk

Explain the uncertainty and present the possible options.

Medium risk

Seek the authoritative source or human owner.

High risk

Stop the action and hand the decision to a human. The agent might say: ‘There are two active records for this service: 500 and 350 USD. The 500 USD price is in the pricing registry; 350 USD appears in an old CRM template. I will not send the customer a price without confirmation from the person responsible for the canonical commercial fact.’ This answer may look like an unfinished task. In fact, it is sound behaviour.

What should an auditor do when the evidence chain is missing?

If the auditor cannot find enough evidence to verify a claim, there are three possible responses:

1. Narrow the claim

‘The rule’s presence in the policy was verified; its application in actual behaviour could not be verified.’

2. Request further evidence

Raw logs

A version record

An independent test

Approval from the human owner

3. Raise an Insufficient Evidence Finding

‘Within the scope examined, we could not obtain sufficient records to reconstruct human approval for the high-impact action. It is not yet clear whether the record was never kept, was lost or was not made available for review.’ An auditor must not fill that gap by assuming the system can be trusted.

Required outputs from this chapter

By the end of this chapter, the audit file must contain two structures:

1. Canonical Fact Registry

This contains all material facts within the audit scope concerning identity, price, scope, capacity, consent, authority and outcome.

2. Evidence Registry

This identifies the evidence behind every claim, test, finding, outcome and recovery judgement. It records the evidence’s provenance, time, integrity, transformations and limitations. Both registries must connect to the Behaviour Map. Every significant node in the map must provide access to:

the canonical fact,

the relevant evidence,

the human owner.

The combined output of the first four chapters

The audit’s foundation is now in place. We have:

Audit Claim Card

This shows what we are trying to prove.

Audit Authorisation Document

This sets out what the auditor may do and within which limits.

Scope Freeze Record

This fixes the system version under audit.

Human–Agent–Tool Behaviour Map

This shows all behavioural paths, from human intent to external action, evidence and stopping.

Canonical Fact Registry

This identifies the authoritative source, owner, scope, time and exception for each material fact.

Evidence Registry

This makes it possible to reconstruct how the audit judgement was reached. It is possible to move straight to test scenarios without these structures. But the tests may then examine the wrong system, the wrong fact or the wrong authority.

The chapter’s judgement

Correct information on an organisation’s website does not prove that its agent used correct information. A correct price in the authoritative registry does not show that all operational sources are current. Having a screenshot does not reconstruct the system at the time of the event. A hash comparison checks for changes against a reliable earlier record; it does not prove that the file’s content is true. A digital signature may identify the signer, not establish that the content is always true. A citation may show a source connection, not establish that the claim is actually supported. An AI explanation shows what the system said; on its own, it does not prove why the behaviour occurred. The chapter’s first judgement is this: canonical facts are not merely values. They connect the correct entity, fact type, authorised owner, scope, time, exception and version.

Second: a canonical source need not be one file containing everything. What matters is knowing which source has authority for each type of material fact. Third: a general rule, a temporary exception and a specific operation must not overwrite one another in the same fact field. Fourth: today’s correct record does not automatically prove what an agent saw in the past or what it acted on. Fifth: human-facing, machine-facing and different language representations must carry the same factual contract governing behaviour. Sixth: the existence of evidence is not enough. Its provenance, time, integrity, transformations, independence and limitations must be known. Seventh: absence of evidence is not absence of error. Inability to reconstruct significant behaviour is a separate governance finding.

Eighth: an evidence chain is not a private chain of thought. It is an observable trail of sources, authority, action, outcome and recovery. And the final judgement: an audit cannot reach a definitive conclusion beyond the reach of its evidence. We now know:

what we are auditing,

who authorised us,

which behavioural paths the system uses,

which facts are canonical,

which evidence supports those facts.

But the 99 errors defined in Volume II are not equally relevant to every system. A document-summarising agent may face no pricing-error risk. For a purchasing agent, budget, subscription and duplicate-payment errors may be critical. In an avatar system, consent and synthetic identity are veto-level concerns. For a web agent, live publication, canonical data and rollback come to the fore. For a customer-discovery agent, correct recipient identification, personal data and authority for external sending are decisive. The same error may have limited impact in a low-risk draft, yet affect millions of people or a high-value transaction in another system.

The next step is therefore not to test all 99 errors at random. First, we must answer:

Which error families actually apply to this system? Which are most likely? Which cause the greatest harm? Which are irreversible? Which should invalidate the overall score after a single event? Which behaviours must be restricted immediately? Where should testing resources go first?

The next chapter will develop:

GBO-99 Risk Map and Veto Gates

Canonical facts and strong evidence show us what the system is. The risk map shows where a failure would matter most.

Every error deserves to be tested. But errors do not all have the same priority, cause the same harm or carry the same weight in a judgement.