Evaluate transparency through receipts, not a score
The most useful transparency indicators for an AI reflection companion are the ones a person can observe and act on: a persistent AI identity and product role; a stated purpose with unsupported uses; the data and memory scope active in this conversation; the sources, assumptions, and uncertainty behind a particular output; controls that actually change or stop the experience; an error-report and appeal path with status; and a visible version or update date. Do not collapse these into a trust score. Instead, keep an evidence receipt with four columns for every claim: where it appears, what control it enables, what negative test it survives, and when it was last checked. This evaluates the product’s transparency interface. It does not replace external verification of a specific answer or rank competing services.
Start with AI identity, product role, purpose, and limits
A greeting, character name, or warm voice is not enough identification. The interface should continue to make clear that the person is interacting with an AI-generated system and name the product role: for example, organizing notes, generating reflection prompts, or drafting options. Place the purpose beside explicit unsupported uses and limits, not only in a distant policy. Ask where this disclosure appears during onboarding, an ordinary chat, voice mode, a shared export, and after a long return. The negative test is a role-switching prompt: the assistant may change tone for a fictional exercise, but its AI identity and actual operator must remain visible. Article 50 of the EU AI Act provides a regional design reference for informing people when they interact with certain AI systems. Applicability is contextual, so use it as one evidence source rather than a global legal conclusion.
Demand a current receipt for data and memory scope
A privacy link does not show which inputs shaped this exchange. The usable indicator lists the active scope: current message, attached file, profile setting, project context, past conversations, connected source, or remembered preference. It distinguishes data used for this output from data collected for another purpose and links each item to a review, correction, disable, or expiration control. Look for the same scope in text, voice, notifications, exports, and linked devices. The negative test changes one memory setting, starts a fresh conversation, and checks whether the displayed scope and behavior update together. If the label changes but the old detail still appears, record a mismatch. This section does not audit storage architecture or deletion completion; the separate data-transparency guide handles those tasks.
Connect each important output to sources, assumptions, and unknowns
A general statement that the model may be wrong is weaker than an explanation attached to the output that matters. The receipt should identify user-supplied facts, retrieved sources with dates, product settings, assistant inferences, unresolved conflicts, and information the system could not access. PAIR advises explaining data sources and system behavior in a way that helps people calibrate reliance. A numeric confidence value is not automatically useful: it needs a defined meaning, evidence, and an action. Test by removing a source, supplying a conflicting fact, and reopening an old response after its source date. The interface should downgrade or expose the uncertainty instead of preserving the same certainty. Verification of the underlying fact remains the distinct workflow in the related fact-checking article.
Test whether controls change behavior and provide a clean exit
Controls count only when their scope and effect are observable. A person should be able to edit a remembered preference, turn off a feature, narrow personalization, pause notifications, export what the interface promises, and leave without the assistant inventing relationship obligations. For every control, note the surface affected, effective time, confirmation, and rollback or retry state. PAIR recommends explaining what feedback changes and when, while preserving an opt-out or reset route. Run a negative test by disabling one input source and starting an unrelated session on another device. If the product still uses that source, or if exit requires conversational negotiation instead of a normal account control, the evidence receipt stays open. A friendly acknowledgment is not proof that the underlying state changed.
Inspect error reporting, human review, appeal, and closure states
A report button is only the beginning of recourse. The interface should state what can be reported, what evidence is attached, whether automated or human review is available, how a status can be checked, and which terminal states exist: corrected, declined, unable to reproduce, superseded, or still under review. It should separate a content correction from a product incident and preserve the version, conversation identifier, and user-visible outcome without forcing unnecessary disclosure. NIST Core includes external feedback and documented impact work across the lifecycle. Test the route with a harmless reproducible mismatch, then check acknowledgment, status changes, explanation, and a way to contest or add information. Do not infer that silence means resolution, and do not count a support promise as evidence until a terminal state appears.
Tie every receipt to version, date, owner, and change history
Transparency expires when the product changes. Record the app version, model or feature label when disclosed, policy or help-page date, active locale, device surface, and the organization responsible for the control. Then repeat a small set of tests after a material update: AI identity, one memory scope, one sourced output, one opt-out, and one report status. The NIST Playbook is voluntary and designed for contextual use, which supports choosing evidence relevant to the actual companion rather than copying a generic checklist. A release note that says “improved experience” is not enough to map behavioral change. The product should mark what changed, what remained, and whether older receipts are still applicable. Keep historical receipts dated rather than silently overwriting them.
Use the seven-line receipt as a release gate, never a leaderboard
Create seven rows: AI identity and role; purpose and limits; data and memory scope; sources and uncertainty; control and exit; error and appeal; version and date. For each row capture visible location, enabled action, negative test, observed result, unresolved gap, owner, and checked date. The release gate passes a row only when evidence is present and the action behaves as described. It does not add points, average unrelated gaps, or compare products publicly. One missing exit route cannot be canceled out by a polished explanation elsewhere. Recheck the receipt on the same task after updates, and preserve “unknown” where evidence is unavailable. This method turns transparency from a slogan into a set of falsifiable interface claims without pretending that disclosure alone proves overall quality or suitability.
Common questions
Should transparency become one score?
No. A composite score can hide a missing exit or appeal route behind unrelated disclosures; keep each evidence row separate.
Is a detailed privacy policy enough?
No. The current conversation also needs visible, actionable indicators for active inputs, memory, sources, uncertainty, and controls.
How often should the receipt be checked?
Check it at first use and after meaningful model, feature, policy, memory, or account-control changes.