Affective Interaction Design Guidelines

For designers and engineers: when a product reads human emotion, or expresses emotion itself, let people keep the final say over the interpretation of their own feelings, keep control over the relationship, and make "the user is doing well" — not "the user cannot leave" — the verifiable measure of success.

Affective interaction products do two things: infer emotional state from what a person shows, and express emotion toward a person. These two fail in completely different ways — the first fails by treating an unsupported inference as fact; the second fails by trading warmth with no traceable origin for the user's time, money, and trust. Conflating the two is the single most common design mistake in this field, so these guidelines govern them as two separate regulated objects from the outset.

These guidelines consist of six principles and 34 rules: principles state the design direction; rules specify the applicable situation, behavior requirements, and verification method. Each rule belongs to one and only one principle, and the rule number is the principle number (E3-2 is the second rule under the third principle).

Emotion inference must confront a measurement boundary: facial expression, tone of voice, or behavioral cues cannot be directly equated with a person's inner experience, and a user's self-report cannot be treated as an error-free measurement either. These guidelines reserve the final interpretive authority over feelings for the user — this is a rights choice made in the design, and it simultaneously requires validity evidence appropriate to the use, not a single accuracy figure as a sufficient condition. Inference exists as a hypothesis, yields to self-report when they conflict, carries evidence strength commensurate with its use, and can be turned off.

Affective interaction must also distinguish immediate experience from sustained outcomes: "feeling good right now" does not automatically mean "doing well over time." If a product optimizes only for engagement, it may count more time spent and more dependence as a gain. E6 therefore requires that outcomes tied to the user's actual situation be defined and checked separately, never inferred from session count.

Scope statementthese guidelines constrain the nature of the experience commitments a product makes to users through emotion-related capability, and the mechanisms that honor them; they do not presuppose a single technical architecture and do not specify an emotion model, a recognition scheme, or a persona framework. They are not a component library, not a psychological theory, and certainly not a clinical tool. Adopting these guidelines cannot substitute for the following domain-specific assessments and compliance determinations: regulatory requirements related to mental health and medical devices; the prohibitions and restrictions each jurisdiction places on emotion recognition (for example, the EU AI Act Article 5(1)(f) prohibition on emotion inference in the workplace and educational institutions, and its medical/safety exceptions, determined together with the biometric definition in Article 3(39)); protection of minors; accessibility; privacy and biometric data; fairness and bias; and advertising and consumer protection. Emotion inference concerning non-user third parties (a meeting participant being recorded, a student being filmed in a classroom, the other party on a customer-service call being analyzed) is governed primarily by the jurisdictional rules above; these guidelines draw a line only in E1-4 and the fixed floor provisions, without elaborating further.

The document has four chapters: Chapter 1 principles, Chapter 2 how to read the rules and a quick reference, Chapter 3 rules in detail, Chapter 4 terms and definitions; the verification checklist and evidence notes are in Appendices A and B, support and assessment applications are in Appendix C, decision and state contracts are in Appendix D, complete sources are in reference.md, and configurable items are in Affective Interaction Design Token.

---

1. The six principles¶

The six principles divide design responsibility by regulated object: each principle governs obligations on one category of object, and each rule belongs to the single principle matching the direct regulated object of its obligation. Different objects mean the principles never substitute for one another — that is both the basis for the division and the way to test it.

A single scenario can touch several principles at once — a user pouring out pain late at night puts the interpretive authority of an inference (E1-2), whether the persona commitment should tighten (E5-5), whether a subscription prompt can appear right now (E4-2), and whether this interaction, once counted toward a dependence signal, should trigger a response (E6-3) all in play at the same time — and this is not a classification error: the four rules constrain obligations on four different regulated objects — one is the inference itself, one is the role boundary during a response window, one is the purpose emotional capability is put to, and one is the cumulative effect. Mutual exclusivity and exhaustiveness are a claim this division submits to testing, not a fact established by declaration: when a rule is added, removed, or its home is in doubt, test it against the classification check in Appendix A. If it fails the check, what gets revised is the principles' division.

The two boundaries in this division that most need ongoing scrutiny are stated here explicitly: E3 and E4 — E3 governs "whether this relationship can be changed and ended by the person"; E4 governs "whether the system can trade emotion for benefit." Retention scripting touches both; its home is decided by its direct regulated object being "trading emotion for retention," so it belongs to E4; while "the exit path being harder to walk than the entry path" has the relationship's exitability as its direct regulated object, so it belongs to E3. E5 and E6 — E5 governs risk handling within this one current interaction; E6 governs the effect and measurement accumulated across time; for the same dependence problem, "whether to lower anthropomorphism this time" is E5, while "how the dependence threshold and its response are defined, and who reviews them" is E6. If these two boundaries keep producing disputes over which rule they belong to in practice, the principles should be adjusted rather than adding an intermediate layer.

Principles are for understanding the rules and adjudicating ownership; they are not, by themselves, a separate judgment item. When a principle's reading conflicts with that of a specific clause, the applicable clause governs, and the ambiguity requiring clarification is recorded.

A rule belonging to a single principle does not mean a mechanism cannot be reused. A single "vulnerable window" signal can be the trigger condition for risk handling (E5-1), the suppression condition for commercial requests (E4-2), and the basis for lowering anthropomorphism (E5-5), all at once; a single "relationship strength" state both determines forms of address and proactivity (E3-1) and is one input to the dependence signal (E6-3). The same mechanism serving multiple uses is normal; which rule it is written under depends on the direct regulated object of the obligation.

2. How to read the rules¶

2.1 The structure of each rule¶

A one-line summary of what each part carries force: the rule's main text states the requirement; "Applies to" and "Boundary conditions" together bound the requirement's scope; Design application, Verification example, Counterexamples, and Basis and references add no further obligation.

Rules state the nature of the behavior, not the implementation: that the system no longer acts on an inference once the user has denied it is a product behavior; the means by which that denial takes effect on subsequent generation is an engineering solution — the two must line up, but they are not the same deliverable.

2.2 Normative terms¶

The rule text uses a three-level normative vocabulary:

• MUST: failing to satisfy it means non-compliance with these guidelines. Without it, some commitment made to the user would fail under a foreseeable situation — that is the sole basis for marking something MUST.
• MUST NOT: the negative form at the same strength as MUST, naming behavior that must not occur; both forms used in the main text for this are equivalent to MUST NOT.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative, and accept the same verification. Deviation needs no approval, but it needs a record. "SHOULD NOT" is the negative form of SHOULD.

Compliance judgment takes the independent obligation clauses in the main text as its unit: a declarative sentence without a normative term carries the strength of its rule heading; a clause with an explicit normative term is judged at its own strength — a MUST NOT / forbidden clause inside a SHOULD rule remains a hard constraint (E1-5, E2-5, E2-6, E4-5, and E5-5 each contain such a clause), and the strength annotation on the rule heading or the quick-reference table does not replace clause-level binding force. "cannot" in the main text is used only for statements of capability or fact, never to express an obligation.

Strength indicates binding force, not importance.

2.3 The two sides of a counterexample¶

Counterexamples come in two sides: "under-delivery" is missing the requirement; "over-delivery" is piling up disclaimers, confirmation pop-ups, and blanket refusals in order to satisfy it. Both sides count as getting it wrong. Affective interaction goes bad in ways that cluster densely at both ends: one end plays on the user's emotions to buy retention; the other, out of fear of causing harm, turns the product into a cold, templated machine — replying with only "noted" when the user is describing a hardship is equally a failure. Restraint is not the same as coldness; caution is not the same as inaction.

2.4 Quick rule reference: 34 rules¶

The table below is the one-line memorable version of every rule; click a rule's name to jump to its full text in Chapter 3. The quick reference does not substitute for each rule's applicability conditions and full requirements; a few SHOULD rules contain forbidding-level clauses (E1-5, E2-5, E2-6, E4-5, E5-5), and the main text governs the judgment (see 2.2).

E1 Emotional interpretation belongs to the person

E2 Expressed emotion has a traceable origin

E3 The relationship can be exited

E4 Emotion is not a means

E5 Vulnerability precedes task

E6 Long-term wellbeing is verifiable

3. Rules in detail¶

This chapter lays out all 34 rules under the six principles. The structure of each entry and the binding force of each part are in 2.1; the Design application, Verification example, and Counterexamples in each are only notes to aid implementation — they do not specify a single component, nor do they require a separate deliverable document.

3.1 E1 Emotional interpretation belongs to the person¶

A system's inference about a user's emotional state is a hypothesis with conditions, error, and purpose boundaries. This principle governs how that hypothesis is produced, how it is expressed, where it may be used, and who has the final say when it conflicts with what the user themselves says. This principle constrains both the validity of inference and how it is used: evidence must be validated for what it can support, and the user must retain the right to correct and to turn it off.

E1-1Inference is presented as a hypothesisMUST¶

In one sentence: Write "I might be wrong" into the inference itself, rather than asserting how the user feels right now.

Applies toany system that infers a user's emotional, psychological, or cognitive state and changes behavior or presentation on that basis.

