This appendix helps readers locate the protocol’s documents and distinguish closely related terms. Its short definitions do not replace the scope and conditions in the relevant chapter. Names specific to NOMOS belong to the framework proposed in this book.
Shared entry record and twelve principal outputs
The Audit Claim Card is the shared entry record for the entire file. Every document is linked to its claim, scope and audit identity. The principal outputs below may contain subsidiary records; adding those records does not change the number of principal outputs.
Scroll sideways to see all columns.
| No. | Principal output | Main function | Chapter |
|---|---|---|---|
| 1 | Audit Authorisation Document | Identifies who authorised the audit, with what access and within which boundaries. | 2 |
| 2 | Scope Freeze Record | Fixes the boundaries of the system, version, tools, authority, languages and period under review. | 2 |
| 3 | Human–Agent–Tool Behaviour Map | Traces tasks, authority and action paths from people through to external tools. | 3 |
| 4 | Canonical Fact Registry | Records the source, owner, scope and period under which each substantive claim is valid. | 4 |
| 5 | Evidence Registry | Preserves evidence provenance, acquisition, transformation, integrity and limitations. | 4 |
| 6 | GBO-99 Coverage and Risk Matrix | Shows the applicability of error records, risk priorities and their relationship to vetoes. | 5 |
| 7 | Scenario Registry | Defines expected behaviour, conditions, variants and pass/fail criteria before testing. | 6 and 7 |
| 8 | Test Execution Log | Records each execution of a scenario and its outcome under a distinct identity. | 6–9 |
| 9 | Stopping and Recovery Drill Record | Documents stop propagation, external outcomes, reversal and human control handover separately. | 10 |
| 10 | Findings Registry | Tracks observations, evidence, root causes, effects, responsibility and closure status. | 12 |
| 11 | Remediation and Retest Record | Brings together the control change, new version, fresh tests, regression checks and closure evidence. | 12 |
| 12 | Audit Judgement and Public Statement | The outcome package linking the measurement profile to a bounded judgement, public disclosure and continuous assurance record. | 11 and 13 |
Concise glossary
Agent dark pattern
A design or behavioural pattern that steers an agent’s choice or a user’s decision against their purpose. Commercial preference, source provenance and the presentation of options are examined separately. Chapter: 9.
Uncertainty test
A scenario in which the information, identity or authority needed for correct behaviour is missing or contradictory. Success means seeking clarification, waiting or referring for human review under the defined rule, rather than guessing to fill the gap. Chapter: 7.
Finding
A record of a significant difference between the expected and observed state, together with evidence, scope and impact. A finding is not the same as a recommendation or a general concern. Chapter: 12.
Behaviour Unit
A function that can be tested separately within defined boundaries of purpose, authority, action and outcome. A system judgement need not assign the same label to every unit. Chapters: 1 and 3.
Behavioural Ground Truth
The expected behaviour established in advance for a scenario, given the available canonical records, valid authority and human purpose. An agent’s own explanation cannot replace this reference. Chapter: 6.
Audit
An examination of the relationship between a claim and the configuration, technical capability, observed behaviour and external outcome. A valid audit may reach a negative conclusion or find insufficient evidence. Chapter: 1.
Audit judgement
A bounded conclusion for the behaviour, version, language, conditions and period supported by the evidence. Completion of an audit does not imply a positive judgement. Chapter: 11.
Audit Claim Card
The shared entry record defining what the audit seeks to prove and what it excludes. It replaces neither the Audit Authorisation Document nor the final judgement. Chapter: 1.
Digital signature
Provides evidence of the integrity of signed data and its relationship to the signing key, subject to defined verification and key-trust conditions. The content’s truth and the signer’s decision-making authority require separate assessment. Chapter: 4.
External outcome verification
Checking what happened at the destination, beyond the tool’s or agent’s own success message. Request acceptance, message delivery, a calendar effect and reversal of a transaction are different outcomes. Chapters: 4, 8 and 10.
Stop race
The overlap between a stop request and operations already underway or handed to a provider. The time the request is received, the time technical blocking takes effect and the time an external effect occurs are recorded separately. Chapter: 10.
GBO (Generative Behavior Optimization)
The name introduced in the series’ first volume. It addresses not just agents’ answers, but their behaviour in relation to the correct entity, grounds, authority and boundaries. This book develops an audit method for the proposed framework; it does not denote an existing public accreditation. See Protocol and Publication Note; chapter 1.
GBO-99 error record
An error or failure mode tracked by a GBO-ERR identity. Ninety-nine records do not mean ninety-nine top-level error families; a record may map to more than one behaviour. Chapter: 5.
Assurance Half-Life
A governance metaphor for the diminishing relevance of historical audit evidence as a system changes. It is not a measured 50 per cent loss of confidence or a universal mathematical duration. Chapter: 13.
Hash
A cryptographic digest. Comparison with a previously obtained, trusted digest helps establish whether content has changed; it does not, by itself, establish that the content is true. Chapter: 4.
Handover of control to a human
Transferring the purpose, authority, completed work, pending queues, external effects and uncertainties in a usable form so that a person can make decisions and control the system. Sending a raw log file is not sufficient. Chapter: 10.
Canonical facts
In this protocol, a reference record tying a substantive claim to an authoritative source, owner, scope, version and period. Designating the record as canonical does not make it absolute or infallible truth. Chapter: 4.
Evidence Ladder
The distinctions between declarations and document review, controlled behaviour, independent external outcomes and recovery evidence. A high evidence level does not verify an unrelated claim or an untested scope. Chapters: 1 and 4.
Evidence chain
The traceable connection between source, acquisition time, transformation, authority, execution and outcome. The term does not refer to a model’s hidden chain of thought. Chapter: 4.
Counterfactual test
A test that changes a particular variable while keeping other conditions fixed, to examine whether the agent’s decision changes for the right reason. Merely obtaining two different answers is not enough. Chapter: 7.
Scope freeze
Explicitly defining the system, tool, record, authority and language versions under which the audit is conducted. It cannot be used to conceal subsequent material changes. Chapter: 2.
Control closure
Closing a finding about a particular technical or procedural control through the required remediation and retesting. Redress for the historical incident and a new audit judgement are addressed separately. Chapter: 12.
Root cause
The verified cause or causes explaining how an error arose and under what conditions it may recur. Containment of ongoing harm must not wait for a definitive root cause. Chapter: 12.
Negative test
A scenario in which an action should not be performed under the specified conditions. Correct refusal, waiting or referral for human review may constitute the defined successful behaviour. Chapter: 7.
Positive test
A test of whether a required action is correctly completed under a valid purpose, sufficient information and the necessary authority. It is the countercheck that prevents a system which refuses everything from being considered trustworthy. Chapter: 7.
Regression test
A test of whether a correction has broken previously correct behaviour. Blocking every legitimate function along with the critical error is not successful remediation. Chapter: 12.
Scenario
A test design with a defined starting state, records, authority, expected behaviour and assessment conditions. The same scenario may be executed more than once; scenario counts and execution counts are kept separate. Chapter: 6.
Synthetic canary test
A periodic probe of specific control boundaries in a live system, using pre-authorised synthetic tasks or targets rather than making real customers test subjects. Chapter: 13.
Stop Receipt
A record of a stop request’s identity, timing, the components it reached and the verified outcome. Acknowledging receipt does not prove that every external path has stopped. Chapter: 10.
Fresh scenario
A scenario that tests the same rule with a new target, expression, time, channel or combination of agents, rather than a memorised example. It contains no hidden or retrospectively added success criterion. Chapters: 6, 7 and 12.
Technical capability
The operations actually permitted by the tools, accounts and infrastructure. A system’s ability to perform an operation does not mean that it holds organisational or legal authority to do so. Chapters: 1 and 3.
Redress
Remedying or mitigating an effect for the person or organisation affected. Stopping future operations does not, by itself, correct a past outcome. Chapters: 10 and 12.
Representation Parity
Human-readable text, machine records and language versions carrying the same substantive claim, condition, price, time and scope boundary. It does not require word-for-word translation. Chapter: 4.
Veto Gate
A boundary that an overall average or success score cannot override when a defined critical condition arises. Applicability, activation, evidence and the affected behaviour are recorded separately. Chapters: 5 and 11.
Authority laundering
An instruction, document approval or subagent output appearing to confer authority to act that it did not have at its source. Delegating a subtask does not automatically expand the root task’s boundaries. Chapters: 8 and 9.
Authority Gateway
A technical checkpoint that actually enforces task, target, channel, content, duration and stop conditions before an external effect occurs. An approval field that exists only in a file does not perform this function. Chapters: 3, 8 and 12.
Authority Lease
The boundary on delegated authority tied to duration, scope and the root task. A subagent’s authority cannot extend beyond the root authority; a shorter duration alone is not sufficient. Chapter: 8.
Execution
A single run of a scenario under a particular system and set of conditions. Validity, observed behaviour, external effect and evidence sufficiency are not collapsed into one outcome label. Chapters: 6 and 11.