The strong rivalInstitution and brand are rational shortcuts

Customers cannot inspect model weights, supplier controls, security architecture and every quality distribution. They rationally use a provider's history, contract, independent certification, policy, support and reputation as compressed evidence. Institutional trust can reduce impossible verification work and make accountability legible. A recognised provider with a credible service history may deserve more initial confidence than an unknown product making the same claim.

The shortcut fails when general reputation is allowed to stand in for task-specific behaviour. A strong privacy programme does not prove that one conversation is excluded from secondary use. Certification of a management system does not show that a new model version preserves abstention on a medical task. A contract promising human review does not show that the reviewer can detect an unsupported citation. Brand can support prior judgement, but the product must update that judgement through use, uncertainty, change and failure.

A behaviour contract also has limits. Showing every caveat can overwhelm the customer, create warning fatigue and transfer all verification cost to the person. Teams can optimise visible metrics while excluding difficult cohorts. Friction can reduce over-reliance while making the safer product unusable. The design task is selective: expose what changes a decision, enforce what users cannot reasonably police, and keep non-reliance available when the evidence does not justify vulnerability.

Trust Behaviour ContractSeven behaviours that can be inspected

The dimensions work as a system. A competent model can still be unsafe if it sends a message outside the disclosed authority. A visible uncertainty label cannot protect a person who cannot interrupt an action. A correction control creates false reassurance if derived records, customer communications and external decisions retain the error. An incident response is incomplete when the provider fixes the model but cannot identify who relied on the earlier output.

Each dimension should be written as behaviour under conditions, not as an adjective. “Transparent” becomes: for recommendations in the supported lending-review task, show the decisive input fields, source date, output status and material exclusions before a reviewer commits a decision. “Controllable” becomes: a reviewer can suspend pending writes, correct the customer record, identify downstream recipients and see which actions were reversed. Conditions make the contract testable.

The contract also defines abstention as successful behaviour. When a request falls outside the evaluated population, the product can say what it cannot support, preserve the user's work and provide a route to a qualified person or a narrower task. This may reduce immediate completion and increase justified reliance in the product's boundary. Teams should include abstentions in outcome review rather than treating every refusal as lost conversion.

Responsibility cannot be delegated to a label. Product owns what the interaction invites, engineering owns enforced state and limits, data and model teams own competence evidence, operations owns incident reach, customer teams own support promises, and legal interprets applicable duties. One named contract owner reconciles these views at release and at material change.

Calibrated relianceObserve decisions, not one sentiment score

A product team needs behavioural measures that preserve context. For each supported task cohort, observe acceptance, verification, override, abstention, interruption, recovery, complaint and abandonment. Join those events to consequence, evidence state, model version, user role and eventual outcome where lawful and feasible. The aim is not surveillance of individuals. It is to find where product behaviour invites reliance that the evidence does not support, or discourages reliance that the evidence does support.

Acceptance alone is ambiguous. A high rate may reflect reliable assistance, time pressure, defaults, management expectation or an inability to detect error. Verification can signal healthy scepticism or unnecessary labour. Overrides may reveal model defects, expert preference or users correcting a poor task definition. Complaints undercount harm when people do not discover an error, cannot connect it to the product, expect no remedy or have already left. Abandonment can be a rational response to opaque failure even when average performance remains strong.

Evaluate the joint outcome. In a low-consequence drafting task, quick acceptance followed by easy editing may be warranted. In a benefit determination, acceptance without checking decisive evidence may be over-reliance even if most recommendations are correct. In an exploratory analysis, repeated rejection of well-sourced options may be under-reliance created by a confusing interface or a history of unannounced change. Product decisions should use distributions and cases, not a scalar “trust score”.

Calibration tests need plausible counter-signals. Seed unsupported citations, out-of-population inputs, stale records, supplier changes and ambiguous authority in controlled evaluation. Observe whether the product abstains, whether users notice the signal and whether the workflow lets them act on it. A system that performs well only when every input is clean has not shown how reliance should change under uncertainty.

People also learn from product behaviour. A consistently useful assistant can earn reliance, but one confident failure can rationally change the customer's threshold if similar failures are difficult to see. Recovery quality affects future decisions: prompt disclosure, complete correction and a credible change in limits can support re-evaluation; apology language without changed behaviour should not. Measure learning across versions and incidents without treating renewed usage as proof of restored warrant.