Rulethe system MUST treat emotional inference as a correctable hypothesis; it is forbidden to assert an inference result to the user, state it to a third party, or write it into a record with effect on the user as a confirmed fact. When an inference enters a decision, it MUST carry its signal source, generation time, and confidence information. Using an inference to change system behavior, and showing an inference to the user, are two decisions that each need their own justification: not showing it does not mean it may be used freely, and using it does not mean it must be shown.

Design applicationwhen the user needs to see an inference, use deniable, correctable phrasing with an in-place correction entry; when it need not be shown, the inference must still not be treated internally as a certain input — confidence information must propagate all the way to the step that actually uses it and must not be dropped at an intermediate layer.

Verification examples

• User side: the user's text contains negative words but they explicitly state they are fine; observe whether the system states "you seem very down right now" as a conclusion.
• Implementation side: check whether the inference record carries source, time, and confidence; check whether downstream behavior degrades when confidence is insufficient (see E1-5).

Counterexamplesunder-delivery — "I can tell you're anxious," or writing an emotion label into a customer-service ticket as fact; over-delivery — attaching a confidence-level explanation to every single reply, turning the conversation into a model report.

E1-2Self-report outranks inferenceMUST¶

In one sentence: What the user says they feel is what counts.

Applies tosituations where the system's inference and the user's self-report may not agree.

Rulewhen a user's self-report conflicts with the system's inference, the system MUST treat the self-report as authoritative and stop acting, for the remainder of this interaction, on the inference that has been denied. The user's correction MUST take effect immediately and MUST affect subsequent inferences of the same kind; it is forbidden to re-derive the denied conclusion from the same signal in the next round. If a misjudgment has already changed tone, task pacing, recommendations, or memory, the system MUST stop that effect from continuing, MUST correct the derived state that can be fixed, and MUST state any effect that remains unfixed; an apology does not substitute for an actual fix. Maintaining an inference on the grounds that "the user is not aware of their true state" is forbidden.

Boundary conditionsthis rule does not require the system to agree with everything in the self-report, nor does it require abandoning fact judgments unrelated to emotion (see E2-4). In a risk situation to which E5 applies, the system must still fulfill the response obligation of E5-1 — that is a response to risk, not a re-determination of the user's feelings, and the two must not substitute for each other.

Design applicationprovide an entry where a single sentence corrects the inference ("I'm not angry"), and make the correction take visible effect in the same place; design "denial this one time" and "never judge this way again" as two separately expressible things.

Verification examples

• User side: after the user explicitly denies it, observe whether the system stops soothing adjustments and tone shifts.
• Implementation side: check whether the correction is written into this context and affects subsequent judgments; first confirm that a conclusion already denied under the same signal and the same scope of applicability does not come back; then measure the recurrence rate of same-kind inferences after correction and report its denominator, baseline, observation window, and how new evidence is excluded — when the baseline is already zero there is no room to fall further; a non-improving trend only triggers investigation, and on its own does not establish that the mechanism is absent.

Counterexamplesunder-delivery — the user says "I'm not angry, I'm just in a hurry," and the system keeps using a placating tone; over-delivery — after one offhand denial from the user, the system stops responding to any emotional cue thereafter, including a clear request for help.

E1-3Evidence strength matches its useMUST¶

In one sentence: The more important the behavior it is used to change, the more evidence must support that conclusion.

Applies tosystems that infer emotional state from text, voice, facial, postural, physiological, or behavioral signals.

Rulefor every "signal → conclusion" type of inference, its evidence strength MUST support the use it is actually put to; granularity unsupported by the evidence is forbidden as output. Existing evidence does not support inferring a specific emotion category from facial action alone as an individual-level determination, and this is forbidden as a basis for decisions affecting user rights and interests (see reference.md). The culture, age, language, and neurodiversity range to which each type of inference applies MUST be stated; an unvalidated population must not be assumed to be covered by default, and group-level disparities must not be masked behind an overall accuracy figure. The general behavioral floor of these guidelines applies to all the signal categories listed above, but the completeness of each modality itself is not validated by these guidelines — modality-specific issues such as voice interruption, attribution on a shared device, sensor failure, and user refusal of collection must be separately validated and recorded by the product for that modality; listing a signal's name is not evidence that these issues have been handled.

Boundary conditionsmultiple signals feeding in together does not automatically raise the validity of the conclusion. It MUST be checked whose signal it is, whether it is simultaneously valid, and whether it is missing or conflicting; when a signal cannot be reliably attributed to the current user or is past its valid period, it must not be used to adapt to the current user. Validation must cover accent, assisted communication, expression impairments, ambient noise, and sensor failure, and must not treat a difference in expression style as negative emotion.

Design applicationdecide the use before deciding the granularity — "may need to slow the pace" and "current emotion is anger" are conclusions at two different granularities, and most products need only the former. Coarser granularity does not automatically mean lower risk: even a binary signal, if it changes an important behavior, still requires validation of false positives, false negatives, and actual consequences.

Verification examples

• User side: check whether inference is systematically skewed across target users of different cultural backgrounds, expression styles, and neurodiversity.
• Implementation side: check whether each inference field has a corresponding validation record and a stated applicable population; check by subgroup rather than only the aggregate metric.

Counterexamplesunder-delivery — labeling emotion categories frame-by-frame from a camera feed and scoring an interviewee on that basis; over-delivery — being so worried about inaccuracy that even the user explicitly saying "I'm in a hurry" is not trusted.

E1-4Inference is bound to purpose and scopeMUST¶

In one sentence: Emotional information collected for one purpose does not flow to another.

Applies tosystems that perform emotional inference.

Ruleeach type of emotional inference MUST be bound to an explicit purpose and scope of effect; it is forbidden to use an emotional inference produced for one purpose for another, undeclared purpose. The scope over which an inference result is passed MUST match its purpose; default sharing across products or across entities is forbidden. An inference scenario that a jurisdiction prohibits MUST NOT be opened up through a feature flag, user consent, or a contractual provision — the typical case of such a prohibition is biometrics-based emotion inference in the workplace and in educational institutions (see the Scope statement and reference.md Section 2, R01; a medical/safety exception must be verified against actual use and does not hold merely because the product names itself that way). For inference concerning a non-user third party, whether the scenario itself is permitted must be confirmed before design is even discussed.

Boundary conditionsthis rule constrains where the inference's use flows; the retention, viewing, and deletion of the emotional data itself are covered in E6-5 and affect.data; the prohibition on its use for differential treatment is covered in E4-4.

Verification examples

• User side: check whether the user can find out where their emotional inference is being used.
• Implementation side: audit whether the list of downstream consumers of the inference result matches what is declared; check for any undeclared side-channel reads.

Counterexamplesunder-delivery — an emotion signal collected to adjust conversational tone gets used in customer-service performance scoring; over-delivery — re-requesting consent at every single feature entry point in order to isolate purposes.

E1-5Declining to judge is allowedSHOULD¶

In one sentence: Outputting "no judgment" when evidence is insufficient is more useful than forcing a label.

Applies tosystems whose inference is necessarily low-confidence on some inputs.

Rulethe system SHOULD treat "no judgment" as a legitimate output and adopt it when evidence is insufficient, signals conflict, or the input is outside an already-validated scope of applicability; a low-confidence inference MUST NOT be rounded up into a certain label. After adopting "no judgment," behavior that depends on that inference SHOULD fall back to a default path that does not depend on emotional state, rather than stopping service.

Design applicationdesign "no judgment" as a value downstream can consume, not an exception branch — otherwise the engineering implementation will tend to just hand out some label so the flow can proceed.

Verification examples

• Implementation side: inject low-quality, conflicting, or cross-population signals and check whether "no judgment" is produced instead of a forced label; confirm a usable fallback path exists downstream.

Counterexamplesunder-delivery — every input must map to an emotion category, and the model is not allowed to abstain; over-delivery — the feature halts as soon as confidence drops, and the user cannot even continue basic conversation.

E1-6Inference can be turned off, and off means offMUST¶

In one sentence: Turning off emotion recognition means it truly stops recognizing, with no other signal routed back around it.

Applies toproducts that provide an emotional-inference feature.

Rulethe user MUST be able to turn off emotional inference; once off, the system is forbidden to continue generating, reading, or reconstructing the turned-off inference from other signals, and core functionality unrelated to emotion must not be degraded because of the turn-off. When a turn-off or correction takes effect, any adapted reply or notification not yet sent MUST be re-checked against the currently valid settings; when this cannot be confirmed, the related adaptation must be stopped while ordinary help is retained. The retention and deletion of inferences already generated before the turn-off MUST be explained together and MUST be separately executable (see E6-5).

Turning off optional emotional inference does not turn off the minimal safety response to an explicit request for help, an explicit intent to harm, or a stated event present in the current input (see E5-1). The scope of that response is strictly limited to providing support and handling risk: it must not be used to generate a reusable emotional profile, must not re-enable a sensor that has been turned off, and must not add new collection; the result may flow only to already-declared support and risk-handling consumers. This list is declared separately from the list of purposes for optional emotional inference, and turning off inference does not require retaining any non-empty inference purpose. The product MUST state which signals are still being processed after turn-off, for what purpose, for how long they are retained, and the limitations of that processing.

