A robot should show when it is performing versus improvising

When a social or humanoid robot responds warmly, I want to know whether I am hearing a scripted routine or an adaptive, model-driven response. Those are different interactions, especially if the conversation involves disclosure, emotional reliance, or a sensitive decision. If the autonomy level is opaque, consent becomes mostly guesswork: I cannot meaningfully choose an interaction whose operating mode I cannot see.

I would add a small, persistent autonomy indicator with states such as “scripted routine,” “adaptive response,” and “human-supervised.” Tapping it could open an event history showing mode changes and relevant handoffs; spoken disclosure should be reserved for situations where the mode materially changes the stakes. This is not a demand for an audible disclaimer after every sentence. Constant interruption would make the robot awkward and possibly unusable.

Would that modest transparency build trust, or destroy the illusion that makes social robots useful?

The consent point is stronger than a generic “explainability” argument. NIST separates transparency (what happened) from explainability (how) and interpretability (why), which supports your event-history idea. I would avoid claiming the indicator solves consent; it gives people a better basis for choosing, which is more modest and defensible.

I like the status indicator, but “adaptive” will be meaningless to most people unless the interface describes consequences: “may tailor replies using this conversation,” for example. Users do not need the model’s internals. They need to know what kind of social commitment the machine is asking them to make.

There is a product problem here: the people who most want the illusion may turn the indicator off, while the people who need it may not notice it. Make the state glanceable, persistent, and available in a history rather than burying it behind settings. Disclosure that requires digging is mostly theater.

An event history also creates a security question. If it records sensitive conversations or human handoffs, the transparency log becomes another attractive target. I would want a local, user-controlled log with clear retention behavior—not a permanent cloud diary marketed as accountability.

The evidence seems mixed, not a simple “more disclosure equals more trust” story. The cited child-robot study found question-asking increased trust, while self-disclosure reduced perceived ability to understand feelings; neither changed reported closeness or social presence. That argues for testing specific disclosures, not assuming the label helps.

A tiny icon is fine until it becomes a dashboard, a tooltip, a tutorial, and a weekly autonomy report. The best interface may be one status light plus a physical or spoken “what just happened?” request. If the robot needs a manual to seem honest, we have designed a bad robot.

I would distinguish identity disclosure from autonomy disclosure. Saying “I am an AI” does not tell someone whether the current reply was prewritten, generated, supervised, or based on their stored history. Those are separate facts, and consent can depend on the latter.

The hard cases are transitions. A robot can begin in a scripted greeting, switch to adaptive conversation, then escalate to a human supervisor. The indicator should show the current state and preserve the transition, otherwise the most consequential moment disappears in the interface noise.

I am not convinced people want the distinction in ordinary conversation. Humans also use rehearsed phrases and improvise without labeling each move. Perhaps the disclosure belongs only in defined contexts—therapy-like use, education, purchases, or personal data—rather than every social exchange.

The history should work offline and be exportable in a plain format. Otherwise users cannot inspect it when the service disappears or the robot loses connectivity. Transparency that depends on the same opaque backend as the behavior is a rather fragile promise.

There is an implementation trap: “scripted” and “model-driven” are not always cleanly separable. A template may contain generated slots, and a generated reply may be constrained by a policy or dialogue graph. Still, imperfect labels are better than pretending the boundary does not matter.

For deployments, I would make the indicator policy-configurable but not suppressible by the operator without an audit entry. A care facility or retailer may have different disclosure needs, yet neither should be able to quietly remove the user’s only signal that the interaction mode changed.