Trust-claim ledgerSubstantiate the invitation, not just the model

Material claims occur wherever a person forms expectations: a campaign, sales deck, procurement answer, onboarding screen, status label, support script, privacy notice or incident message. The ledger records the exact wording and audience, the reliance behaviour it intends to encourage, the product behaviour that supports it, the evidence population and date, uncertainty and exceptions, prohibited inference, failure notification and remedy, owner, review trigger and retirement.

Begin with the reliance verb. “Reliable answers” may invite a user to accept without verification, while “helps you locate candidate sources” invites exploration. If the team cannot state which behaviour it wants, it cannot judge whether the claim is safe or useful. Different audiences can draw different inferences from identical language. A procurement professional may read “enterprise-ready” as a security and support representation; an end user may read it as permission to use the product for any work task.

Next connect the wording to enforced behaviour and dated evidence. If a product says it checks citations, specify whether it confirms that a link resolves, that the cited passage exists, or that the passage supports the generated proposition. Those are different tests. State the evaluated source types, language, retrieval date, version and residual uncertainty. An interface should show the status that matters to a decision rather than decorating every sentence with an identical citation icon.

Exceptions prevent a supported claim from expanding by implication. A quality evaluation on English-language public policy documents does not support private legal advice in another jurisdiction. A read-only trial does not support a later connector that can send messages. The prohibited-inference field records the tempting conclusion the evidence cannot carry. This field should shape copy, sales training and interface defaults.

Claims expire. A model, retrieval index, prompt, tool, supplier, customer population or regulatory context can materially change. The ledger owner identifies which changes trigger review and which require withdrawal before revalidation. Retirement should remove the wording from every channel, including cached onboarding, documentation and support macros. Leaving a stale claim in one route preserves the old reliance invitation even if the main website is corrected.

Regulatory and standards evidence belongs in the ledger with disciplined scope. NIST's AI RMF gives voluntary risk-management characteristics and lifecycle outcomes; its published 1.0 is being revised. OECD principles, updated in 2024, frame transparency, robustness, accountability and human-centred values. The EU AI Act and GDPR create duties only where their provisions and scope apply. ISO/IEC 42001 concerns an organisational management system. None independently proves that one recommendation is correct or that one product behaviour warrants reliance. Applicable legal conclusions require context and qualified interpretation.

Lifecycle behaviourReliance is earned, interrupted and re-earned

Onboarding establishes the first competence and authority boundary. It should show supported tasks, consequential exclusions, data use, external actions and where a person retains a decision. Progressive disclosure can keep the interaction usable, but a material action must not remain hidden until after it occurs. Defaults should reflect the safest common reliance pattern, especially where a person cannot easily detect or reverse an effect.

Normal use updates the contract through performance. Source and action status should remain close to the decision. The product should distinguish a generated draft, a validated field, a pending external action and a completed write. Controls need semantic reach: correcting the visible text is different from correcting the customer record; stopping a progress animation is different from stopping queued tool calls.

Uncertainty is a behavioural state, not decorative probability. The product should surface what changes the user's next action, abstain outside its evaluated boundary and route unresolved consequence to an appropriate person or process. Paper 074 develops uncertainty interfaces in depth. Here the point is narrower: uncertainty display warrants trust only when it changes product or user behaviour.

A material change resets affected evidence. Compare the new model, prompt, tool, retrieval source and supplier behaviour against the contract dimensions. Identify affected cohorts, retest disconfirming cases and communicate changes before customers inherit a different authority or error pattern. Tone changes can matter if they alter perceived confidence even when task performance appears stable.

An incident begins when actual behaviour breaches the invitation to rely, not only when a model service fails. Contain the affected authority and population, preserve the trace, disclose known facts and uncertainty, locate downstream effects and provide a remedy route. Recovery is not a return to the previous claim. The provider should narrow scope, demonstrate changed controls on relevant cases, involve affected customers and restore authority in bounded stages.

Explanation is an interventionTest whether it improves discrimination

Explanations can answer legitimate user questions about purpose, process, evidence and recourse. They can also increase acceptance because fluent language feels considered. Research on human-AI teams warns that explanations may raise reliance without improving complementary performance. A product team should therefore test the behavioural effect of each explanation format, including whether people distinguish correct from incorrect outputs, notice missing support and choose an appropriate next step.