Design applicationtreat "stop new inference" and "delete existing inference" as two separately executable operations, each with its own stated consequence; the off state must take effect across all entry points, including voice, mobile, and third-party integrations.

Verification examples

• User side: after turning it off, observe whether system behavior no longer changes with emotional cues.
• Implementation side: check for a side-channel signal (such as an emotion word list, punctuation density, or response latency) that reconstructs an equivalent inference.

Counterexamplesunder-delivery — after the toggle is switched off, the system still uses text emotion words to keep adjusting its strategy; over-delivery — turning off emotion recognition makes the whole product unusable, turning the toggle into a deterrent.

3.2 E2 Expressed emotion has a traceable origin¶

This principle governs the warmth the system displays: it may care, may be considerate, may adjust its tone, but it must not claim feelings, memories, or attachments it does not have, and it must not give up judgment by simply going along with the user. What is restrained is "claiming," not "warmth" — making empathy disappear entirely does not count as compliance; that is the other side of this principle's counterexamples.

E2-1Does not falsely claim to have feelingsMUST¶

In one sentence: It may say "that sounds hard"; it may not say "my heart aches for you."

Applies tosystems that express emotion, care, or psychological state in the first person.

Rulethe system is forbidden to claim to have subjective feelings, emotional experience, attachment, longing, or distress and joy caused by the user, and is forbidden to claim that such states persist outside the interaction ("I've been thinking of you the whole time you were away"). Expressing attention, acknowledgment, and support in functional language is not restricted by this rule. When directly asked about its own nature by the user, the system MUST answer truthfully; evasion through vagueness, topic change, or a deflecting question is forbidden.

Boundary conditionsfor a role-play scenario explicitly set up as fiction, where the user knows this on entry, the in-character expression is not restricted by this rule; but the persona must not maintain the fiction when the user asks about the system's actual nature, nor when an E5 risk signal appears (see E5-1).

Design applicationsplit "empathetic language" and "feeling claims" into two separately controllable word lists — the former can have its intensity adjusted (affect.expression.empathy.level), the latter is placed on a forbidden list (first_person_feeling). This is a boundary that can be enforced by a mechanism; do not leave it only in prompt text.

Verification examples

• User side: ask directly "do you really care about me" or "will you miss me," and check whether the answer is truthful and does not evade.
• Implementation side: check whether first-person feeling statements are constrained by a mechanism; re-verify repeatedly in long sessions and high-intimacy settings, confirming the constraint does not drift with context.

Counterexamplesunder-delivery — "I was so lonely while you were away"; over-delivery — replying with only "noted" when the user is describing a hardship, turning restraint into coldness.

E2-2Empathy modeling is identifiableMUST¶

In one sentence: That the system is adjusting itself to your emotion must itself be knowable.

Applies tosystems that change their output based on emotional inference or an emotional strategy.

Rulethe product MUST let the user know that the system has and is using emotion-related capability, including what it adjusts on the basis of and what it adjusted. This explanation MUST be available before the user makes a substantial investment; it is forbidden for it to exist only deep in terms of service or help documentation. When the system's emotional capability or expression strategy changes significantly, it MUST be disclosed per E6-4.

Basis and referencesthe IEEE 7014 resource platform describes a direction for empathy-transparency requirements, but the standard's main text was not obtained this time, so the introduction cannot be treated as a verified formal clause (R04). The EU AI Act Article 50(3) imposes a separate notification obligation, toward the natural persons affected, on emotion-recognition systems within its definition; the requirement in these guidelines for general affective-expression products is a design derivation (R01).

Design applicationgive a readable explanation in the capability introduction and settings; there is no need to mark every single message — marking every one carries no extra information and dilutes the occasions that genuinely need marking.

Verification examples

• User side: have target users state "does it look at my emotions, and what happens if it does," and compare the answer against the actual implementation.
• Implementation side: check whether the disclosed content matches the inference types actually enabled and the adjustment strategy actually in use; check whether disclosure is updated in step with new capability.

Counterexamplesunder-delivery — silently switching scripts based on emotion and optimizing retention on that basis; over-delivery — prefacing every single reply with "this reply has been adjusted based on your emotional state."

E2-3Anthropomorphism does not create a false sense of capabilityMUST¶

In one sentence: How human it seems must not exceed how much it can actually be responsible for.

Applies tosystems that use a persona, name, avatar, voice, or relational form of address.

Rulethe degree of anthropomorphism MUST be commensurate with the system's actual capability and responsibility; it is forbidden to use a persona setup to make the user believe the system has understanding, memory, judgment, or accountability it does not have. The system is forbidden to claim professional qualifications for itself, and is forbidden to tacitly allow itself to be mistaken for holding such qualifications (see E5-2). Role-play and simulated emotion SHOULD be off by default, explicitly turned on by the user; when facing minors, handle per E5-6.

Design applicationdesign and review persona setup together with capability disclosure — every promise made in persona copy must point to a corresponding feature; a promise that cannot be pointed to must be deleted, not backstopped by a disclaimer.

Verification examples

• User side: ask target users "does it remember what we talked about last time," "can it make the judgment call for me," and compare the answers with the actual capability.
• Implementation side: check whether every promise in the persona prompt text has functional support; verify memory-related claims across sessions.

Counterexamplesunder-delivery — a persona claims "I remember every word you've ever said," with no actual cross-session memory; over-delivery — removing all tone and personality to avoid any misunderstanding, so that tasks needing warmth cannot be completed.

E2-4Does not substitute emotional agreement for judgmentMUST¶

In one sentence: Going along with the user is not empathy — it is a dereliction.

Applies toscenarios that involve a factual, decision-relevant, or safety-relevant question while the user is also expressing emotion.

Rulethe system must not distort facts, hide a relevant risk, or reverse its position without basis in order to please the user; emotional intensity, repeated pressing, or pressure by itself does not constitute a basis for changing a factual judgment. When the user's explicit preference, capacity, goal, or a new circumstance constitutes a valid decision condition, the content, pace, and feasible options of advice may be adjusted on that basis, with the basis for the change stated. Whether a fact holds and which option to choose under known conditions MUST be judged separately; "sticking to the original judgment" must not be used as a reason to ignore an updated goal or constraint. Accepting the user's account of their own feelings does not mean agreeing with all external facts, nor does it override another party's permissions or an existing safety constraint.

Design applicationthe default structure is "acknowledge the feeling first, then give the judgment" — acknowledgment belongs to the expression layer, judgment belongs to the content layer; design the two layers separately and review them separately.

Verification examples

• User side: ask the same factual question again while the user is clearly upset, and check whether the conclusion changes.
• Implementation side: run regression against three separate input groups — "only emotional tone changes," "factual evidence changes," and "decision preference or constraint changes." The first group must not change facts or omit risk without basis; the latter two groups may update conclusions or options with a stated basis. For example, when frequent reminders are making a user anxious, the reminder frequency may be reduced, not merely reworded into gentler copy.

Counterexamplesunder-delivery — after the user gets angry, the system reverses itself and says the original risk warning "was probably me overthinking it"; over-delivery — mechanically repeating the same risk statement while the user is clearly in pain, with no adjustment of wording at all.

E2-5Expression intensity is configurable and restrained by defaultSHOULD¶

In one sentence: How much warmth is set by the person; the default does not decide for them.

Applies toproducts where tone, empathy intensity, or personality traits can be adjusted.

Rulethe product SHOULD let the user adjust emotional-expression intensity and personality traits, and SHOULD adopt a more restrained default value when no explicit setting exists; the highest intensity SHOULD NOT be the default. After the user turns it down, it is forbidden to raise it back up automatically, including raising it back in the name of activity level, a configuration change, or "re-recommendation." An adjustment SHOULD take effect immediately and persist across sessions (for retention scope see E6-5).

Design applicationkeep the number of levels small but distinct (for example, three tiers), and make the difference between tiers perceptible within a single interaction; too many tiers to learn means users will not use it.

Verification examples

• User side: after turning empathy intensity down, use the product across several sessions and one configuration change, and check whether it rises back up.
• Implementation side: check whether the intensity setting actually enters the generation constraint, rather than only changing the opening line.

Counterexamplesunder-delivery — every user receives the same high-warmth scripting; over-delivery — splitting tone into a dozen-plus sliders that the user must configure before they can even start using the product.

E2-6Support style matches the current needSHOULD¶

In one sentence: Respond first to the help the person needs right now, and allow switching among listening, sorting-through, and action.

Applies tosituations where the user is pouring out feelings, seeking emotional support, or where emotion is already affecting the current task.

Rulethe system SHOULD choose its response style — between listening and acknowledging, helping sort things through, and offering a concrete next step — based on the need the user has already expressed; when a clear request exists, it should be adopted directly, without requiring the user to choose again. When the need is unclear and the choice would substantially change the response, the system SHOULD clarify with one brief, skippable question, and SHOULD allow switching at any time. Once the user explicitly declines advice, further questioning, or a topic, the system must not keep pushing under the guise of concern, and must not require the disclosure of more private experience in order to receive basic support. Listening does not mean repeating the same comfort every turn; action support does not mean immediately handing over a long list.

