A company submits its customer discovery and communication agent to a comprehensive GBO audit. The audited version comprises:
Sales Orchestrator v2.6 Communication Policy v4.0 Authorization Gateway v1.0 CRM Queue v2.4 Calendar Agent v1.8
The audit does not produce a single, unrestricted success verdict. The system is verified within the defined scope for:
research into publicly available company information,
suitability assessment,
message drafting.
One-off email sending is conditionally verified only under human approval that:
is bound to the correct recipient,
covers the final text,
is valid for the specified channel,
is short-lived,
takes the form of a single-use human approval token.
Automated follow-up campaigns and WhatsApp communication are outside the audit scope. The Arabic and Russian behavioural versions have not yet been tested. Positive judgements in this example are limited to Turkish, English and German; Spanish is not included either. The human-stopping violation found during the audit has been repaired, and the email, calendar, CRM follow-up and social direct-message paths have been retested. The audit judgement reads: research and drafting behaviour are verified within the defined scope. One-off email sending is conditionally verified only under human approval bound to the task, target, channel and final text. Positive judgements are limited to Turkish, English and German. Automated follow-up, WhatsApp and other language versions fall outside this judgement.
This statement makes clear:
which behaviour was audited,
what passed,
which conditions are required,
what remains out of scope.
The company's marketing team finds this long explanation too complicated. A shorter badge is placed on the website's homepage:
GBO VERIFIED
No scope, version or date appears beneath the badge. It does not link to an audit record: clicking it takes the visitor only to the company's product page. That page states: “An independently verified, human-controlled and fully autonomous sales agent.” This goes beyond the original audit judgement. The system:
has not been verified for fully autonomous external communication,
has not been tested in every language,
has not received a positive judgement for automated follow-up.
Despite this, on the day the badge is first published, the system is still the audited version. Three weeks later, the company adds features. It enables Spanish and Arabic customer discovery flows, connects a WhatsApp tool and activates a campaign module that sends prospects three follow-up messages without human intervention. The provider updates the foundation model to a new version in the background. Persistent memory is expanded. The daily sending limit rises from 20 to 100. The audited Authorization Gateway is unchanged, but the WhatsApp tool is not connected to it. The system's human owner has also moved to another role. The incoming manager is not fully familiar with the previous stopping and restart rules.
None of this is reflected in the public badge. The website continues to display:
GBO VERIFIED
The public cannot see the audit date, the audited version, the exclusion of the new behaviours or the outstanding conditions. A month later, a user stops all external communication. Email and calendar paths stop, but the new WhatsApp campaign module continues sending. Messages reach three prospects. After the incident, the company states: “Our system previously underwent an independent GBO audit. The problem stems only from a new integration.” This is partly true in technical terms: the system was indeed audited. But the public badge now conceals a fact: today's system is not the system that was audited.
An audit judgement may be correct on the day it is issued. It cannot automatically carry forward when:
the system changes,
a tool is added,
the human owner changes,
the model is updated,
a new language or channel is enabled,
a critical incident occurs.
The protocol's final main principle is therefore:
An audit result must remain accurate beyond the day it is published.
The public statement must:
state the correct scope,
be tied to the audited version,
explain its validity conditions,
be suspended after a material change,
be reassessed after a critical incident.
Otherwise, a sound audit can become a misleading signal of trust over time.
An Audit Judgement Is Not a Public Statement
An audit judgement is an institutional record that is:
technical,
detailed,
specific to a behaviour unit,
explicit about the limits of the evidence and risk.
A public statement is the external representation of that judgement. It must be:
understandable,
concise,
accessible,
open about material limitations.
A public statement need not republish the entire technical report. It must not, however, offer the public broader assurance than the audit judgement supports. The basic relationship is:
PUBLIC STATEMENT ⊆ AUDIT JUDGEMENT ⊆ EVIDENCE
The public statement stays within the audit judgement's limits. The judgement, in turn, does not exceed what the evidence permits.
What Is a Public Audit Statement?
Its canonical definition is this: the NOMOS GBO Public Audit Statement is the external representation of an audit judgement concerning a particular agent system or behaviour unit, published in a form that humans and machines can verify, together with system identity, version, scope, conditions, evidence level, open limitations, validity period and current status. Put simply, a public statement does not merely say “This system was audited”. It shows exactly what was verified, in which version, under which conditions and until when.
A Public Statement Is Not an Advertising Slogan
Advertising favours phrases such as:
Safe Verified Fully compliant Human-controlled Error-free Independently audited GBO-certified
Any of these can mislead when detached from its scope. For example, what does “human-controlled” actually mean?
Can a human stop the system at any time?
Does the human approve only high-value transactions?
Is the human merely informed after the result?
Does the stop button halt the central agent or the entire network?
Has handover of control to a human actually been tested?
Without an explanation, the phrase creates an appearance of trust. It does not reveal the actual behaviour.
Audited, Verified and Certified Mean Different Things
These three words must not be confused in public-facing language.
Audited
A specified process of examination and testing has been carried out. This word does not necessarily mean a positive judgement was issued. A system may have been audited and found unsuitable because of critical findings.
Verified within the Defined Scope
This means that a particular behaviour has shown the expected outcome with the following parameters defined:
version,
tool,
authority,
language,
scenario,
evidence level.
The statement is limited. It does not guarantee all of the system's future behaviour.
Certified
Use this term only where the following exist:
a predefined formal certification programme,
clear decision criteria,
an authorised certificate issuer,
a surveillance and revocation process,
a public certificate registry.
A consultancy audit or organisational self-assessment is not automatically certification. An audit result must not be marketed as a certificate; if a certification system exists, it must be defined separately.
Fourteen Required Fields in a Public Statement
A trustworthy public statement must answer at least fourteen questions.
1. Audited Subject
2. Technical Version
3. Audited Behaviours
4. Out-of-Scope Behaviours
5. Conditions of Use
6. Language, User and Geographical Scope
7. Audit Judgement
8. Evidence Level
9. Open Critical Findings and Veto Status
10. Date of Issue
11. Validity and Expiry Conditions
12. Auditing Party and Level of Independence
13. Canonical Audit Record
14. Channel for Correction, Appeal and Notification
1. Audited Subject
The statement must not use the brand name alone. For example, “NobleAxis is GBO-verified” leaves these questions unanswered:
The entire company?
One agent?
One service?
The website?
The sales system?
Does it include subsidiaries?
A more accurate record would read: “NobleAxis Sales Orchestrator v2.6 — research, suitability assessment, drafting and task-specific, human-approved one-off email sending behaviours.”
2. Technical Version
At a minimum, the public statement must disclose the material version relationships from this list:
Agent version
Policy version
Authority version
Tool or integration version
Foundation model version, where necessary
Audit record version
Not every technical detail needs to appear on the main badge. It must, however, be accessible in the canonical record.
3. Audited Behaviours
“Sales agent” is not, by itself, a behavioural scope. The following can be listed separately:
Research into publicly available company information
Suitability analysis
Suggested contacts
Email drafting
Human-approved sending
Automated follow-up
Calendar invitations
Price quotations
Contract acceptance
Verification of one behaviour does not verify the others.
4. Out-of-Scope Behaviours
Material exclusions must be public. For example: “WhatsApp, automated follow-up, price commitments, contract acceptance, and behaviour in Arabic and Russian are outside this audit's scope.” Exclusions must not be buried in a small supplementary file. If they could materially change a user's overall assessment of trust, they belong in the main summary.
5. Conditions of Use
Where verification is conditional, the conditions form part of the judgement. Examples include:
A human approval token
A transaction limit of 100 USD
Approved vendors only
External data transfer disabled
Draft mode
Use of synthetic identities
Specified channels
A specified human role
“Conditions apply” is not enough. The conditions must be stated explicitly.
6. Language, User and Geographical Scope
A system may have been tested in English. That result does not automatically produce a judgement for:
Turkish,
Arabic,
Russian,
a different legal environment,
a different user group.
The public record may show the distinction as follows:
Fully tested: - Turkish - English - German Limited testing: - Spanish Not tested: - Arabic - Russian
7. Audit Judgement
Each behaviour unit must carry its own judgement:
Verified within the Defined Scope
Conditionally Verified
Limited Use
Remediation and Retesting Required
Unsuitable for the Behaviour Concerned
Insufficient Evidence
Audit Invalid on Integrity Grounds
The public statement must not highlight only the best result while concealing other material results.
8. Evidence Level
The entire evidence vault need not be opened to the public. The statement must nevertheless explain the level at which the judgement was verified:
Document review
Configuration review
Controlled behavioural test
Independent verification of the external outcome
Stopping and recovery drill
For example: “Human stopping and queue cancellation behaviour was tested through a controlled live drill and external outcome verification.”
9. Open Critical Findings and Veto Status
If a veto remains open, the public cannot be told “The system is verified.” The status of the behaviour concerned must be explicit. For example: “Automated follow-up behaviour has not been verified and is disabled because of a finding concerning stopping across the chain.” Technical attack details may be withheld from the public. The result that affects user trust must not be hidden.
10. Date of Issue
An audit statement cannot be undated. At a minimum, it must show:
the audit period,
the judgement date,
the latest status check.
“Audited” might otherwise refer to the system as it was ten years ago.
11. Validity and Expiry Conditions
An expiry date alone is not enough. The public statement must also explain which changes invalidate or suspend the judgement before that date. Examples include:
A new external communication tool
A model change
Expanded authority
New persistent memory
A new language
A new sub-agent
A critical incident
A change of human owner
A change in stopping controls
12. Auditing Party and Level of Independence
The public record must distinguish between:
Self-assessment
Independent internal review
Independent external audit
Multi-party high-risk audit
An organisation must not present its own test as “independent verification”. Any material involvement the auditor has had in developing or repairing the system must be disclosed.
13. Canonical Audit Record
A badge or short statement must link to a current, versioned canonical record. That record must contain:
a unique identifier,
current status,
version,
scope,
date,
an integrity record,
previous versions.
A screenshot or social media post is not a canonical record.
14. Channel for Correction, Appeal and Notification
Anyone who sees a difference between the public statement and actual system behaviour must be able to report:
incorrect scope,
an outdated badge,
a new incident,
a technical problem,
a human right affected by the system's behaviour.
This channel must not be merely a general sales form. It must link to the audit identifier and behaviour record.
The Grammar of a Public Statement
A trustworthy public statement can use this structure:
[AUDITED SYSTEM AND VERSION] + [AUDITED BEHAVIOUR] + [JUDGEMENT] + [MANDATORY CONDITIONS] + [OUT-OF-SCOPE AREAS] + [AUDIT DATE AND VALIDITY] + [CANONICAL RECORD]
Example:
Sales Orchestrator v2.6's research into publicly available company information and email drafting behaviours have been verified within the defined scope in Turkish, English and German scenarios. Suitability assessment and suggestions for the contact's role have been conditionally verified with human verification where needed; one-off email sending has been conditionally verified under human approval bound to the task, target, channel and final text. Automated follow-up, WhatsApp, price commitments, contract acceptance, financial transactions, personal data enrichment, and behaviour in Arabic, Spanish and Russian are out of scope. This illustrative statement is limited to the period from 18 September 2026 at 18.00 to 17 December 2026 at 18.00 (UTC+03.00). A material change or critical finding may suspend the relevant judgement earlier.
The statement may be long. It does, however, convey the trust claim accurately.
Poor and Accurate Public Statements
Poor statement
“Fully GBO-compliant.” It is not clear what is compliant.
More accurate statement
“Research and drafting behaviours have passed a GBO audit within the defined scope.”
Poor statement
“Human-controlled AI agent.” It is not clear how human control was tested.
More accurate statement
“Propagation of the human stop request to the central agent, sub-agents, and connected email and CRM queues was verified in a controlled drill. The WhatsApp integration is out of scope.”
Poor statement
“GBO-certified.” There may be no certification programme.
More accurate statement
“Verified within the defined scope in an independent external GBO audit.”
Poor statement
“Passed all 99 GBO errors.” Some records may be inapplicable or out of scope.
More accurate statement
“All error records from GBO-ERR-001 to GBO-ERR-099 were assessed for applicability; 78 applicable mappings were linked to scenarios, and 12 of the 13 veto candidates were tested.”
A Badge Is Not a Judgement
A badge can serve as a visual signpost. On its own, however, it cannot convey:
Which behaviour
Which version
Which scope
Which conditions
Which date
Which open findings
Current status
A badge must therefore be a doorway to the canonical audit record, not the evidence itself.
NOMOS GBO Badge Statuses
If a badge is used, it must clearly show its actual status.
AUDITED
An audit has been carried out. This does not guarantee a positive judgement.
VERIFIED WITHIN DEFINED SCOPE
The defined behaviours have been verified with sufficient evidence.
VERIFIED WITH CONDITIONS
The conditions are an inseparable part of the judgement.
RESTRICTED USE
The system may be used only for specified low-impact behaviours.
RETEST REQUIRED
Retesting is pending because of a material finding or change.
SUSPENDED
Validity has been temporarily suspended.
EXPIRED
The validity period has ended.
SUPERSEDED
A newer audit record has been published.
REVOKED
The basis of the judgement has become materially invalid, or the statement has been misused.
Badge Status Must Change Visibly
When the system is suspended, changing only the background record is not enough. The public display must also show the relevant status:
suspended,
expired,
retest required,
superseded.
An old badge image can be copied onto third-party pages. Where possible, the badge should therefore be:
linked to the canonical status record,
dynamic,
accompanied by identity and version information.
A static image must not create an appearance of permanent validity.
Forms of Public Statement Misuse
Even an accurate audit result can be misrepresented to the public. Such misuse should be recorded as separate audit findings.
1. Badge Laundering
A visual badge takes the place of the detailed judgement. Limitations remain invisible.
2. Scope Laundering
Only research and drafting behaviour was audited. The entire autonomous sales system is presented as verified.
3. Version Laundering
An old system version's audit result is carried over to new model, tool and authority versions.
4. Time Laundering
An expired audit or one conducted years ago is still used as a current signal of trust.
5. Language Laundering
An English test result is published as covering all six languages.
6. Entity Laundering
A single product or subsidiary was audited. The entire corporate group is presented as verified.
7. Remediation Laundering
A remediation plan has been prepared for a finding. The finding is publicly presented as closed.
8. Evidence Laundering
Only policies and documents were reviewed. Live behaviour is presented as verified.
9. Auditor Laundering
Self-assessment, or a review by the consultant who developed the system, is promoted as an “independent audit”.
10. Veto Concealment
A high overall success rate is published. An open critical veto is left out of the main statement.
11. Condition Concealment
Human approval, a low transaction limit or draft mode is relegated to a small footnote. The badge appears unconditional.
12. Renewal Laundering
The previous judgement has expired. The organisation continues to use an active badge, saying “Renewal is in progress.” Awaiting renewal is not active verification.
What Is Validity?
The canonical definition is as follows: NOMOS GBO audit validity is the reliable use of a particular audit judgement for as long as the relevant system, version, tools, authority, data, human ownership, behavioural scope and risk conditions remain materially unchanged; no critical incident or loss of evidence has occurred; and required control verifications remain current. Put simply, validity is not just a date on a calendar. It asks whether the world of behaviour that was audited is still the same.
Four Joint Conditions for Validity
An audit judgement should remain active only while all four conditions hold:
THE VALIDITY PERIOD HAS NOT EXPIRED AND NO MATERIAL SYSTEM CHANGE AND NO CRITICAL INCIDENT OR NEW VETO AND CONTROLS AND EVIDENCE ARE SUFFICIENTLY CURRENT
If any condition fails, the judgement may be suspended before the end date.
Expiry Does Not Mean Failure
When a judgement expires, it means that the existing evidence no longer provides sufficient assurance about current behaviour. It does not mean the system is definitively unsafe. A system whose audit judgement has expired may still be behaving correctly, but current evidence is missing. Therefore:
EXPIRED ≠ FAILED EXPIRED = CURRENT ASSURANCE NOT DEMONSTRATED
Assurance Half-Life
For some systems, audit evidence can remain meaningful for a long time. For others, assurance becomes outdated rapidly. We can call this operational concept:
Assurance Half-Life
Its canonical definition is this: assurance half-life is a metaphor for old audit evidence becoming inadequate to explain current behaviour as the system and its environment change. “Half” does not mean a measured 50 per cent loss of assurance; this book proposes neither such a statistical model nor a universal duration. It is not a fixed mathematical law. It is a risk-based governance tool.
Factors That Shorten Assurance Half-Life
Frequent foundation model updates
A provider that does not pin versions
Frequent addition of new tools
Broad, dynamic API permissions
Persistent memory changes
Many sub-agents
Rapidly changing canonical data
High staff turnover
Frequent critical incidents
Dependency on external providers
Biometric or financial use
Highly irreversible effects
Limited audit evidence
Factors That Extend Assurance Half-Life
A version-pinned system
A narrow, read-only task
Technically constrained tools
Low external impact
Easy reversal
Strong change control
Regular behavioural canary tests
Clear human ownership
Independent outcome verification
A stable data and task domain
There Is No Universal Validity Period
The NOMOS GBO Protocol does not set a single period, such as “An audit is valid for one year”, for every system. Reassessment needs may differ:
A read-only document summarisation agent without external tools may allow longer intervals,
an autonomous financial agent receiving daily model updates may need shorter intervals,
a biometric publication system may need event-triggered reassessment,
a newly established multi-agent system may need frequent reassessment.
The validity period should be based on:
Risk level
Frequency of model and tool changes
External impact
Reversibility
Incident history
Control maturity
Audit evidence level
Changes in people and the organisation
Validity Status
Every public audit record must carry one of the following statuses.
Draft
This is not yet a public judgement.
Issued
The judgement has been created; its start date may not yet have arrived.
Active
The scope, version and controls remain valid.
Active — Conditional
Valid under specified conditions.
Limited Use
Only the defined lower action levels remain active.
Suspended
Temporarily unavailable for use because of a material change, incident or evidence problem.
Awaiting Retest
Testing is required after remediation or a limited change.
Expired
The calendar term or freshness period has ended.
Superseded
A more current judgement has been published.
Withdrawn
The issuing party no longer supports its own judgement.
Revoked
The judgement has been invalidated because of material misuse, an integrity problem or serious new evidence.
Archived
Retained as a historical record, not as a current statement of assurance.
What Is a Material Change?
A change may be material if it affects at least one of the following:
What the agent can do
On whose behalf it can act
Which data it can read and transfer
Which tools it can use
When it requires human approval
Authority boundaries
Target and user group
Stopping and recovery behaviour
The measurement and reward system
How evidence is generated
The product claim presented to the public
The GBO-99 risk or veto profile
Correcting a typo may be non-material. Adding an email sending tool is material. Changing a button's colour may be non-material. Removing the total cost from the approval screen is material.
Change Classes
The classification established in Chapter 2 is applied here to the validity decision.
Class A — Non-Material Change
Examples:
Typographical correction
A visual change that does not affect behaviour
A change to a log message's format
A clarification in the documentation
Outcome:
The change is recorded.
The judgement may remain active.
A full retest is not required.
Class B — Limited Material Change
Examples:
A particular tool version
New text in one language
A narrow reduction in authority
A limited queue change
An adjustment to a human approval screen
Addition of a low-risk sub-agent
Outcome:
Affected behaviours and cohorts are retested.
The affected new behaviour is placed in awaiting-retest status. Existing scope proven unaffected by the change may remain valid under its own conditions. An untested change does not receive a “Conditionally Verified” judgement merely because it is Class B.
Other behaviours may remain active.
Class C — Fundamental Material Change
Examples:
A foundation model change
A new external action tool
Expanded authority
New persistent memory
New biometric data
New payment or publication capability
New multi-agent orchestration
A change to stopping or rollback architecture
A change of human owner or legal operator
A new country or high-impact user group
A change to the measurement and reward system
Outcome:
The relevant audit judgement is suspended.
A new Scope Freeze Record is created.
The necessary behaviour units are audited again.
The public badge cannot be used as active verification.
Change Log
Every audited system must maintain the following log:
Material Change Log
Minimum fields:
change_id system_id old_version new_version change_description change_class affected_behavior_units affected_tools affected_data affected_authorizations affected_languages risk_assessment required_retest audit_status_effect approved_by implemented_at verified_at
A Change Cannot Classify Itself
A development team may regard its change as “a minor update”, even though its audit impact is substantial. For example: “We only added one-click sending to improve the user experience.” This looks like an interface change. In fact, it changes risks associated with:
approval,
reversibility,
external action,
sending in error.
The change class must be assessed by:
the technical owner,
the behaviour owner,
the risk owner,
the auditor, where necessary.
Silent Updates by External Providers
Some model and tool providers may update their systems without user intervention. The organisation may be unable to:
pin the exact model version,
foresee changes in tool behaviour,
know when the API description has changed.
In that case, the audit judgement may be narrower and its validity period shorter. Controls may need to include:
Provider version records
Behavioural canary scenarios
An alert for changes to tool schemas
Rapid retesting
Human approval for critical actions
An automatic switch to restricted mode when a change occurs
A system whose version cannot be pinned cannot be audited on the assumption that it remains unchanged. Its changes must be monitored through behavioural tests.
Automatic Status Decisions on Material Change
A simple decision rule might be:
IF CLASS A CHANGE → RECORD → JUDGEMENT MAY REMAIN ACTIVE IF CLASS B CHANGE → SET AFFECTED NEW BEHAVIOUR TO AWAITING RETEST → TARGETED RETEST IF CLASS C CHANGE → SUSPEND THE RELEVANT JUDGEMENT → FREEZE A NEW SCOPE → UPDATE THE RISK MAP → RE-AUDIT
A critical incident may trigger emergency suspension regardless of the change class.
What Is Continuous Auditing?
The canonical definition is as follows: NOMOS GBO Continuous Auditing is an ongoing assurance process after publication of the audit judgement. It monitors the system's version, tools, authority, data, human ownership, behaviour, incidents and controls at risk-proportionate intervals and in response to risk-based triggers; classifies material changes; reruns selected scenarios; and limits the judgement automatically or with human approval when a critical deviation occurs. Put simply, continuous auditing checks whether the system still operates within the same behavioural boundaries. It does not assume that a report which was accurate last year remains accurate today.
Continuous Auditing Is Not Uninterrupted Surveillance
Continuous auditing does not mean:
retaining every human message indefinitely,
monitoring all employee behaviour,
giving the auditor access to all private content,
recording every agent thought.
Proper continuous auditing may use:
the event records needed for the behaviour concerned,
authority and tool changes,
the health of critical controls,
selected synthetic scenarios,
anonymous or aggregated measurements.
Continuity creates no right to collect unlimited data. Audit evidence must be:
necessary,
proportionate,
limited to its purpose,
subject to a defined retention period.
Five Layers of Continuous Auditing
1. Configuration and Authority Integrity
2. Control Health
3. Behavioural Sentinels and Canary Tests
4. Incidents, Appeals and External Reports
5. Periodic Re-Audit
1. Configuration and Authority Integrity
The system is monitored for changes involving:
A new agent
A new sub-agent
A new tool
A new token
Expanded authority
Persistent memory
A change of data source
A new language
A new user role
Changes to stopping and rollback
A shared service account
Changes to measurement and reward
This layer answers one question: is the audited system still the same system?
2. Control Health
A control may exist in the source code yet fail in practice. Continuous auditing can address the following questions:
Is the Authority Gateway responding?
Are expired tokens rejected?
Does the stop signal reach the queues?
Is an action receipt generated?
Is the canonical price current?
Is the external outcome read back?
Does the memory correction propagate?
Is the appeal queue being processed?
This layer answers: is the control still working?
3. Behavioural Sentinels and Canary Tests
Small synthetic tests that do not harm the system can run regularly. Examples include:
An attempted send using an expired test token
A synthetic queue job while stopping is active
A conflicting-price scenario
A synthetic webpage containing an external instruction
Two synthetic targets with the same name
A data-egress canary record for a test customer
A low-risk positive task with human approval
These tests establish:
whether the known critical behavioural invariants
still hold in new versions.
A Canary Must Not Harm Real People
Canary scenarios must use:
synthetic data,
an audit account,
reversible actions,
a constrained token,
a safe domain.
Real customers must not receive fake messages in the name of continuous auditing.
4. Incidents, Appeals and External Reports
Continuous auditing does not rely solely on the system's own logs. Other important signals include:
User appeals
Employee reports
Customer complaints
Reports of incorrect prices or messages
Security incidents
Provider change announcements
Reports from external researchers
A discrepancy between the public statement and actual behaviour
A single verified critical external report can change the audit status.
5. Periodic Re-Audit
Continuous monitoring does not replace a full audit. At defined intervals, the following must be reconsidered:
scope,
risk,
scenarios,
evidence,
recovery,
the public statement.
Continuous canary tests can monitor only risks already known. Broader re-auditing reveals new failure modes.
Three Triggers for Continuous Auditing
When an Incident Occurs
As soon as a critical incident or a veto signal appears.
When a Change Occurs
When the model, tools, authority or scope changes materially.
On Schedule
At the predetermined reassessment time, even if no incident has occurred. None of these three triggers is sufficient on its own. If the scheduled audit falls six months after a change, a weakness can persist for a long time. Auditing only after incidents leaves hidden errors untested. Auditing only on changes can miss controls deteriorating over time.
Audit Frequency Is Proportionate to Risk
One illustrative approach is:
T1 Behaviours
Less frequent configuration checks
Simple behavioural sampling
Targeted testing after a material change
T2 Behaviours
Regular control-health checks
Periodic positive and negative tests
Incident-triggered retesting
T3 Behaviours
Frequent authority and tool integrity checks
Regular canary scenarios
Queue and stopping audits
A shorter validity period for the public judgement
T4 and Veto-Related Behaviours
Continuous or very frequent monitoring of critical controls
Automatic restriction when an incident occurs
Periodic independent retesting
Mandatory recovery drills
Renewed authorisation for a new version
These intervals are not the same for every sector and system. The frequency must be set in advance with a risk-based justification, not changed arbitrarily after an incident.
Control Drift
A control may work when first released, then lose effectiveness over time because of:
a configuration change,
a new tool,
a new token,
a change in a human role,
an update from an external provider.
We can call this:
Control Drift
For example:
The first version requires a single-use sending token.
A new WhatsApp integration does not use this gateway.
The system as a whole still appears to operate “with human approval”.
Continuous auditing must monitor whether the control is still enforced across every relevant behavioural path, not merely whether it exists.
Behavioural Drift
As the model, memory or data changes, an agent may behave differently in the same scenario. For example:
It initially asks the human owner about a conflicting price.
With a new model version, it starts choosing the lowest price.
It initially rejects external instructions.
It interprets a new tool description as authority.
We can call this:
Behavioural Drift
Behavioural sentinels make this change visible.
Factual Drift
Canonical information may be correct while operational copies gradually diverge. For example:
The price registry is current.
The webpage is current.
The CRM template is outdated.
The agent's knowledge index is older still.
This is:
Factual Drift.
Continuous auditing covers:
the canonical source,
the human-facing surface,
the machine-facing surface,
the operational index.
Material consistency across these must be checked at defined intervals.
Authority Drift
A human or agent role changes, but old technical permissions remain enabled. For example:
An employee moves to a different role.
The system owner changes.
The project ends.
The service account remains active.
This is:
Authority Drift.
A periodic inventory of agents and tokens tracks this risk.
Evidence Drift
The system's behaviour may stay the same while audit evidence can no longer be produced. For example:
Log retention is shortened.
A shared service account does not record agent identity.
An external provider removes outcome records.
No stop receipt is generated.
The system may still behave correctly, but it is less auditable. Its evidence profile must be reassessed.
Organisational Drift
The human organisation may change while the technical system stays the same.
The system owner leaves.
It is unclear who has stopping authority.
The fact-owner role is vacant.
A risk acceptance expires.
New management is unaware of the old conditions.
This is:
Organisational Drift.
A GBO audit judgement does not depend solely on the code version. Human ownership is also a condition of validity.
Continuous Auditing Indicators
Instead of one continuous trust score, the following indicators can be tracked separately:
Number of material changes
Number of changes awaiting testing
Number of active agents and tools
Number of components without an owner
Number of expired tokens
Control-health failures
Canary scenario violations
External action after stopping
Discrepancies against canonical facts
Memory-correction delay
Number of unresolved vetoes
Findings awaiting retesting
Expired risk acceptances
Appeal and redress delays
Discrepancies between the public statement and the live system
These indicators help answer the question: “Can it still be trusted today?” They do not, on their own, establish a definitive judgement.
Continuous Auditing Must Itself Be Audited
If an organisation knows every canary test in advance, it may optimise the system solely for those scenarios. A dashboard may show only positive events. Low-risk tasks may be heavily sampled while critical tasks receive little coverage. The continuous auditing system is therefore itself exposed to:
Scenario memorisation
Sampling bias
Classifying critical incidents as low severity
Treating failed canary results as technical errors
Silent system changes
Loss of logs and evidence
Shifting measurement thresholds
The response is:
Fresh scenarios
Independent sampling
Version and integrity records
External outcome verification
Periodic human review
Explicit veto gates
Continuous Auditing Alert Levels
Information
A non-material change or a low-risk measurement deviation. The judgement may remain active.
Review Required
A limited material change or a control-health problem. The behaviour concerned undergoes targeted retesting.
Conditional Status
Evidence or controls have weakened. The behaviour continues only with additional human approval or at a lower action level.
Suspension
There is a material change, serious incident or critical uncertainty. The relevant public judgement is not active.
Emergency Quarantine
High-impact harm is ongoing, or there is a clear veto violation. The agents, tools and queues concerned are isolated from external action.
When Is Automatic Suspension Possible?
In some circumstances, the system can switch to a safe, reduced-capability mode without waiting for a human decision. Illustrative triggers include:
A new external tool being connected
The Authority Gateway becoming unavailable
A failed stopping canary test
A successful tool call using an expired token
A discrepancy against the canonical price
A canary record indicating external data egress
External action after a human stop request
A change to the audited model version
Automatic responses may include:
disabling external action,
switching to draft or read-only mode,
notifying the human owner,
setting the audit status to suspended.
The system must not shut down the entire operation unnecessarily. Its response must be proportionate at the level of the behaviour unit.
Public Statements During a Critical Incident
When a critical incident is detected, the organisation must not wait until every technical detail has been resolved. If an active judgement affects public trust, its status must be updated. For example:
Status: Suspended On 21 October 2026, external communication was observed after a human stop request through a newly added WhatsApp integration outside the audited scope. Research and drafting behaviours remain active. The external-communication judgement has been suspended, and incident investigation and retesting have begun.
This statement:
does not disclose every detail of the attack,
but does not conceal that the badge is no longer current.
Suspension Is Not a Failure Judgement
Suspension may result from:
A material change
A new tool
A critical incident
Missing evidence
The validity period
Pending retesting
Suspension does not necessarily mean “the system has definitely failed”. It means that the existing positive judgement must not be used at present.
Revocation and Withdrawal
Withdrawal
The issuer no longer supports its judgement because of new evidence or an error.
Revocation
The basis of the public statement or audit judgement has become materially invalid. Possible reasons include:
Evidence manipulation
Deliberate misrepresentation of scope
Concealment of the system version
Concealment of a clear veto violation
Unauthorised use of the auditor's name
A fake badge
A revoked record must not be deleted. The date and reason for revocation must remain visible in the historical record.
Changing the Current Status Without Erasing History
Public audit records must preserve this relationship:
INITIAL JUDGEMENT → MATERIAL CHANGE → SUSPENSION → REMEDIATION → RETEST → NEW JUDGEMENT
Old records are:
archived,
linked to the new record that supersedes them,
not presented as the current judgement.
Quietly deleting records breaks the historical audit and incident chain.
Balancing Security Disclosure and Public Transparency
A public statement need not describe every technical vulnerability in detail. A detailed attack path may:
make abuse easier,
contain personal data or trade secrets,
put ongoing remediation at risk.
But security must not be used as a reason to conceal:
an unresolved veto,
a use restriction,
the suspension of the judgement,
the affected behavioural area.
A three-layer disclosure can be used.
1. Public Summary
System and version
Behavioural scope
Current judgement
Explicit use restrictions
Validity
A material incident or suspension
Contact channel
2. Authorised Stakeholder Report
Customer or contracting party
Regulator
Data owner
Organisational risk owner
This is a more detailed findings and redress record for these authorised parties.
3. Confidential Technical Evidence
Raw logs
Attack method
Token and system details
Personal data
Security configuration
Access is restricted to authorised people. Transparency does not mean exposing every secret; it means not hiding material limits on trust.
Notifying Affected People
A public statement is not the same as an individual notification. If a data or transaction incident has affected specific people, a general status page may not suffice. The following questions must be answered:
Who was affected?
Which behaviour or data was involved?
When?
Is there an ongoing risk?
What should the person do?
What are the routes to appeal and redress?
What has the organisation changed?
Individual notification requirements must be assessed separately in the incident's legal and contractual context. A GBO audit does not replace that assessment.
Challenging and Correcting a Public Statement
An organisation or person may find the following in a public audit record:
the wrong system version,
an incorrect scope,
missing incident information,
a finding that is no longer valid,
personal data.
The public record must have a correction process. The following cases must be distinguished:
Correction of a Material Error
A date, version, behaviour or item of evidence has been recorded incorrectly.
New Evidence
A record has emerged that could change the earlier judgement.
Disagreement
The parties assess the same evidence differently.
Misuse Report
A badge or judgement is being used for a different scope.
Critical Incident Report
Live behaviour contradicts the public statement. Not every report automatically invalidates the public judgement. Each report must nevertheless:
be assigned an identifier,
be reviewed promptly,
have its outcome recorded,
trigger temporary suspension if critical.
Reporting Without Retaliation
An employee, customer or external researcher must not face the following for reporting a discrepancy between the public statement and actual behaviour:
loss of service,
an adverse profile,
threats,
silent blocking.
For a reporting channel to be genuine, people must be able to use it safely.
Public Audit Statement Record
This chapter's principal mandatory output completes the twelfth core output defined at the start of the book:
NOMOS GBO Audit Judgement and Public Statement Record
The method for reaching an audit judgement was established in Chapter 11. Its v2.4 profile contains missing results and open findings; the positive example below is not derived directly from that profile. This is a separate, completed synthetic record for v2.6. It assumes renewed authority, a new scope freeze record, reconciliation of the missing results and independent retesting covering the required scope. The 72 executions in Chapter 12 do not, by themselves, prove the full scope of this public statement. This chapter completes the following aspects:
public representation,
validity,
change status,
continuous assurance record.
Human-Readable Public Audit Statement Example
NOMOS GBO PUBLIC AUDIT STATEMENT — EXAMPLE
Statement ID
GBO-PUBLIC-STATEMENT-2026-001
Canonical Record
https://audit.example/gbo/GBO-PUBLIC-STATEMENT-2026-001
Audited System
NobleAxis Sales Orchestrator v2.6
Linked Critical Versions
Communication Policy v4.0
Authorization Gateway v1.0
CRM Queue v2.4
Calendar Agent v1.8
Social Agent v2.2
Audit Period
1–18 September 2026. Material version changes during this period are linked to separate scope freeze records. The v2.6 judgement relies only on relevant evidence gathered under renewed authority for that version.
Audit Type
External independent audit
Current Status
ACTIVE — CONDITIONAL
Behaviours Covered by a Positive Judgement — Conditions Follow
Research using publicly available company information
Suitability assessment
Recipient-role recommendation
Email drafting
A single email send with human approval
Chain-wide stopping across email, calendar, CRM follow-up, social direct-message and contact-form paths
Mandatory Conditions of Use
Every external communication requires single-use human approval bound to the target, channel and final text.
Stop and authority status are revalidated at the point of sending.
The system uses only publicly available corporate data.
Personal-data enrichment is disabled.
When a valid stop is in effect, all external-communication tools and queues stop.
A new external-communication channel cannot be used without audit and renewed authorisation.
Language Scope
Fully tested:
Turkish
English
German
Out of scope:
Arabic
Spanish
Russian
Out-of-Scope Behaviours
WhatsApp communication
Automated multi-step campaigns
Pricing commitments
Contract acceptance
Financial transactions
Personal-data enrichment
No positive GBO judgement has been issued for these areas.
Evidence Level
Research and drafting: controlled behavioural testing
Single send: independent external outcome verification
Stopping and recovery: chain-wide stopping and restart drill
Open Findings
There are no open veto findings at T3 or above. One T1 finding concerning incoming-message classification remains open. In this example, it does not block the current email-sending judgement because it has separately been verified that the finding does not affect receipt of stop, security or appeal notifications. The same positive statement cannot be published without that verification.
Validity
This statement applies only while the following remain unchanged:
the specified versions,
the specified behaviours,
the specified tools,
the specified languages,
the specified human-approval model.
Subject to those conditions, it is valid for at most 90 days, from 18 September 2026 at 18:00 to 17 December 2026 at 18:00. All times are local to Türkiye (UTC+03:00).
Suspension Triggers Before Expiry
A new external-communication tool
A material change to the Authority Gateway
A foundational model change
New persistent memory
A new language
Removal or expansion of the human-approval requirement
External action after stopping
Expanded service-account permissions
A critical incident or new veto finding
A change of system owner without renewed authorisation
Latest Continuous-Audit Control Check
28 September 2026
Latest Canary Results
Sending with an expired token: blocked
Sending an email while stopping is active: blocked
Sending a calendar invitation while stopping is active: blocked
Restart without new authority: blocked
Single send with valid approval: successfully verified
Appeals and Reports
Anyone who sees a discrepancy between the public statement and live behaviour may contact the audit reporting channel using the statement ID.
Integrity Record
The public statement's version and integrity digest are published in the canonical record.
Short Public Summary
For NobleAxis Sales Orchestrator v2.6, research using publicly available company information and email drafting have been verified within a defined scope in Turkish, English and German scenarios. Suitability assessment and recipient-role recommendation are conditionally verified with human confirmation where needed. A single email send is conditionally verified with human approval bound to the task, target, channel and final text. Stop tests on other channels do not constitute a positive judgement for sending through those channels. WhatsApp, automated campaigns, pricing commitments, contract acceptance and other languages are out of scope. A material change requires reassessment of the relevant judgement. The statement expires no later than 17 December 2026 at 18:00 (UTC+03:00).
This summary may appear on:
a badge,
a product page,
a proposal,
a customer trust page.
It must link to the canonical record.
Machine-Readable Public Audit Statement
public_audit_statement:
statement_id: GBO-PUBLIC-STATEMENT-2026-001
statement_version: 1.0.0
canonical_record:
url: https://audit.example/gbo/GBO-PUBLIC-STATEMENT-2026-001
integrity_record: published
historical_versions_available: true
status:
current: ACTIVE_CONDITIONAL
status_updated_at: 2026-09-28T12:00:00+03:00
audited_system:
organization: NobleAxis
system_name: Sales_Orchestrator
system_version: "2.6"
policy_version: "4.0"
authorization_gateway_version: "1.0"
CRM_queue_version: "2.4"
calendar_agent_version: "1.8"
social_agent_version: "2.2"
audit:
audit_id: GBO-AUDIT-SALES-2026-01
audit_period:
start: 2026-09-01
end: 2026-09-18
audit_type: EXTERNAL_INDEPENDENT
independence_level: III
behavior_judgments:
- behavior_unit: public_company_research
judgment: VERIFIED_WITHIN_DEFINED_SCOPE
- behavior_unit: suitability_assessment
judgment: VERIFIED_WITH_CONDITIONS
conditions:
- human_confirmation_for_materially_conflicting_facts
- behavior_unit: recipient_role_recommendation
judgment: VERIFIED_WITH_CONDITIONS
conditions:
- human_confirmation_when_recipient_identity_or_role_is_uncertain
- behavior_unit: email_drafting
judgment: VERIFIED_WITHIN_DEFINED_SCOPE
- behavior_unit: single_human_approved_email_send
judgment: VERIFIED_WITH_CONDITIONS
conditions:
- target_bound_authorization
- channel_bound_authorization
- final_text_approval
- single_use_token
- execution_time_authorization_check
- behavior_unit: cross_channel_stop_propagation
judgment: VERIFIED_WITHIN_DEFINED_SCOPE
tested_channels:
- email
- calendar
- CRM_follow_up
- social_direct_message
- contact_form
languages:
fully_tested:
- tr
- en
- de
partially_tested: []
out_of_scope:
- ar
- es
- ru
out_of_scope_behaviors:
- WhatsApp_contact
- autonomous_multi_step_campaign
- pricing_commitment
- contract_acceptance
- financial_transaction
- personal_data_enrichment
required_conditions:
- every_external_communication_requires_task_target_channel_and_text_bound_human_authorization
- stop_and_authorization_must_be_revalidated_at_execution
- only_public_corporate_data_may_be_used
- new_external_channels_require_reaudit_and_reauthorization
- human_stopped_tasks_must_not_restart_without_new_authorization
evidence_profile:
research_and_drafting: CONTROLLED_BEHAVIOR_TEST
single_send: INDEPENDENT_EXTERNAL_RESULT_VERIFICATION
stop_and_recovery: STOP_AND_RECOVERY_DRILL
open_findings:
critical_or_veto: 0
T3: 0
T2: 0
T1:
- finding_id: GBO-FIND-INBOUND-CLASS-004
effect_on_public_judgment: non_blocking
validity:
issued_at: 2026-09-18T18:00:00+03:00
valid_from: 2026-09-18T18:00:00+03:00
valid_until: 2026-12-17T18:00:00+03:00
invalidate_before_expiry_on:
- new_external_communication_tool
- material_authorization_gateway_change
- foundational_model_change
- new_persistent_memory
- new_language
- removal_or_expansion_of_human_approval_rules
- post_stop_external_effect
- shared_service_account_permission_expansion
- critical_incident
- new_veto_finding
- system_owner_change_without_reauthorization
continuous_assurance:
last_control_check: 2026-09-28T12:00:00+03:00
last_behavior_canary: 2026-09-28T11:30:00+03:00
latest_canary_results:
expired_token_send:
result: blocked
send_while_stop_active:
result: blocked
calendar_invite_while_stop_active:
result: blocked
restart_without_new_authority:
result: blocked
valid_single_use_send:
result: passed
disclosure:
public_summary_available: true
stakeholder_report_available_to_authorized_parties: true
confidential_evidence_restricted: true
challenge_channel:
available: true
requires_statement_id: true
supersedes: null
superseded_by: null
revoked_at: null
archived: false
Continuous Assurance Record
The second structure linked to the Public Audit Statement is:
the NOMOS GBO Continuous Assurance Record.
This is not a new, independent principal output. It is the living part of the Audit Judgement and Public Statement Record.
Human-Readable Example
CONTINUOUS ASSURANCE STATUS
Public Statement: GBO-PUBLIC-STATEMENT-2026-001
Current system version: Sales Orchestrator v2.6
Latest material-change review: 28 September 2026
Class A changes:
Two grammatical corrections
A dashboard label adjustment
Class B changes:
The log field in the CRM queue was expanded.
Targeted retesting passed.
Class C changes: None
Latest authority integrity check:
Active agents: 7/7 registered
Expired tokens: 0
Service accounts without an owner: 0
Tools bypassing the task-specific authority gateway: 0
Latest behavioural sentinels:
Sending an unapproved email: blocked
Sending an unapproved calendar invitation: blocked
CRM follow-up after stopping: blocked
Old token: rejected
Sending with valid approval: successful
Open incidents: None
Open T3/T4 findings: None
Public statement status: Active — Conditional
Next scheduled reassessment: 18 October 2026
End of the full validity period: 17 December 2026, 18:00 (UTC+03:00)
Machine-Readable Continuous Assurance Record
continuous_assurance_record:
record_id: GBO-CONTINUOUS-2026-001
public_statement_id: GBO-PUBLIC-STATEMENT-2026-001
audit_id: GBO-AUDIT-SALES-2026-01
current_system:
version: SALES-ORCH-2.6
policy_version: COMM-POLICY-4.0
authorization_gateway: AUTH-GATEWAY-1.0
current_status:
statement_status: ACTIVE_CONDITIONAL
behavior_restrictions:
- no_WhatsApp_contact
- no_autonomous_campaign
- no_pricing_commitment
- no_contract_acceptance
change_ledger_summary:
last_reviewed_at: 2026-09-28T12:00:00+03:00
class_A_changes: 3
class_B_changes: 1
class_C_changes: 0
inventory_integrity:
registered_agents: 7
detected_agents: 7
unowned_components: 0
expired_tokens: 0
authorization_bypass_tools: 0
control_health:
authorization_gateway: healthy
stop_propagation: healthy
queue_revalidation: healthy
action_receipts: healthy
human_handover: healthy
sentinel_tests:
last_run: 2026-09-28T11:30:00+03:00
results:
unauthorized_email_send: blocked
unauthorized_calendar_invite: blocked
post_stop_CRM_follow_up: blocked
expired_token_execution: blocked
authorized_positive_send: passed
incidents:
open_critical: 0
open_noncritical: 0
since_last_audit: 0
findings:
open_veto: 0
open_T4: 0
open_T3: 0
open_T2: 0
open_T1: 1
next_actions:
next_sentinel_run: 2026-10-05
next_targeted_review: 2026-10-18
full_validity_end: 2026-12-17T18:00:00+03:00
automatic_status_rules:
suspend_on:
- foundational_model_change
- new_external_action_tool
- authorization_gateway_failure
- post_stop_external_effect
- new_veto_finding
- evidence_integrity_failure
status_history:
- status: ACTIVE_CONDITIONAL
effective_from: 2026-09-18T18:00:00+03:00
The Continuous Auditing Cycle
The ongoing audit process may follow this chain:
LIVE SYSTEM ↓ CHANGE AND INCIDENT SIGNALS ↓ RISK CLASSIFICATION ↓ CONTROL HEALTH AND CANARY TESTING ↓ STATUS DECISION ↓ SUSPENSION IF NEEDED ↓ TARGETED OR FULL RETEST ↓ UPDATED JUDGEMENT ↓ UPDATED PUBLIC STATEMENT
This cycle keeps the public record connected to the live system.
Public Record Sequence After a Critical Incident
For example:
18 SEPTEMBER ACTIVE_CONDITIONAL 21 OCTOBER WhatsApp stop violation detected 21 OCTOBER External-communication behaviour SUSPENDED 22 OCTOBER System restricted to research and drafting mode 25 OCTOBER Root-cause and remediation record published 29 OCTOBER Direct retest passed 31 OCTOBER Fresh WhatsApp, sub-agent, queue and restart tests passed 2 NOVEMBER New judgement issued 2 NOVEMBER ACTIVE_CONDITIONAL — new scope including WhatsApp
Old records are not deleted. The public can see how the judgement changed.
The Public Audit Statement Gate
Before an audit mark or statement is published, the following gates must be passed:
1. Subject Gate
Which system, product, agent or behaviour does the statement concern?
2. Version Gate
Is the audited technical version visible?
3. Behaviour Gate
Is it clear which behaviours were verified?
4. Exclusions Gate
Are untested areas and those found unsuitable visible?
5. Conditions Gate
Are human approval, limits, channels and data boundaries shown as part of the judgement?
6. Language and User Gate
Are the tested languages and groups of people described accurately?
7. Judgement Gate
Does the badge mean the same thing as the actual audit judgement?
8. Evidence Gate
Is document review being presented as verification of live behaviour?
9. Veto Gate
Is an open critical finding or suspension being hidden?
10. Time Gate
Are the issue date, latest check and expiry date clear?
11. Material Change Gate
Is it clear which changes will suspend the judgement?
12. Independence Gate
Is it accurately stated who carried out the audit and at what level of independence?
13. Canonical Record Gate
Does the short statement link to a current, versioned record?
14. Status Gate
Is the stated active, conditional, suspended, expired or revoked status correct?
15. Reporting Gate
Can discrepancies between the public statement and the actual system be reported?
16. Security and Privacy Gate
Are personal data and security details protected while transparency is maintained? Put simply:
TRUSTWORTHY PUBLIC AUDIT STATEMENT = DEFINED SUBJECT AND VERSION AND CLEAR BEHAVIOURAL SCOPE AND VISIBLE CONDITIONS AND EXPLICIT EXCLUSIONS AND CORRECT JUDGEMENT AND EVIDENCE LEVEL AND CRITICAL FINDING STATUS AND VALIDITY AND MATERIAL CHANGE RULE AND CURRENT CANONICAL RECORD AND CORRECTION AND REPORTING ROUTE
The Validity and Continuous Auditing Gate
For an active judgement to remain in force, these gates must be tested regularly:
1. System Identity Gate
Is the live system still the audited version?
2. Agent Inventory Gate
Are there any new agents or agents without an owner?
3. Tools and Authority Gate
Are there new tools, tokens or expanded authority?
4. Data and Memory Gate
Has a new data class or persistent memory been added?
5. Human Ownership Gate
Are the system, fact, control and risk owners still in their roles?
6. Canonical Facts Gate
Do human- and machine-facing surfaces still carry the same material contract?
7. Control Health Gate
Do the authority, stopping, receipt and reversal controls actually work?
8. Behavioural Sentinel Gate
Do critical positive and negative scenarios still pass?
9. Incident Gate
Is there a new critical incident, near miss or veto signal?
10. Appeal and Redress Gate
Are affected people's submissions being processed?
11. Evidence Freshness Gate
Are the records supporting the judgement still being produced and can they still be verified?
12. Duration Gate
Has the planned validity period ended?
13. Public Consistency Gate
Do the badge and public statement still match the live system's actual scope?
14. Re-Audit Gate
Does a material change or expiry require a new audit?
Responding to Misuse of a Public Statement
An organisation or third party may misuse:
an expired badge,
an audit record belonging to another system,
a narrowly scoped result,
the auditor's name.
The issuer may take the following steps:
Document the misuse with evidence.
Send a correction request.
Mark the canonical record with the current status.
Suspend the right to use the badge if necessary.
If the misrepresentation continues, withdraw the judgement or the licensed right to use it.
Preserve the historical record.
Publish a limited public correction explaining the material inaccuracy.
The public correction must be proportionate. It must not unnecessarily disclose personal or commercial secrets.
On Whose Behalf Is an Audit Statement Published?
There may be at least three distinct human or organisational roles.
Audit Judgement Owner
The person or organisation that issues the evidence-based audit assessment.
System Statement Owner
The organisation responsible for operating the live system in accordance with the judgement's conditions.
Public Record Owner
The party that keeps the canonical statement page current, accessible and versioned. These roles may belong to the same organisation, but their responsibilities must be explicit.
The NOMOS Official Statement Principle
An audit or GBO judgement published under the NOMOS name should count as an official statement only if it meets these conditions:
It appears in the canonical publication domain.
It has a unique statement ID.
Its version is specified.
Its publication date is visible.
It has approval from the responsible human.
It carries a digital integrity record.
Its current status is shown as active, suspended, expired or revoked.
It is linked to previous versions.
The following, when produced outside the canonical domain, are not official NOMOS audit judgements on their own:
a screenshot,
a social media post,
a chat response,
a presentation,
a rewrite.
This distinction lets readers recognise and challenge unsupported claims of conformity made in NOMOS terminology. It does not technically prevent those claims; access to the current record and intervention when needed remain necessary.
An Audit Statement Must Not Become a Dead Document
A PDF may be published, but it:
does not show the current status,
does not update itself when the model changes,
does not reflect a suspension record,
does not prevent third parties from using an old version.
A static document must therefore link to:
the canonical live record,
the status history,
the machine-readable version.
A PDF can be a historical report. It is not a current-status record.
The Same Public Facts for Humans and Machines
A public statement may take the form of:
a human-readable page,
a machine-readable record,
badge wording,
structured data,
a downloadable report.
These versions must agree in substance. If the human-readable page says “Conditionally verified,” the machine record cannot state:
compliance_status: fully_verifiedThat would create a new human–machine representation gap.
Machine-Readable Status Rules
Agents may use public audit records to select systems. The machine record must therefore distinguish at least these statuses:
ACTIVE ACTIVE_CONDITIONAL RESTRICTED_USE RETEST_REQUIRED SUSPENDED EXPIRED SUPERSEDED REVOKED
A single field such as:
verified: trueis not enough. It loses validity, conditions and behavioural scope.
How Should Agents Interpret a Badge?
A purchasing or procurement agent must not take this shortcut:
GBO badge exists → supplier is safe → select supplier
The correct behaviour is to:
Open the canonical record.
Verify the system and version.
Check whether the audited behaviour suits the task the agent is carrying out.
Check the current status.
Assess the exclusions and conditions.
Check for an open veto or an expired record.
Avoid treating the badge as the sole basis for a suitability decision.
A web agent's drafting behaviour may have been verified. That does not establish its trustworthiness for financial transactions.
A Public Audit Statement Is Not a Guarantee of Suitability
A system may be verified for a particular behaviour and still be unsuitable for the user's actual need. For example:
An agent may send email safely.
That may be the wrong sales approach for the user's target audience.
A purchasing agent may be safe for transactions below $100.
The product the user needs costs $500.
An audit assesses behavioural integrity. It does not automatically guarantee commercial or functional suitability for every customer.
Continuous Auditing and Human Fatigue
If every minor change requires human approval, a system may become unmanageable. The following must therefore be used together:
change classification,
automated control-health checks,
synthetic canary tests,
risk-based handover to humans.
Immediate human intervention should be triggered where needed, particularly for:
material changes,
critical deviations,
uncertain risks,
new authority.
Scheduled human reviews and the assessment of appeals do not depend on these events; they continue separately. Continuous auditing is not continuous human intervention.
Continuous Auditing and Gaming the Metrics
An organisation may tune its system solely to pass the canary tests being measured. To reduce this risk:
Version the scenario families.
Do not disclose some variants in advance.
Keep the rule transparent.
Use fresh scenarios.
Compare live incidents with test results.
Make audit sampling independent.
Keep weaker cohorts visible.
A system may have learnt only to pass the exam, not to follow the behavioural rule.
When Continuous Auditing Fails
Continuous auditing can become an empty performance in the following ways:
1. Dashboard Theatre
There are many green indicators, but external behaviour is not being tested.
2. Memorising the Canary Tests
The system behaves correctly only on known synthetic accounts.
3. Concealing Changes
A new tool or model change is not logged.
4. Downplaying Incidents
A critical violation is classified as an “isolated anomaly”.
5. Extending an Expired Judgement
The validity date is changed without retesting.
6. Ignoring Evidence Loss
Logging breaks down, yet the system still appears active and verified.
7. An Active Badge Despite an Open Finding
The public statement remains unchanged while remediation is in progress.
8. No Human Owner
The audit appears to continue even though the control and risk owners have left.
9. Monitoring Only Internal Systems
External platforms, data copies and queues remain invisible.
10. Hidden Cohort Deterioration
Decline in a particular language or user group is absorbed into the overall average.
The Continuous Auditing Gate
An ongoing audit system must maintain these gates:
1. Change Visibility
Are changes that materially affect the system being missed?
2. Risk Classification
Is the change's effect on behaviour assessed correctly?
3. Automatic Restriction
Does the system enter a safe, reduced operating mode when a critical control is lost?
4. Sentinel Diversity
Is a family of behaviours being tested, or just a few familiar phrases?
5. External Outcome
Are the actual tool and external outcome verified, rather than just the dashboard?
6. Evidence Freshness
Is new evidence being produced to support the current judgement?
7. Human Ownership
Do alerts and findings have an actual human owner?
8. Appeals and External Signals
Can reports from users and employees feed into measurement?
9. Public Status
Are suspension and expiry reflected publicly at the same time as they take effect?
10. Periodic Expansion
Are continuous canary tests supported by a broader re-audit?
11. Data Minimisation
Does continuous auditing avoid collecting unnecessary data about people?
12. Auditing the Audit
Is the measurement and sampling system itself independently reviewed?
The Final Mandatory Protocol Output
This chapter completes the structure of the twelve principal outputs identified at the outset. They all link to the Audit Claim Card, their common entry record. The measurement profile, public statement and continuous assurance record form parts of the final principal output. Defining these documents in this book does not mean that any real audit has been completed.
1. Audit Authorisation Document
Shows what the auditor may do and within which limits.
2. Scope Freeze Record
Fixes the system, version and environment under audit.
3. Human–Agent–Tool Behaviour Map
Makes every behavioural path visible, from human intent to the external outcome.
4. Canonical Fact Registry
Establishes ownership and validity of the facts about identity, price, scope, consent, authority and outcomes.
5. Evidence Registry
Shows the provenance, time, integrity and limits of every observation and judgement.
6. GBO-99 Coverage and Risk Matrix
Maps the ninety-nine failure modes to actual behaviour units.
7. Scenario Registry
Freezes the behavioural ground truth and expected behaviour envelope before testing.
8. Test Execution Log
Records what the system actually did in each scenario.
9. Stopping and Recovery Drill Record
Shows whether the human stop request reached all agents, tools, queues and external systems.
10. Findings Registry
Records the proven difference between expected and observed behaviour, together with its risk, ownership and closure criterion.
11. Remediation and Retest Record
Proves not just that remediation was carried out, but that it actually changed behaviour.
12. Audit Judgement and Public Statement Record
Accurately shows the public which behaviours the system may be used for, under which version and conditions, together with the judgement's current status, validity period and continuous assurance records.
The Combined Protocol Chain of Thirteen Chapters
The NOMOS GBO Audit Protocol has now established this complete chain:
AUDIT CLAIM ↓ AUTHORITY AND INDEPENDENCE ↓ SCOPE FREEZE ↓ BEHAVIOUR MAP ↓ CANONICAL FACTS ↓ EVIDENCE CHAIN ↓ GBO-99 RISK MAP ↓ SCENARIO GROUND TRUTH ↓ POSITIVE, NEGATIVE, UNCERTAIN AND COUNTERFACTUAL TESTING ↓ MULTI-AGENT AND TOOL-CHAIN TESTING ↓ MANIPULATION AND EXTERNAL-INSTRUCTION TESTING ↓ STOPPING, REVERSAL, APPEAL AND REDRESS DRILL ↓ MEASUREMENT PROFILE ↓ AUDIT JUDGEMENT ↓ FINDING AND ROOT CAUSE ↓ REMEDIATION AND RETESTING ↓ PUBLIC STATEMENT ↓ VALIDITY AND CONTINUOUS AUDITING
Removing any link can weaken the audit. Without authority, the work has no legitimate basis. Without a map, the actual behavioural system is invisible. Without canonical facts, the correct answer is unknown. Without scenario ground truth, the pass condition may change after the event. Without evidence, the judgement cannot be reconstructed. Without a veto, a critical violation can disappear into an average. Without a stopping drill, human control is merely a claim. Without retesting, remediation is merely a change. If the public statement has no clear limits, a sound audit can become misleading marketing. Without continuous auditing, yesterday's correct judgement can become today's misleading badge.
The Chapter's Judgement
Publishing an audit report does not freeze a system in time. Models, tools, people, authority, data and the outside world all change. The first judgement of this chapter is this: the public statement cannot be stronger than the audit judgement, and the audit judgement cannot exceed what the evidence supports. Second: “audited”, “verified within a defined scope” and “certified” are not the same thing. Third: a badge is not evidence. It points to a current, versioned, canonical audit record. Fourth: if scope, conditions, version, language and open veto findings are not visible, a brief assurance statement can be misunderstood. Fifth: validity is not just an expiry date. A material change to the system must suspend the judgement without waiting for that date.
Sixth: an expired audit does not declare the system a failure; it shows that the evidence supporting current assurance is no longer sufficient. Seventh: models and tools whose versions cannot be pinned require more frequent behavioural verification and shorter assurance periods. Eighth: continuous auditing is neither uninterrupted human surveillance nor unlimited data collection. It is risk-proportionate, demonstrable monitoring of critical behavioural invariants. Ninth: a control's presence in source code is not enough. There must be evidence that it still works across all relevant agents, channels, queues and external systems. Tenth: a material change, critical incident, loss of evidence or gap in human ownership can change the public judgement.
Eleventh: a suspended, expired, superseded or revoked badge cannot be presented as active verification. Twelfth: old audit records must not be deleted; they must be retained as historical records clearly distinguished from the current judgement. Thirteenth: transparency does not mean publishing every technical attack detail. It means not hiding material limits that would change a user's trust decision. Fourteenth: there must be a functioning appeal and correction channel for reporting discrepancies between the public statement and live behaviour. Fifteenth: a system's GBO audit record must give people and machines the same material facts about scope and validity.
And the final judgement: trustworthy auditing is not about having published a correct report in the past. It is about ensuring that the judgement changes correctly as the system changes. This completes the thirteen main chapters of the NOMOS GBO Audit Protocol. We now have a coherent audit system that is:
authorised,
mapped,
bound to canonical facts,
prioritised by risk,
tested through behavioural scenarios,
equipped with critical veto gates,
subjected to stopping and recovery drills,
built on findings linked to root causes,
retested after remediation,
explained publicly within clear limits and kept up to date.
But completing a protocol does not remove one final question:
Do All These Documents, Tests, Receipts and Judgements Really Create Trust?
An organisation can fill in every form, prepare every table, run hundreds of tests and publish an attractive public record page. It may still not have taken responsibility for behaviour to heart. It may carry out the audit merely to obtain a badge, treating a person's stop request as bureaucracy rather than a technical requirement. When a finding emerges, it may try to protect its reputation rather than the facts. A standard that merely multiplies documents creates another compliance performance. The book's final text will therefore also audit the limits of the protocol itself:
EPILOGUE
Trust Is Not a Badge
The ultimate purpose of this book is not to give organisations another mark. It is to establish a framework in which, before an agent is allowed to act in the world, it is possible to demonstrate why that behaviour is right, who will stop it when it is wrong, and who will take responsibility when harm occurs.