The comparison needs a negative control. Present matched correct and incorrect outputs with the same explanation fluency. Then compare a source-support view, material counter-signal, example boundary or uncertainty status. If the rationale increases acceptance in both conditions, it is a placebo for calibration even if users say they prefer it. Preference still matters for usability, but it cannot be used as proof that the interface supports warranted reliance.

Cognitive forcing, such as requiring an independent judgement before revealing a recommendation, can reduce over-reliance in some settings and can also create friction or lower preference. Use it selectively where consequence, error detectability and time pressure justify the cost. A low-stakes writing aid may need lightweight provenance and easy editing. A high-consequence review may require verification of decisive evidence, a recorded counter-view or separation of proposal and commitment.

Explanations should not smuggle authority. A detailed description of why the product plans to send a message does not authorise the send. A consent-like button does not create meaningful control when the user cannot inspect recipients, cumulative effects or alternatives. Keep evidence, action status and authority distinct in the interface and in the trace.

Nine boundary casesTrust behaviour under pressure

These cases expose why brand, complaint volume and overall accuracy are insufficient. The same product can warrant direct reliance for one bounded task, verification for another and withdrawal for a third. The right unit is the product behaviour contract attached to a task, population, version and consequence.

Correction and remedyFollow the effect, not the interface object

Suppose a customer discovers that an extracted income field is wrong after an AI-assisted eligibility review. The first action is containment: pause pending decisions and further propagation associated with the disputed value. The correction records the source, prior value, new value, reason, time and authorised actor. It does not overwrite history in a way that destroys the incident trace.

The product then traverses the effect graph. Derived features, caches, embeddings, reports, recommendations, customer messages and external decision systems may each contain or depend on the old value. Some objects can be recomputed; others need reversal, manual review or explicit notation that the earlier decision is no longer valid. The customer should not have to identify every internal copy before the provider accepts responsibility.

Remedy concerns consequence, not data hygiene alone. If the value contributed to a denial, delay, charge or communication, the provider determines what can be reversed, repeated, compensated or explained. It tells affected people what is known, what changed, which downstream effects were repaired and which remain open. Where laws, contracts or sector rules apply, notification, access, correction and redress follow their specific scope.

The closure receipt supports re-earned reliance. It links the detected error to contained actions, corrected objects, re-evaluated decisions, notifications and owner sign-off. It also states the product change that reduces recurrence and the test that could disconfirm that change. A green status without this evidence is a fresh claim, not proof of recovery.

Five product routesMake the reliance invitation match the evidence

Permit warranted reliance for the bounded task when the population and consequence are clear, evidence is current, exclusions work, authority is limited, decision-relevant status is visible, control reaches downstream effects and claims remain precise. Permission is not permanent. Keep cohort monitoring and the disconfirming test live, then review at material change.

Require verification or friction for this consequence when the product is useful but reliance exceeds the available warrant. Add a source-support check, independent judgement, counter-signal, specialist review or separation between proposal and commitment. Test whether the intervention improves error discrimination, not just whether users complete it.

Restrict scope, authority or affected population when competence is partial, a change is stale, authority exceeds need or control is only cosmetic. Remove tools, narrow cohorts, cap cumulative action, fall back to proposal-only mode or exclude the consequential task until evidence catches up. Restriction is a product feature when it preserves the useful core.

Repair the breach and re-earn reliance through evidence when behaviour has violated the contract. Contain authority, preserve facts, notify affected people, propagate correction, remedy consequence and prove the control change against the incident pattern. Restore scope in stages; customer return by itself does not demonstrate recovered warrant.

Withdraw the claim or product because reliance is misleading when a material representation is false, evidence is absent or contradicted, severe failure is hard to detect, stewardship is breached without a credible remedy, or the team cannot own the effect. Removing persuasive language is insufficient if the product still invites the same reliance through defaults and workflow.

The Trust Behaviour Contract does not promise certainty. It disciplines the invitation. Product leaders should be able to point from any consequential claim to the behaviour that makes it true, the evidence that bounds it, the exception that stops expansion and the remedy that follows failure. Customers can then rely where the evidence warrants, verify where consequence demands and refuse where vulnerability would be unreasonable.

Trustworthy product conduct is revealed when the system is wrong, uncertain, changed or challenged. It abstains without abandoning the user, limits authority before consequence accumulates, preserves meaningful choice, corrects the whole effect graph and learns in a way that can be tested. A brand may open the door. Only repeated observable behaviour gives a person reason to remain vulnerable on the other side.