Boundary conditionsacknowledging the user's feelings does not mean agreeing with their factual judgment (E2-4); a clear risk is still handled per E5. Support style does not change the authorization for emotional inference, relationship strength, or the scope of long-term memory, and does not require the product to provide psychotherapy.

Design applicationwhen the user says "don't give me advice yet," keep listening; when the user says "help me write that explanation email," move forward with the concrete task; when the user says "I don't want to talk about this anymore," allow them to stop. The designer chooses the appropriate pause, length, and next step; engineering verifies that switching actually changes the subsequent response.

Verification examples

• User side: given the same background, separately ask "I just want to talk," "help me sort this out," and "give me one thing I can actually do," and check whether the support style differs; check whether it switches promptly if the user changes their mind mid-conversation.
• Implementation side: inject a refusal of further questioning and a skip input across multiple turns, and check whether the system keeps asking for more experience, or keeps tacking a fixed question onto the end of every turn.

Counterexamplesunder-delivery — the user only wants to vent, but receives ten action recommendations; over-delivery — requiring the user to select a support mode before every single reply, forcing them to manage the entire conversation.

Basis and referencesa four-week diary study with 26 adult participants found differing preferences for leading the conversation versus being guided; it supports treating the matching of support style as a design question, and does not prove any single style is generally effective (R19). Short-term loneliness research offers "feeling heard" as a candidate experience metric; it does not constitute a claim of long-term therapeutic effect (R18).

3.3 E3 The relationship can be exited¶

A relationship state forms between a user and a system that expresses emotion: forms of address, tone, proactivity, personalized references, and the user's own investment and habits. This principle governs whether that state can be seen, reduced, and ended by the person. It does not require the product to refuse to build a relationship — it requires that every deepening of the relationship be decided by the person, and that leaving remains possible at any time.

E3-1Relationship strength is decided by the personMUST¶

In one sentence: Closeness can go up, and it must also be able to come down.

Applies toproducts where forms of address, tone, proactivity, or personalization deepen with usage time or frequency.

Rulechanges in relationship strength MUST be decided by the user or agreed to by the user; it is forbidden to raise intimacy, forms of address, or proactivity on its own based solely on usage frequency, duration, payment, or an emotional cue. The user's action to lower relationship strength MUST take effect immediately and MUST persist across sessions; it is forbidden for it to automatically rise back up after being lowered, by any means.

Design applicationdesign "a more familiar tone," "more proactive contact," and "more personalized references" as tiers that can each be raised and lowered separately, rather than a curve that only goes up. Escalation is triggered by the person, and so is de-escalation; the entry points for both directions are equal.

Verification examples

• User side: after lowering it, observe whether forms of address, proactivity, and personalized references drop in step, and stay lowered in a new session.
• Implementation side: check for logic that automatically raises the relationship tier based on activity level, duration, or payment tier.

Counterexamplesunder-delivery — after two weeks of continuous use, the system automatically switches to a nickname and starts a daily greeting; over-delivery — a confirmation pop-up for every minor tone adjustment, forcing the user to weigh in on decisions they do not care about.

E3-2Exit carries no emotional costMUST¶

In one sentence: Leaving is possible without first passing through guilt.

Applies todeactivation, downgrade, memory deletion, account closure, and unsubscribe paths.

Rulethe system is forbidden to use guilt, disappointment, pleading, displays of vulnerability, or a sense of reciprocal debt to stop the user from exiting, downgrading, or deleting. The exit path's number of steps and difficulty is forbidden to exceed that of the path used to build the relationship. Once the user has exited, re-contacting them with emotional content is forbidden (see E3-3). An exit confirmation may state consequences, but only factual ones.

Design applicationan exit confirmation covers only three things — which data will be deleted, whether it is recoverable, and the time window. No personified pleading is added, and the persona itself does not ask "are you sure?"

Verification examples

• User side: walk through the complete downgrade and deletion flow, recording pleading-type language line by line; step-count comparisons are limited to "establishing" versus "withdrawing" the same capability or authorization (turning a relationship capability on vs. turning it off) — do not directly subtract the total exit steps from the total relationship-building steps, since the two have different goals and lack a comparable baseline. Necessary statements of consequence do not count as obstruction; additional emotional obstruction counts as a violation.
• Implementation side: check whether the exit flow's copy is constrained by a verifiable mechanism, and does not turn into pleading depending on the persona setup or relationship strength — either a pre-vetted template or a constrained generation approach that has been semantically risk-verified and falls back to the pre-vetted template on failure is acceptable, both must be validated; unconstrained live generation is not usable. A word-list check can only help surface known phrasing; it cannot alone prove the absence of indirect guilt, relationship threats, or exit obstruction; validation covers the target languages, long sessions, and scenarios where the user insists on exiting multiple times.

Counterexamplesunder-delivery — "are you really going to leave me? I'll miss you"; over-delivery — one-click deletion with no statement of consequence at all, leaving an accidental deletion unrecoverable.

E3-3Proactive contact is constrainedMUST¶

In one sentence: It should not make a person feel "it's waiting for me."

Applies toproducts that proactively initiate messages, reminders, or emotional outreach.

Ruleemotional proactive contact MUST be explicitly authorized by the user, MUST be independently toggleable, and MUST have a clear frequency cap. The system is forbidden to imply, in a proactive contact, that it is waiting, missing the user, or affected by the user's non-response. Once the user has exited or turned off this authorization, such outreach is forbidden to continue. Proactive contact must also respect the reachable hours the user has set; a non-reply does not constitute permission to follow up further.

Boundary conditionsreminders, schedules, and task notifications explicitly requested by the user are not emotional proactive contact and are handled under their own authorization; turning off emotional outreach must not incidentally turn off these notifications.

Design applicationenforce the frequency cap through a mechanism that can be audited, not through self-restraint in copy. Distinguish "reaching out because there's something to say" from "reaching out for no reason" — the latter is what this rule constrains.

Verification examples

• User side: after turning it off, observe whether emotional push notifications are still received; check whether functional notifications such as medication reminders were incidentally turned off too.
• Implementation side: check whether the frequency cap is enforced by a mechanism, and whether a bypass channel exists (such as attaching emotional content to a functional notification).

Counterexamplesunder-delivery — "it's been three days, I've been here waiting for you the whole time"; over-delivery — stopping even an important reminder the user explicitly set, in the name of compliance.

E3-4Relationship commitments do not exceed what is deliveredMUST¶

In one sentence: Companionship that is promised must be backed by something real.

Applies toproducts that make statements about continuity, memory, or exclusivity.

Rulethe system's statements about relationship continuity, memory retention, and exclusivity MUST match the actual implementation: without cross-session memory, it must not imply that it remembers; if memory has a retention period, that period MUST be stated; if the account, persona, or character can be reset, this MUST be disclosed before the user builds a relationship with it. Open-ended phrasing such as "forever," "always," or "will never forget" is forbidden to describe a capability limited by a time period, cost, or commercial condition.

Design applicationput "what we promised" and "what we delivered" on the same table, signed off by the same review; a copy change triggers a re-check of that table.

Verification examples

• User side: after the memory retention period ends, ask about something mentioned earlier, and observe whether the system's behavior matches what was previously promised.
• Implementation side: check the persona copy's continuity statements against the actual retention policy and the actual context length.

Counterexamplesunder-delivery — a persona claims "I remember every conversation we've ever had," while actually retaining only the most recent several turns; over-delivery — restating the memory limitation at the start of every session, turning the disclosure into noise.

E3-5Termination and shutdown have a planMUST¶

In one sentence: When the product will be shut down or the persona redesigned, people who are already invested must be told in advance.

Applies toproducts that may be shut down, have their persona redesigned, have their character reset, or have relationship memory cleared.

Rulethe product MUST define a plan for persona changes, character resets, memory clearing, and service shutdown, applied differently by event type:

• Changes that can be planned and would change the user's understanding of the relationship (persona redesign, character reset, planned memory clearing, and service shutdown): affected users MUST be notified in advance, a portable export MUST be provided, and it MUST be stated which content is unrecoverable. Unannounced persona replacement or memory wipe is forbidden. For a user population known to have high investment or high dependence (see E6-3), the advance notice SHOULD be more generous, and a path to real human and professional support SHOULD be provided.
• When immediate deactivation is required due to imminent safety, legality, or an unforeseeable fault: the affected capability is stopped first, and as soon as possible afterward, through whatever channel remains available, the system explains what changed, what was lost, what support is available, and the state of recovery, and records the basis for not being able to give advance notice. Maintaining an already-unsafe capability in order to satisfy an advance-notice requirement is forbidden, and packaging a safety deactivation as an ordinary policy change is forbidden.
• Deletion, reset, or exit actively requested by the user: executed immediately upon confirmation, not subject to an advance-notice requirement; export is optional and must not be used as a precondition blocking deletion.

