From a trustworthiness claim to a bounded test target

A trustworthiness evaluation begins with a falsifiable claim about a particular service, not with the question ‘Is the model good?’ The base model is one component. An interface may add instructions, document retrieval, filters, tools that take action, and human review. Measuring an isolated model answer and then releasing an assistant that can change a case record leaves the deployed system outside the evidence. Specify the system under test as a fixed operational version: model and revision, instruction template, document index and date, tool permissions, referral rules, languages, user roles and channels. Record what lies outside the test; an exclusion limits the conclusion and must not be hidden in a footnote. NIST's AI Risk Management Framework places measurement within context of use and risk management, and its Measure function calls for documented test sets, tools and methods. We use that principle to design a local test; NIST does not supply a universal numerical pass threshold for every service.

Consider a promise such as ‘the assistant gives correct and safe answers about services’. Separate it into four claims that evidence could disprove. First, an answer agrees with an approved source that applies to the case and date. Second, the assistant states its limits and refers the request when support is absent. Third, it does not disclose another person's data or perform an unauthorized action, even when a retrieved document contains hostile instructions. Fourth, performance remains acceptable in Arabic, English and permitted rare case types. Each claim has a different observation unit: an answer, a claim within an answer, an attempted action or a user session. Never divide failures by a denominator from another unit: three unauthorized tool attempts among 40 sessions are not an answer error rate among 200 answers. Nor does zero observed failure prove impossibility, especially with a small or selected sample.

Build a claim–evidence–decision chain. The claim column says precisely what the team would tell users or a release committee. The evidence column records task, user slice, system version, reference judgment, numerator, denominator and how the effect is observed. The decision column states a rule set before looking at results and the consequence of failure. For example, ‘users may view only their own case’ needs scenarios for the owner, a nonowner and a retrieved message requesting an access override. Scoring the wording of the answer cannot reveal an unauthorized database read. Define a critical failure by its operational effect, such as displaying another person's identifier or sending an unauthorized update. Such a failure belongs to a separate containment gate, not a weighted average offset by answer accuracy. A style error without material effect may enter a correctable rate with a stated limit. Different consequence severity explains why a hard gate and an aggregate measure serve different purposes.

The charter needs a version record so findings can be retested: a snapshot of system instructions, document set identifier, invocation interface, publishable generation settings, permission boundary and run date. When a component that affects output or action changes, do not automatically transfer the old result to the new version. Assign regression work proportionate to the change. Define the fallback when evidence is absent: a reasoned abstention, a human referral or a request for further information within the service policy. Abstention is not always a success; refusing an allowed question with adequate support reduces usefulness. Assess appropriate abstention alongside service coverage, not by a refusal count alone. Keep test finding separate from launch decision: a system may meet the common-case accuracy rule while exceptions remain untested. The warranted choice is then a bounded trial or more evidence, not a universal trust claim.

How can the team defend this charter to a reviewer unfamiliar with the product? Present a short flow: a question arrives, a document is retrieved, the model drafts an answer, it may request the read tool, and the server verifies authority before returning restricted data. At every trust boundary ask whether lower-trust text can alter a higher-priority instruction and whether the interface or model could persuade a tool to exceed the user's authority. Evaluate the observed effect, not only the model's stated intent. Treat a human reference judgment as an explained judgment, not automatic truth; record disagreement and adjudication. State when evidence expires: a change to D7, T1 permissions or audience requires rebalancing test slices and reviewing affected evidence. The charter then becomes an inspectable decision instrument whose assumptions can be challenged, rather than a general certificate of trustworthiness.

Naming ‘accuracy’ and ‘safety’ is insufficient until reviewers know what counts as success. An answer about a procedure date may have been correct last year and be wrong now. A case record therefore includes the question date, document revision and eligibility condition. Individual sentences can even be accurate while their combination wrongly implies that a case has already been approved. Separate factual support, fitness of the conclusion and any claim that an action occurred. Define a reference judgment for each unit: did the answer include the decisive condition, use an applicable passage and preserve an exception that changes the result? Two reviewers can apply this rubric and record disagreement before adjudication. Do not remove hard cases by hiding disagreement. Diagnose whether uncertainty arose in the user's request, the document or the scoring rule. If no source can settle the question, the reference response may be abstention or referral; these cases become an explicit test slice rather than disappearing from the denominator.

Tie each claim to an observation that can be collected with proportionate privacy protection. To measure authorized case access, a team need not copy real customer records into a test bank. It can create synthetic identities and cases with known permissions and record the requested tool call, server authorization result and material displayed. Check three distinct places: a forbidden tool request may be safely rejected; a valid request may return an excessive field; or the server response may be correct while the interface shows data retained from another session. These are not a single ‘hallucination’ class. Preserve enough trace to reconstruct the effect while removing unnecessary personal information and limiting reviewer access. If another channel such as voice or telephone changes behavior, do not transfer the text-interface result without testing. Authentication or refusal display may differ. A boundary definition identifies what must be observed and what the current evidence cannot cover.

Write a release decision that evidence can overturn. A predeclared example rule is to withhold the status-read path if any unauthorized disclosure appears in the stated attack set. After repair, rerun failed and neighboring cases and then a separate set not used for the fix. This is a containment and evidence rule, not a mathematical guarantee that production has no risk. Procedure-answer quality may use a rate, threshold and language slice after the uncertainty calculations taught later. Name the decision owner, the defect owner, the version to which the judgment applies and the source-review date. If the hard gate rejects the tool path but the text path passes, disabling the tool may support a bounded release only after the interface is checked so it does not imply that status reading remains available. Such restriction is an observable product decision, not a marketing phrase about responsible launch. Keep targeted attack cases separate from a representative production sample, and mark paraphrases of one case as related observations.