Operational proofReview the contract where systems and teams meet

Test the claim chain end to end

A claim review should begin with the exact product surface, not a summary prepared for governance. Capture the words, icon, default, timing and audience. Ask a representative user what action the surface appears to permit and what protection it implies. Compare that interpretation with the technical behaviour, evaluation population, support process and commercial terms. A mismatch at any link is a product defect even when each team approved its own artefact.

Claims should be tested under failure as well as success. If an interface says that sources are checked, introduce a valid link whose text contradicts the generated proposition, a source that changed after indexing and a page the product cannot access. Observe status, abstention and correction. If “you remain in control” is material, test a queued write, delayed tool response, duplicate event and stop request during partial execution. The phrase is substantiated only if control reaches the external effect.

Sales and support need the same ledger. A carefully bounded interface can be undermined when a demonstration implies universal competence or a support agent reassures a customer that an update “does not affect anything”. Give customer-facing teams the evaluated population, prohibited inference, change status and escalation route in language they can use. Sample actual calls and tickets for expansion, then correct the product claim rather than blaming individual wording alone.

Separate prior confidence from earned evidence

Institutional signals belong at the start of judgement. Security history, governance certification, contract terms and independent assessment can justify investigation or procurement. After use begins, task evidence should carry more weight. Track which version served the output, whether the case matched the evaluated population, what tool and data authority applied, and whether the user could challenge the effect. A general badge should not remain the strongest signal after direct contradictory behaviour.

Independent assurance adds value when its scope, method, date and exceptions are visible. A management-system audit may show that an organisation maintains defined processes. A product evaluation may show performance on a population. A penetration test may address a technical threat set. Each supports a different inference. The claim ledger records the inference and blocks the others. Renewal dates should not silently extend evidence across a material product change.

Customer scepticism can provide disconfirming evidence, but the provider should not make every user an unpaid auditor. Aggregate overrides, disputed records and abandonment patterns; offer a protected route to report hard-to-detect failures; and investigate cohorts with few complaints but high exposure. When users lack access to ground truth, the team needs independent samples, downstream outcome review and red-team cases. Silence cannot close the evidence gap.

Govern the behavioural release

A release review maps each change to the seven dimensions. A new model may alter competence and abstention. A connector alters authority, control and trace. Memory changes stewardship and user expectations. A confident tone can alter reliance even if benchmark quality is constant. The team identifies affected claims, cohorts, tests, interface states, support language and incident playbooks before the change reaches customers.

Use graduated release for changes that modify reliance. Begin with a bounded population and proposal-only authority. Compare outcomes and reliance decisions with the prior version, including negative controls. Expand only when evidence supports the next cohort or action class. If monitoring cannot distinguish a useful correction from harmful acceptance, hold the boundary. Feature adoption is not the release criterion for consequential behaviour.

Ownership persists after launch. The claim owner watches review triggers, the product owner watches interaction and reliance patterns, operations tests interruption and repair, and customer teams detect expectation drift. A periodic meeting is insufficient if a supplier can change between meetings. Material automated alerts should open a claim review, but a person remains accountable for interpreting scope and deciding whether to restrict or withdraw.

Prove re-earned reliance without manufacturing confidence

After a breach, the provider may be tempted to restore confidence through apology, executive visibility or new certification. Those actions can matter, but re-earned reliance begins with reduced exposure. Suspend the affected claim and authority, preserve the incident cohort, correct the effect graph and provide a remedy that affected people can use. Publish what is known with uncertainty, rather than waiting for a complete narrative or offering premature reassurance.

The corrective action needs a disconfirming test tied to the failure mechanism. If unsupported citations caused harm, test proposition-level source support across the affected source types and force review when support cannot be established. If a hidden update changed tool behaviour, pin the relevant version, compare action traces and require revalidation before another material change. If conversation data were reused improperly, stop the pipeline, locate derived data and verify deletion or lawful retention according to the actual representation and applicable duties.

Restoration proceeds by behaviour. Reopen a narrow task with lower authority, visible status and enhanced monitoring. Let affected customers choose whether to participate. Review whether errors are detected, corrections propagate and reliance matches current evidence. Only then consider wider population or authority. The goal is not to make people feel trusting again. It is to make the product sufficiently assessable that willingness or refusal can be well founded.