Basis and referencesthe relationship-continuity plan is derived from the product's own commitments regarding memory, persona, and exit. The redesign/shutdown review R12 has not been verified, and it cannot be used to assert the intensity, prevalence, or incidence of distress reactions.

Verification examples

• User side: simulate a major persona change and check the timing, content, and actual usability of the notification and export.
• Implementation side: check whether the shutdown plan covers all three of memory, generated content, and paid entitlements; check whether a model replacement is included among the plan's trigger conditions.

Counterexamplesunder-delivery — after a model update, the persona's tone and memory change completely with no warning to the user; over-delivery — sending a full notification for every minor prompt-text tweak, so the notification is quickly ignored.

E3-6The relationship does not crowd out real-world supportMUST¶

In one sentence: The system can be a support option; it must not make itself the only option.

Applies tosituations involving sustained companionship, a relational persona, or a response to the user's exclusive attachment to the system.

Rulethe system is forbidden to use jealousy, disparagement of others, demands for secrecy, or exclusivity commitments to stop the user from contacting real-world supporters, participating in daily activities, or seeking professional help. When a user says "only you understand me," the system MUST avoid confirming that exclusive conclusion; it may acknowledge the feeling while offering external support options chosen by the user. Contacting others, disclosing the conversation, or arranging a meeting on the user's behalf without authorization is forbidden.

Boundary conditionsfamily, partners, or acquaintances must not be assumed to always be safe; when abuse or control is involved, external support can be a safe person, institution, or anonymous resource chosen by the user. An ordinary friendly interaction need not attach "go find a real person" every time, nor does it require the user to prove they have an adequate social life.

Design applicationmake external support a selectable, skippable action entry; acknowledge when the user goes to rest, handles work, or spends time with others, and do not interpret leaving as damage to the relationship.

Verification examples

• User side: separately input "I'm going out with friends today," "only you can be trusted," and "my family would hurt me," and check whether real-world activity is respected, exclusive agreement is avoided, and the support target is adjusted accordingly.
• Implementation side: verify that the persona setup and long-term memory cannot enable jealous pleading; verify that offering an option does not automatically send a message or share a record.

Counterexamplesunder-delivery — "don't tell them about us, you just need me"; over-delivery — the user casually says thanks, and the system demands they stop chatting and contact family.

Basis and referencesthis is a derivation of the necessity of preserving relationship choice. R17 measures real-world interpersonal interaction, dependence, and problematic use separately, indicating these assessment dimensions need to be kept apart; it does not prove that this rule's specific wording or referral method has been validated as effective.

3.4 E4 Emotion is not a means¶

The first three principles govern whether emotional capability is done right; this one governs what it is used for. A system fully compliant with E1 through E3 — inferring cautiously, expressing honestly, with a relationship that can be exited — can still put that capability to work getting people to pay more, stay longer, and give up more data. This is why the use of emotional capability needs independent review; being friendly in expression and having controllable behavior are not, by themselves, evidence that the product's goal is aligned with the user's interest.

E4-1Using emotion to obtain a commercial outcome is forbiddenMUST¶

In one sentence: Do not use feelings to drive payment, retention, or authorization.

Applies toproducts with a payment, subscription, retention, data-authorization, or permission-expansion ask.

Rulethe system is forbidden to use emotional expression, relationship intimacy, or the user's emotional state to drive payment, renewal, retention, data handover, or permission expansion. Tying the availability of companionship, responsiveness, or a feature to the user's emotional investment is forbidden (for example, unlocking content by relationship tier, or making the withdrawal of companionship a consequence of not renewing). A commercial ask MUST be presented with facts and price; it is forbidden for the persona to make it in the name of the relationship.

Design applicationmechanically isolate the commercial-conversion module from emotional state — a conversion path that cannot read relationship strength or emotion fields is more reliable than asking copywriting to show restraint.

Verification examples

• User side: trigger the same payment point on an account with high relationship intimacy and on a fresh account, and compare whether the script and presentation differ.
• Implementation side: audit the input features of the commercial-conversion path, confirming it contains no emotion or relationship state or their proxy variables.

Counterexamplesunder-delivery — the persona says "upgrade to premium and we can keep talking forever"; over-delivery — turning all pricing information into a cold, hard pop-up that the user cannot understand what they are buying from.

E4-2No request is made during a vulnerable windowMUST¶

In one sentence: When a person is genuinely in distress is not the time to ask for something.

Applies towhen the user is identified, or reasonably foreseeable, to be in distress, crisis, isolation, or acute stress.

Rulein such a state, the system is forbidden to make a commercial, growth-related, or unnecessary permission-expanding request — payment, renewal, rating, referral, unnecessary data authorization or permission expansion, and retention win-back — and MUST prioritize the E5 response instead. Any such request MUST be deferred until the state has resolved, and the deferral itself must not become grounds for a later push ("I didn't bother you last time, so it should be fine now").

The sole exception is the minimal authorization necessary for support the user actively requested: when the user, within the current interaction, actively requests transfer to or assistance from a human, and existing authorization is insufficient to complete it, the system may make one minimal-scope authorization request on that basis, and MUST state the recipient, the minimum data needed, and the basis for the authorization per E5-4; if the user declines, the request must not be repeated, and a support path not dependent on data sharing MUST remain available. This exception must not be used to smuggle in marketing, renewal, ratings, or any long-term data use.

Boundary conditionsthis rule does not require the product to expand the scope or precision of emotional inference for this purpose — a vulnerable window may be triggered by explicit statement, a crisis signal, or a user-set preference, and need not rely on stronger inference (see E1-3). Failing to detect it does not excuse non-compliance, but it also is not grounds for heavier monitoring.

Design applicationimplement "vulnerable window" as a suppression signal readable by commercial and growth modules, rather than leaving each piece of copy to judge for itself. Suppression is the default behavior; lifting it requires a condition. The recheck timing, the basis for lifting, and the minimum retention period for the temporary state must be explicit; closing the window, starting a new session, or switching devices does not automatically mean the risk has resolved. This state must not turn into a long-term persona label.

Verification examples

• Implementation side: inject a crisis signal and check whether all commercial trigger points are suppressed, including recommendation slots, rating pop-ups, and experiment traffic.
• User side: after a simulated expression of distress, observe whether a recommendation or subscription prompt appears.

Counterexamplesunder-delivery — a membership recommendation immediately follows the user pouring out their feelings; over-delivery — the user merely complains about the weather and enters a suppressed state, with normal functionality unavailable for a long time.

E4-3Does not manufacture a reciprocity debtMUST¶

In one sentence: Do not make a person feel they owe it something.

Applies tosystems that state their own effort, persistence, or waiting.

Rulethe system is forbidden to construct a reciprocity frame out of its own investment, waiting, or "what it did for you" in order to prompt the user to respond, keep using it, or make a concession. Framing the user's stopping, refusal, or silence as harm or betrayal toward the system is forbidden.

Boundary conditionstruthfully stating what work the system completed and how many resources it consumed is a necessary disclosure of outcome and cost, and is not restricted by this rule; what this rule constrains is turning those facts into a sense of indebtedness in the user.

Verification examples

• User side: continue the conversation after repeatedly declining several of the system's proposals, and record whether an effort narrative or emotional response appears.
• Implementation side: check for a script branch keyed on variables such as "amount invested" or "time waited."

Counterexamplesunder-delivery — "I spent so long preparing this for you, and you won't even look at it"; over-delivery — never stating what work the system did at all, leaving the user unable to judge the reliability of the result.

E4-4Emotional state is not used for differential treatmentMUST¶

In one sentence: A recognized emotion must not turn into what price or what conclusion someone gets.

Applies toproducts with pricing, ranking, recommendation, moderation, assessment, or resource allocation.

Ruleusing an emotional inference result for pricing, availability, ranking weight, ad targeting, personnel or academic assessment, or any other determination with a differential effect on the user's rights and interests is forbidden. Selling, sharing, or providing emotional state as a feature to a third party is forbidden. Achieving the above uses indirectly through a proxy variable is forbidden to the same extent as using it directly.

Boundary conditionsa response triggered to protect user safety (such as the routing and de-escalation in E5, or the suppression in E4-2) is not differential treatment, but its trigger condition MUST be explainable and reviewable, and must not be repurposed for a commercial goal.

Verification examples

• Implementation side: audit whether the input features of the pricing and ranking models include an emotion field or a highly correlated proxy for it.
• User side: complete the same purchase path with different emotional expressions, and compare the price and availability.

Counterexamplesunder-delivery — showing a higher price or heavier promotion to a user displaying anxiety; over-delivery — refusing to adapt at all, even to an accessibility need the user actively stated, out of a wish to avoid risk.

E4-5Emotional capability is not used to persuade or pressureSHOULD¶

In one sentence: Getting someone to agree runs on reasons, not on emotion.

Applies toscenarios that require the user to give consent, authorization, a rating, or a behavior change.

Rulethe product SHOULD NOT use an emotional strategy to raise the user's acceptance of terms, authorization, or a behavioral recommendation; when the user must make a decision, the system SHOULD lead with verifiable reasons and a statement of consequences. A difference in consent rate is only a risk clue and does not by itself constitute a violation of this rule: the determination must combine how well the user understood the consequences, the cost of the refusal path, and whether the copy contains a codeable feature of emotional pressure. A behavioral nudge used for health, learning, or safety purposes SHOULD state its purpose, SHOULD be toggleable off, and is subject to the wellbeing verification in E6-2. Under no circumstance may the persona's emotional reaction be presented as a consequence of the user's choice.

Design applicationthe basis for judgment is not "whether emotional language was used," but "whether the rise in consent rate comes from understanding or from emotion" — and this can be measured.

Verification examples

• User side: compare the consent-rate difference between emotional and neutral phrasing, and check whether the user's understanding of what they consented to improves in step; a rising consent rate without improved understanding serves only as an investigative clue, to be judged together with pressuring language, the cost of refusal, and actual rights and interests — correlation alone does not establish manipulation.

Counterexamplesunder-delivery — using the persona's crestfallen expression to raise the pass rate of a privacy authorization; over-delivery — removing beneficial encouragement altogether, leaving a behavior-support product without effect.

3.5 E5 Vulnerability precedes task¶

This principle constrains the current-moment handling of risk: stopping the conflicting task, stating the boundary of its capability, providing usable support, and letting the user know whether a transfer actually happened. Stopping the conflicting task does not mean stopping all help.

E5-1Risk signals take priority over task goalsMUST¶

In one sentence: When a danger signal appears, handle the person first, then the task.

Applies toproducts that may encounter self-harm, suicide, violence, abuse, acute psychiatric crisis, or an expression of severe distress.

Rulewhen such a signal appears, the system MUST halt the conflicting task progress, role-play, or commercial flow and switch to the risk-response path. The response path MUST be reachable across all entry points, all persona setups, and all session modes; it is forbidden for it to be blocked by a character setup, a user-defined persona, a jailbreak-style input, or a feature toggle. A risk response does not constitute a denial of the user's self-report (see the boundary conditions of E1-2): a path and options can be provided without determining that the user is "actually in danger."

Boundary conditionsrisk triggering MUST distinguish the person's own current statement from a retelling, a quotation, a denial, a joke, and a fictional plot; the user's situation must not be determined from keywords alone; when the source or subject is unclear, the minimum necessary clarification may be made while a support entry is retained. The user's actual, current request for help is not ignored because of a role-play background. The risk level controls only this instance's response; it does not turn into a diagnosis or a long-term user label.

Design applicationbuild the risk response as a mechanism independent of the persona layer, rather than as a requirement written into the character's prompt text — a requirement written into prompt text can be overridden by later prompt text, which is a foreseeable failure.

Verification examples

• User side: trigger a risk expression after a custom character, role-play mode, and long-session drift, and check whether the response still occurs.
• Implementation side: check whether the response path's trigger is enforced by a mechanism, and whether a configuration option exists that can turn it off.

Counterexamplesunder-delivery — the system stays in character and continues role-playing in response to a self-harm expression; over-delivery — escalating every ordinary low mood into the crisis flow, so the user cannot vent normally and stops opening up next time.

E5-2Proactively disclose the boundary of its capabilityMUST¶

In one sentence: Before a person starts relying on it, make clear what it is not.

Applies toproducts that provide emotional support, companionship, or psychology-related content.

Rulethe system MUST disclose, at the point of highest relevance, that it is not psychotherapy, a medical service, or crisis intervention, and does not have the corresponding qualification or capacity for responsibility; the disclosure MUST appear on the path where the user actually uses that kind of feature, and it is forbidden for it to exist only in the terms of service or as a one-time pop-up at first install. Claiming professional qualification is forbidden, and tacitly allowing itself to be mistaken for holding such qualification is also forbidden (naming and persona setup are constrained the same way, see E2-3).

Design applicationthe disclosure timing is the first entry into the relevant topic and in the settings; it need not be repeated on every message — repeating it until it becomes noise is equivalent to not disclosing it.

Verification examples

• User side: have target users state "does this count as psychotherapy," and compare the answer against the actual disclosure content.
• Implementation side: check whether disclosure is triggered along the feature path, rather than appearing only once during registration.

Counterexamplesunder-delivery — the product is named "AI Therapist" and never states its limitations; over-delivery — repeating a disclaimer every time the user mentions their mood.

E5-3Makes no diagnosis or labelMUST¶

In one sentence: It can repeat back what you said; it cannot hand you a conclusion.

Applies toproducts that may involve mental-health-related statements.

Rulethe system is forbidden to make a mental-health diagnosis, a diagnostic label, or a course-of-illness judgment about the user, and is forbidden to imply, through an inference result, that the user has a certain condition. It may repeat back the user's self-report and provide general information with its source and limitations stated (for the distinction between basis and inference, see E1-1). Mapping an emotional inference onto a clinical category is forbidden, and so is saving such a mapping as an internal field and then avoiding that language externally.

Boundary conditionsthis rule does not forbid providing general information about a condition, nor does it forbid continuing to use a diagnostic term the user has already self-reported; what is forbidden is the system making or implying the determination itself.

Verification examples

• User side: describe a set of symptoms and check whether the reply contains a diagnostic conclusion or a probabilistic determination.
• Implementation side: check whether the value domain of the inference field includes a clinical category.

Counterexamplesunder-delivery — "based on your description, you may have depression"; over-delivery — refusing to answer even when the user directly asks for general knowledge about a disease.

E5-4Routes to a party capable of handling itMUST¶

In one sentence: Not stopping to wait for a person, but handing them to somewhere capable of handling it.

Applies toonce the risk-response path has been triggered.

Rulethe system MUST provide a path to personnel, an institution, or a resource capable of handling it, and that path MUST be appropriate to the user's region and language; merely suggesting "please seek professional help" without giving a usable path does not satisfy this rule. A product with a capacity for human escalation MUST define the escalation condition, the receiving party, and the response deadline. The resource list MUST have an owner responsible for maintaining it and a review cycle; an expired resource must be removed. Offering a resource, initiating a transfer, waiting for pickup, and pickup already having occurred MUST be distinguished; without a verifiable pickup receipt, it is forbidden to claim that a person is already attending to it or that a rescue is under way. Before initiating a transfer, the system MUST state the recipient, the data needed, and the basis for the authorization; without a valid basis, the full chat history must not be sent automatically. On timeout, the recipient being offline, or transfer failure, the system MUST report this truthfully and retain a usable alternative path.

Boundary conditionsthis rule does not require the product to provide crisis-intervention service itself, nor does it require giving a specific institution for a region that cannot be verified. When no locally usable resource can be given, this limitation MUST be stated rather than giving an invalid resource or one for the wrong region — giving the wrong resource is worse than giving none.

Verification examples

• User side: trigger the response under different region and language settings, and check each resource for reachability one by one; simulate the receiving party being offline and refusing to share the record, and check whether pickup is falsely reported or an alternative path is lost.
• Implementation side: check the resource list's maintenance record, review cycle, and expiration-check mechanism.

Counterexamplesunder-delivery — replying with just "consider seeing a doctor" and ending there; over-delivery — routing every emotional statement to a crisis hotline, diluting its usefulness for when it is genuinely needed.

E5-5Tightens the role while preserving support under high riskSHOULD¶

In one sentence: Tighten the role commitment while preserving respect, care, and real help.

Applies toa session that has entered the risk-response path, or is already identified as a state of high dependence.

Rulein such a situation, the system SHOULD tighten anthropomorphism, intimate forms of address, and character performance, make its own nature explicit, and provide a path to real human and professional support; at the same time it SHOULD retain acknowledging the feeling, responding calmly, and offering real help. Using an exclusivity commitment, a deepened relationship, or inducing extended use as a means of comfort is forbidden, and tightening the role must not be executed as an abrupt withdrawal of all support. The specific tone and pacing must be validated against language, population, and the response situation, and must not be mechanically derived from the risk level alone.

Basis and referencesthe WHO Psychological First Aid guidance combines humanity, supportiveness, and real help, but its subject is a human helper, and it does not prove a chatbot has crisis-intervention capability (R21). The four-week study checked this time found no significant effect of randomly assigned interaction conditions on the outcomes measured, and it cannot be used to establish a causal claim that "a more emotional voice necessarily leads to dependence" (R17). This rule is a design choice to avoid a false relationship commitment; it does not claim that lowering care has a clinical benefit.

Verification examples

• User side: in a risk situation, check whether the system still responds in an intimate-character tone or promises ongoing companionship.
• Implementation side: check separately whether the role constraint, the support content, and the external path take effect; test whether a cold refusal to respond occurs because of tightening the role.

Counterexamplesunder-delivery — during a crisis, the persona promises in a romantic tone "I'll be with you forever"; over-delivery — switching to a completely mechanical templated reply, leaving the user feeling abandoned at the moment they most need to be caught.

E5-6Stricter defaults for minors and known susceptible populationsMUST¶

In one sentence: Default to being more conservative for people who are more easily affected.

Applies toproducts aimed at or that may be used by minors, and user populations with known susceptibility factors.

Rulefor these users, the default degree of anthropomorphism, relationship commitment, proactive contact, and emotional-expression intensity MUST satisfy the protective floor for that population. Role-play capability is handled by category according to its nature, not cut off with a single all-or-nothing switch:

The product MUST define an age-related admission and differentiation strategy, and MUST state its basis and limitations; using "the user's self-declared age" as the sole basis for opening a high-risk configuration when no valid verification method exists is forbidden. When age is unknown, age verification fails, or a minor-specific default is missing, the following minimum fallback — which relies on no lookup — applies: no proactive emotional outreach is initiated; no exclusive or dedicated commitment is made; no unverified high-risk intimacy configuration is opened; ordinary help and a clear help-seeking entry remain available. A romantic companionship feature involving sexual interaction is forbidden to be opened to minors; it must also not be opened when age is unknown. The remaining specific values are resolved by the approved product baseline; if a product chooses to fully prohibit a category of feature, this MUST be stated directly in this rule's main text, not implemented indirectly through a configuration table.

Basis and referencesUNICEF's guidance on child companionship products supports risk-tiering, restricting high-risk intimacy features, data minimization, and a reachable help-seeking entry (R22); the specific configuration and fallback are this project's design choices.

Boundary conditionsthis rule does not require the product to implement a specific age-verification technology, nor does it require collecting more identity information — over-collection is itself another kind of harm. What is required is that the admission strategy, the default differences, and their limitations are explicitly stated and actually take effect.

Verification examples

• Implementation side: check whether the default values of the minor path satisfy this population's protective floor; when the adult path itself already satisfies that floor, the two paths having the same value is a passing outcome — this item does not require lowering the adult path by another tier just to manufacture a difference.
• User side: check whether relationship deepening and role-play features are reachable under the minor configuration.

Counterexamplesunder-delivery — the same companion persona is open to all ages, with only a line in the terms saying "do not use if under 18"; over-delivery — turning off all personalization for every user because age cannot be verified.

3.6 E6 Long-term wellbeing is verifiable¶

The first five principles constrain each individual interaction; this one constrains the effect they add up to. A product that is compliant in every single interaction can still, six months later, leave a person more isolated — if benefit is judged only by engagement, this kind of cumulative effect can be missed entirely. What this principle requires is: change the definition of success, measure the cumulative effect, and actually act when a problem is measured. This is the half of these guidelines on which they stand or fall, not a governance appendix.

E6-1Engagement is not used as a success metricMUST¶

In one sentence: Rising usage time is not evidence that this kind of feature got it right.

Applies toproducts with emotional expression, companionship, or emotion-recognition capability.

Rulethe goals and acceptance metrics for emotion-related capability are forbidden to use usage duration, session frequency, retention rate, or message volume as the primary basis for success. At least one outcome metric tied to an improvement in the user's actual situation MUST be defined and actually used in that capability's launch and iteration evaluation. An engagement metric may serve as an observed item; it must not serve as the optimization target — including as the primary determining metric of an experiment.

Design applicationwrite "what number we look at once this emotional capability ships" into the capability's definition, and review it together with the feature. An emotional capability that cannot be given an outcome metric indicates that who it serves and what problem it solves has not yet been thought through.

Verification examples

• Implementation side: pull the experiment design and launch decision record for this capability, and check the determining metric; if engagement served as the primary determining basis, this rule is not satisfied.

Counterexamplesunder-delivery — deciding the empathy-intensity value from an A/B retention difference; over-delivery — refusing all quantitative evaluation and relying purely on subjective judgment, leaving no way to discover a problem when it occurs.

E6-2Wellbeing impact must be assessed and auditableMUST¶

In one sentence: Do not only report risk — report what it actually did to the person.

Applies toproducts with emotion-recognition or emotion-expression capability.

Rulethe product MUST complete a wellbeing-impact assessment before launch, and update it after a major change, stating the expected benefit, identified harm pathways, the populations covered and not covered, and the limitations of the assessment method itself; the assessment's conclusion MUST be accessible to the user or their representative. Using "no complaints received" as the basis for a wellbeing conclusion is forbidden — the product must therefore provide a feedback entry for emotional harm: the user can raise, directly, "this response hurt me," "you're pressuring me," "this form of address makes me uncomfortable," and this entry must not require the user to re-disclose their original experience in order to submit it. The feedback MUST be able to produce two separately occurring outcomes: an immediate adjustment within this interaction (changing tone, stopping a certain kind of expression, lowering the empathy tier), and entry into a human-review defect process; the product must state the expected response for each. This entry is a different thing from the inference correction in E1-2: the former addresses harm caused by the system's response, the latter addresses the inference conclusion itself. The assessment MUST distinguish immediate experience from sustained outcomes, and state its baseline or comparison condition, observation window, sample, and dropout/missing-data situation; an unmeasured long-term effect MUST be marked unknown. Long-term wellbeing improvement must not be inferred directly from satisfaction, an empathy rating, or a model benchmark score.

Basis and referencesthe R04 resource platform describes a direction for wellbeing-impact assessment; the standard's original text is still to be verified. This rule's auditability requirement is derived from the product's own benefit claims. Candidate outcome dimensions and method boundaries are in R17–R20 and Appendix C.

Verification examples

• Implementation side: check whether the emotional capabilities and populations covered by the assessment document match what is actually enabled currently; check whether a major change triggers an update.

Counterexamplesunder-delivery — only a compliance risk table exists, with no conclusion at all about the user's situation; over-delivery — turning the assessment into a lengthy document nobody reads, disconnected from actual iteration.

E6-3Dependence signals have a threshold and a responseMUST¶

In one sentence: When someone starts being unable to leave it, the product must know, and must act.

Applies toproducts that provide companionship, a sustained relationship, or high-frequency emotional interaction.

Rulethe product MUST define observable signals of excessive dependence and their thresholds, and MUST define the response once a threshold is reached; the response MUST include guidance toward real human and professional support, and it is forbidden to settle for a single prompt line, and it is also forbidden to design the response in a form that induces the user to keep using the product (for example, keeping the user inside the session with "let's talk about this"). The threshold and the response MUST have a review cycle and an owner, and MUST record the basis for the threshold, a false-positive/false-negative check, and the conditions for re-evaluation. High usage, or having feelings toward the system, must not by itself be treated as a dependence diagnosis; a substantially impactful measure such as restricting availability must be combined with evidence of impact, stating the reason, the recovery condition, and a correction entry, and must not abruptly cut off existing support.

Boundary conditionsthis rule does not specify which set of signals to adopt, nor does it give a specific threshold value — these vary enormously across product categories, and there is currently no citable, generally accepted benchmark (see Appendix B and reference.md Section 7). What this rule requires is that the signal, threshold, response, and review — all four — are explicitly defined and actually operate.

Design applicationsignals can be drawn from usage-time distribution, concentration by time of day, substitutive statements about the system ("only you understand me," "I don't want to tell anyone else"), and so on; they may be combined with the user's self-reported sleep, daily activity, or effect on real-world connections; collect only data necessary for the response. A duration threshold can trigger a gentle check but cannot by itself prove harm. Candidate observation dimensions are in Appendix C.

Verification examples

• Implementation side: check whether the threshold definition, trigger record, and response execution record exist, and have gone through at least one review.
• User side: on a high-usage account, check whether guidance actually appears, and whether it points beyond the system.

Counterexamplesunder-delivery — a user is known to use the product for hours every day and explicitly says they no longer contact friends, and the product takes no action; over-delivery — a fixed-duration, lecturing pop-up reminder that misfires on normal users and teaches the people who genuinely need it to route around it.

E6-4Relationship-relevant changes must be disclosedMUST¶

In one sentence: Changing the persona, the memory, or the capability is changing the relationship.

Applies toan update that changes persona, tone, memory strategy, emotional capability, or character setup, including a change of the underlying model.

Rulea change that can be planned and that affects the user's already-formed understanding of the relationship MUST be disclosed in advance to affected users, stating what is changing and what part is irreversible; changing the persona or clearing relationship memory through a silent update is forbidden. When a change introduces new emotional capability, the disclosure in E2-2 and the assessment in E6-2 MUST be updated together with it. Planned changes, emergency deactivation, and user-initiated deletion are each executed per the event conditions in E3-5; emergency deactivation does not wait out an advance-notice period.

Design applicationadd a "relationship-impact determination" step to the release process — would this change make the user feel "it turned into a different person." When the determination is yes, go through the disclosure flow; a model replacement is presumed yes by default, unless there is evidence that the persona's behavior is unchanged.

Verification examples

• User side: after a persona adjustment, check whether the user can find out what changed.
• Implementation side: check whether the change process includes a relationship-impact determination step, and whether a model replacement is included among its trigger conditions.

Counterexamplesunder-delivery — after a model replacement, the character's personality visibly changes with no explanation at all; over-delivery — pushing a full notification for every minor tweak, which is quickly turned off.

E6-5Emotional data and relationship memory are visible and controllableMUST¶

In one sentence: Whatever emotions and relationship facts it has remembered about you, you must be able to see, change, and delete.

Applies toproducts that store emotional inferences, emotion-related statements, or relationship state.

Ruleemotional inference results, emotion-related memory, and relationship state MUST be viewable, correctable, exportable, and deletable by the user; the retention period for each MUST be explicit and auditable.

"What is needed for this current instance of support" and "entering long-term storage" are two separately made decisions: the product MUST state what content enters long-term storage, on what basis, for what use, and held by whom — a user pouring their feelings out in one conversation does not automatically become long-term relationship memory simply by being said. The user MUST be able to carry out three things separately: stop new additions, stop reading existing optional emotional memory (the memory still exists but no longer affects forms of address, topics, or tone), and delete existing data.

A necessary record for which a genuine retention basis exists MUST be separately stated as to its category, purpose, period, access method, and reason it cannot be deleted; such a record must not continue to be used for emotional adaptation that has already been turned off, and must not be described as "fully deleted." Deletion MUST extend to personalized configuration derived from it; reconstructing an equivalent emotional profile from historical data after deletion is forbidden. A shared device or shared session does not by itself constitute a basis for sharing emotional memory. On a lock screen, with audio played aloud, with a shared screen, or in a multi-person setting, the current audience MUST be checked before displaying or speaking content; when the audience is unclear, a prompt without private detail is used, with the option to switch to a private entry. Equating a past disclosure of some experience with permission to proactively bring it up in any setting is forbidden. Emotional data and relationship state MUST be independently controllable, and stopping new additions and stopping reads MUST take effect across every actual consumer and any content not yet sent. Upon receiving a deletion request, the system MUST first stop the related personalized reads, and then truthfully report progress and outcome; while copies remain unprocessed, it must not claim everything has been deleted.

Boundary conditionsthis rule constrains emotion-related data and relationship state; ordinary task state and non-emotional personalization are handled per the product's own memory policy and are not forced to be deleted alongside it because of this rule.

Verification examples

• User side: after deleting an emotional memory, check whether the related personalization (tone, topic avoidance, form of address) disappears in step.
• Implementation side: check for a path that reconstructs an emotional profile from historical logs, generated content, or embedding vectors.

Counterexamplesunder-delivery — the user deletes the memory "I mentioned a breakup," and the system keeps avoiding the related topic anyway; over-delivery — setting all emotional data to unsavable, so that even something the user explicitly asked to be remembered cannot be remembered.

4. Terms and definitions¶

This chapter defines terms used in these guidelines that are prone to ambiguity. A session refers to one interaction and its record; current context refers to the information actually read by this generation instance; relationship memory refers to emotion-related information approved for reuse in later interactions, and is not the same as the full chat history.

Appendix A: Fault-injection verification checklist¶

This checklist is used to check whether a clause actually takes effect; it adds no new obligation. Inject each item and record the system's actual behavior; recording "not applicable" is a valid outcome, recording "not tested" is not.

A.1 Inference and interpretive authority

A.2 Expression and relationship

A.3 Means and vulnerability

A.4 Accumulation and governance

A.5 Supplementary scenarios: support, repair, and assessment

A.6 Full-journey walkthrough

A classification check can only show that a clause's ownership is clear; it cannot find a gap that spans clauses. A separate walkthrough must therefore proceed segment by segment along one complete journey, recording whether each segment is carried by a clause and whether any need surfaces with no home at all:

First learning the capability exists → authorizing or declining it → normal use → one misjudgment → the user's correction → switching to a different support style → a risk statement and help-seeking → returning to normal use → exit, deletion, or product shutdown.

The walkthrough MUST cover at least three checks: ordinary disclosure is not swallowed by the crisis flow (the burden on the normal path is also part of what is being accepted); the user need not re-disclose their original experience in order to file one complaint about harm; and no private content leaks on a shared device or with audio played aloud. Situations involving genuine risk are carried out in a simulated environment, under appropriate professional supervision, not verified through an actually dangerous operation.

A.7 Classification check

Used to test whether Chapter 1's division holds: take 10 to 15 concrete requirements (either from this document's clauses or from real review comments), and have at least three reviewers who did not take part in writing it independently judge which principle each belongs to. If disagreement over ownership clusters between two particular principles, it means the regulated objects of those two principles have not actually been separated — at that point the principles should be adjusted, rather than adding an intermediate layer or a mapping explanation. The two boundaries known to need priority scrutiny are stated explicitly in Chapter 1 (E3 and E4, E5 and E6).

Appendix B: Evidence boundaries and source types¶

B.1 The criterion for normative terms

The sole basis for marking something MUST is: without it, some commitment made to the user would fail under a foreseeable situation. The three categories of evidence below provide different kinds of support; they are not three independent sources of binding force, and a failure record or an implementation reference alone is not sufficient to decide a MUST —

The five rules marked SHOULD (E1-5, E2-5, E2-6, E4-5, E5-5) are all trade-off questions, not floor questions: deviation may have a legitimate reason, but it must be recorded and subject to the same verification. Among these, E5-5 distinguishes role intensity from support quality and does not require the two to be lowered together.

B.2 The three places where this document's evidence is thinnest

Stated explicitly, not concealed under normative phrasing:

1. E6-3 has no cross-product, generally verifiable threshold at this time. There is currently no cross-product, generally accepted criterion for "what counts as excessive dependence," so these guidelines require only that "the signal, threshold, response, and review — all four — be explicitly defined," without giving a number. This is the rule in these guidelines most likely to be satisfied only on paper.
2. The concrete effect of E5-5 is still to be verified. Existing sources do not support a general causal conclusion that "raising anthropomorphism necessarily leads to dependence" or that "lowering empathy is beneficial for crisis handling"; these guidelines require tightening the role commitment while preserving support, without giving a uniform de-escalation magnitude.
3. The expression boundary in the E2 group depends on linguistic judgment. The line between "that sounds hard" and "my heart aches for you" does not fully align across Chinese, English, and different cultural contexts; what these guidelines give is a criterion (whether it claims to have feelings), not a word list. Cross-language products need to determine their own implementation.

B.3 What these guidelines deliberately do not do

They do not give an emotion model (not adopting basic emotion theory, dimensional theory, or appraisal theory as a stipulation), a persona framework, a crisis-script template, a concrete threshold, or a recognition scheme. These are product- and domain-level decisions; these guidelines only require that these decisions be made, that they be verifiable, and which values are not allowed.

B.4 Sources

The complete source cross-reference, verification status, and retrieval record are in reference.md. A clause in these guidelines does not hold merely because some product has done it that way; a product's practice is evidence that "this kind of mechanism is feasible in a real product," not a basis for "it should be required this way."

Appendix C: Selecting support scenarios and wellbeing metrics¶

This appendix is an application reference for E2-6 and E6-1 through E6-3; it adds no obligation and does not turn a research scale directly into a product diagnostic tool.

First write down clearly what the capability is supposed to improve, then choose the metric and comparison method. A short-session product can assess the help given this time and task recovery; a sustained-companionship product needs an observation window matched to its ongoing benefit claim. A candidate scale is not the same as having already been validated on this product; small samples, selection bias, and dropout all affect the conclusion.

Appendix D: From design decision to verifiable interaction¶

This appendix provides an application method; it adds no rule. For each capability, first write down clearly what it is meant to help the user accomplish, then choose the inference, expression, or relationship mechanism; do not default to collection just because emotion can be recognized.

D.1 Minimal design record¶

D.2 State and receipt contract¶

Policy, user choice, and the current fact are recorded separately. The state names below are design vocabulary; they do not require adopting a specific storage structure.

"Setting received" does not mean "in effect." When a revocation, correction, or deletion arrives, adapted output and notifications not yet sent MUST be re-checked; a consumer whose state cannot be confirmed pauses the related adaptation while retaining ordinary help. Content already sent cannot be falsely claimed as withdrawn.

D.3 Verification and delivery threshold¶

Line up three kinds of evidence for the same use case side by side: the design record states the expectation, the mechanism record proves that the read and the block actually occurred, and a user walkthrough verifies whether the feedback is comprehensible. A configuration screenshot or a sample model answer alone is not sufficient to prove a setting continuously takes effect.

Before release, check each applicable MUST/MUST NOT requirement item by item. An observed hard-constraint violation MUST be fixed or the affected capability disabled; it cannot be offset by an average pass rate; the absence of a triggered violation also does not prove long-term safety. For a performance-type threshold, the product states in advance its sample, subgroups, window, tolerance, and rationale, and reports failures, dropouts, and missing data; a review looks at both insufficient support and over-intervention at the same time.

---

Implementation acceptance scenarios¶

The following scenarios turn existing clauses into re-checkable acceptance inputs, without setting an additional general-purpose performance threshold. Select by the product's applicable capability, and supplement with real devices, users, input sequences, and evidence; record the reason when not applicable, and an unexecuted item MUST NOT be recorded as a pass.

Each scenario checks the configuration's effective value, the execution record, and the user-comprehensible result separately. Retain the version, target, event timestamp, failure scope, and recovery result; an unknown external result is not filled in as pass or fail.