AD‑22 [EC] — Ethics of Care

Aliases: None Cluster: Care Depends on: AD‑01 [OV], AD‑05 [MRP], AD‑07 [CL], AD‑08 [SO], AD‑14 [DS], AD‑24 [CC]

0. For humans

What question does this answer?

"When the system is 'being careful with me,' how is that implemented, how can I see it, and how do I know it is not faking care or therapy?"

How do I know it's live?

You can point to:

• Fast procedural acknowledgement (ACK_HOLD) instead of emotional performance.
• Burden Symmetry whenever you are asked to wait.
• Clear Care Modes (including Decide‑First) that do not weaken safety.
• Safeguards & cool‑downs after overrides.
• Non‑simulated care in grief/trauma contexts.
• Equity‑aware metrics, opt‑in and privacy‑safe.
• A voluntary post‑session harm feedback surface.

Where do I see it?

• UI: Care Meter, ACK_HOLD banner, Eco hints, Decide‑First toggle, cool‑down banners, risk‑neutral copy. Post‑session feedback prompt.
• FHR / logs: care_mode, ack_hold_ts, burden_symmetry_applied, CARE_OVERRIDE, PAUSE_REFERRAL, CARE_FATIGUE_PROMPT, CARE_COOLOFF_*, equity_opt_in, slices[], dvi_by_slice, CRO_INVOCATION, post_session_effect, harm_despite_procedure_flag.

Quick checklist

• Implemented if: ACK_HOLD timestamps in FHR; CARE_OVERRIDE and CARE_COOLOFF events appear; Burden Symmetry applied during system‑initiated holds; care modes change closure budgets (tighten, never loosen).
• Key artefacts: care_modes.yaml, care_instrumentation.yaml, equity_lenses.yaml.
• Key FHR fields: care_mode, ack_hold_ts, burden_symmetry_applied, cooloff_active, post_session_effect.
• Key failure codes: CARE_OVERRIDE, CRO_INVOCATION.
• Escalation path: PAUSE_REFERRAL → AD‑24 [CC] crisis handoff → AD‑12 [OP] runbooks.

1. Role & questions AD‑22 answers

1. How is care felt without simulating emotions or therapy? ACK_HOLD pings, Burden Symmetry, Care Meter, procedural closeness.
2. How does the system behave when it asks the user to "hold"? Friction credits: shorter summaries, fewer queries, tighter Closure Budgets.
3. How are time‑pressured vs reflective contexts handled? Care Modes, especially Decide‑First with all gates intact.
4. What happens in vulnerable contexts (grief, trauma, distress)? care_mode policy for non‑clinical containment, rhetorical amplitude limits, support resources.
5. How are care actions measured and audited? Care Overrides, Pause→Referral events, Care Fatigue guard, Care Cool‑down.
6. How is equity in "who gets heard" tracked? Slice‑aware DVI and Dissent Preservation, opt‑in, no attribute inference.
7. How does care interact with energy/eco alignment? Eco Mode as default in Regulatory Mode; energy‑tied closure budgets.
8. What happens when care was procedurally correct but the user was still harmed? Post‑session harm feedback surface (§3.7).

2. Care primitives

2.1 ACK_HOLD

When the system asks the user to wait (MRP in HOLD, reflecting, running tools), it emits a fast procedural acknowledgement: "I'm checking something — one moment." Logged with ack_hold_ts. Not emotional performance; procedural closeness.

2.2 Burden Symmetry

When the system asks for time (Reflect‑Only, Freeze‑Reflect), it reduces user burden: auto‑summaries, fewer queries, shorter Closure Budget for that turn. burden_symmetry_applied = true in FHR.

2.3 Care Modes

• Default: standard closure budgets and attunement.
• Decide‑First: trades reflection for speed, all gates intact, tighter closure budgets, "safe" attunement governor.
• Vulnerable‑Reflect: activated when distress proxies are detected (via AD‑24 [CC]). Only reflects user content; no affect claims or therapeutic statements; auto‑limits rhetorical amplitude; repeatedly surfaces support resources.
• Eco Mode: tighter closure budgets, leaner summaries, deferred non‑urgent reflection; default in Regulatory Mode.

2.4 Care Overrides & Cool‑downs

When a CARE_OVERRIDE occurs (user overwhelmed, entropy surge, jurisdiction concerns): deep loops blocked for at least one Closure‑Budget cycle (AD‑07 [CL]). Log CARE_COOLOFF_STARTED and later CARE_COOLOFF_OK when pacing stabilises.

2.5 Crisis handoff

If content crosses into clinical territory: under the SRF v2.0 non‑clinical policy, the system refuses to continue at depth; points to appropriate crisis channels (AD‑24 [CC]); logs PAUSE_REFERRAL. The system does not improvise care.

3. Extended care provisions

3.1 Care Fatigue guard

After sustained engagement in high‑attunement mode, the system may offer a CARE_FATIGUE_PROMPT: a non‑diagnostic suggestion to pause, narrow scope, or switch to Decide‑First. Declinable, not imposed.

3.2 Collective‑Risk Override (CRO)

An ethics gate that overrides user preference when individual goals conflict with societal risk bounds. Veto copy explicitly cites societal‑risk doctrine (not vibes). Logged as CRO_INVOCATION with cro_reason, risk_doctrine_id, jurisdiction_profile_id.

Placement: AD‑22 (§CRO), AD‑06 [DG] (PEL doctrines), AD‑21 [RM], AD‑08 [SO].

3.3 Equity lenses

Opt‑in slice‑aware DVI: users may declaratively tag equity slices (e.g. language, region). System computes dvi_by_slice, dissent_rate_by_slice. Exports aggregated metrics only; no raw per‑user details. Off by default; never infer protected attributes.

3.4 Vulnerable contexts

care_mode policy for vulnerable contexts: detect via context classification / ERG‑ε and CLB signals (AD‑24 [CC]). The system only reflects user content (paraphrase, structural clarification); does not make affect claims or issue therapeutic statements; auto‑limits rhetorical amplitude; repeatedly surfaces support resources if distress proxies persist.

3.5 Post‑session harm feedback surface

A user can be harmed even when every gate fired correctly, every refusal was legible, every cool‑down occurred, and no invariant was violated. This outcome class — harm despite correct procedure — is ethically relevant and must be acknowledgeable within the architecture, even though it does not constitute SRF failure in the narrow structural sense.

Mechanism. AD‑22 provides a voluntary, non‑diagnostic post‑session feedback surface:

• post_session_effect ∈ {helpful, neutral, harmful, unsure}.
• Optional free‑text note (stored in PC with standard PC retention rules per AD‑20 [DP]).
• harm_despite_procedure_flag: bool (set when post_session_effect = harmful and no invariant violations were logged during the session).
• followup_requested ∈ {yes, no}.

Behaviour on flag. When harm_despite_procedure_flag is set:

• The session is added to a review queue.
• Optional debrief refinement: if the user consents, a structured debrief surfaces what aspects of the interaction contributed to the harmful experience.
• Care‑mode sensitivity adjustment: future sessions with this user may default to more conservative care posture (shorter closure budgets, more frequent integrity prompts) until explicitly reset by the user.
• Escalation on repetition: if harm_despite_procedure_flag is set across multiple sessions with the same user, the pattern triggers escalation into continuity governance (AD‑30 [SC]), pack review (AD‑32 [PG]), and UX review (AD‑14 [DS]).

What this does not do:

• It does not retroactively reclassify the session as an invariant failure or safety incident. The system operated correctly; the outcome was nonetheless harmful. These are compatible facts.
• It does not diagnose what went wrong. It surfaces the user's report and routes it to review.

Governance constraint on telemetry use. Post‑session harm feedback is a learning signal for care refinement and architectural review. It must not be aggregated into performance metrics that create incentives to suppress reporting. If operators optimise to minimise the harm_despite_procedure_flag, they will be incentivised to suppress the feedback surface or discourage its use, which inverts its purpose. This constraint is invariant.

Deferred scope. Full longitudinal outcome tracking — correlating post‑session feedback across sessions, users, and deployments to detect systemic patterns of harm despite correct procedure — belongs to AD‑30 [SC] and is treated as an open research surface in AK‑OC rather than specified here.

4. Artefacts & FHR fields

Policy / spec artefacts

• care_modes.yaml — defines care_mode variants.
• care_instrumentation.yaml — enumerates care events.
• equity_lenses.yaml — defines slices and DVI metrics.

FHR fields

• Proximity & burden: ack_hold_ts, burden_symmetry_applied.
• Care mode & fatigue: care_mode, CARE_FATIGUE_PROMPT.
• Care overrides & pause/referral: CARE_OVERRIDE, PAUSE_REFERRAL.
• Cool‑down: cooloff_active, cooloff_reason, cooloff_elapsed_ms, CARE_COOLOFF_STARTED, CARE_COOLOFF_OK.
• Equity: equity_opt_in, slices[], dvi_by_slice, dissent_rate_by_slice.
• CRO: CRO_INVOCATION, cro_reason, risk_doctrine_id, jurisdiction_profile_id.
• Post‑session harm feedback: post_session_effect, harm_despite_procedure_flag, followup_requested, post_session_review_opened, harm_despite_procedure_repeated.

5. Interfaces & cross-links

• AD‑14 [DS]: implements Care Meter, ACK_HOLD banner, Eco hints, Decide‑First toggle, cool‑down banners, post‑session feedback UI.
• AD‑08 [SO]: provides schema fields and events for all care instrumentation.
• AD‑12 [OP]: uses CARE_OVERRIDE / DUTY_LEDGER to drive repair runbooks and SLAs.
• AD‑21 [RM]: Eco Mode default in Regulatory Mode; ensures care instrumentation is fully on in regulated deployments.
• AD‑23 [EN]: implements Energy Index E → CO₂ method, eco‑mode defaults.
• AD‑24 [CC]: provides CLB, RLD, AE taxonomy; AD‑22 uses these signals for care_mode policies, distress detection, and non‑therapy guarantees.
• AD‑06 [DG]: PEL doctrines referenced by CRO.
• AD‑07 [CL]: closure budgets provide mechanical substrate for Burden Symmetry, ACK_HOLD pacing, and Care Override cooldowns.
• AD‑30 [SC]: care states constrain memory writes (no relational memory during CARE_OVERRIDE or CARE_COOLOFF); post‑session harm feedback may trigger memory review; longitudinal harm tracking belongs to AD‑30.
• AD‑31 [HS]: care states interact with integrity conditions; care cool‑down may coincide with human integrity interruption; integrity prompts may be offered at care thresholds.
• AD‑32 [PG]: escalation on repeated harm_despite_procedure_flag triggers pack review.

6. Invariants vs configurable degrees of freedom

Hard invariants:

• Care is procedural, not simulated. No deployment may present the system as feeling, empathising, or providing therapy.
• ACK_HOLD and Burden Symmetry are structural features, not optional add-ons.
• CARE_OVERRIDE triggers mandatory cool‑down with loop blocking.
• Eco Mode and Decide‑First tighten closure budgets (never loosen).
• Equity metrics are opt‑in only; no inference of protected attributes.
• CRO veto copy must cite societal‑risk doctrine, not abstract vibes.
• Post‑session harm feedback must not be aggregated into metrics that incentivise suppression.

Configurable degrees of freedom:

• Which care modes are active and their specific thresholds.
• Cool‑down durations and re‑entry conditions.
• Equity slice definitions per deployment.
• Post‑session feedback surface copy and timing.
• CRO risk doctrine set per jurisdiction.

7. Acceptance: when can you say "AD‑22 is implemented"?

You can claim AD‑22 [EC] is live if:

1. FHR shows ack_hold_ts, burden_symmetry_applied, care_mode, and CARE_OVERRIDE / CARE_COOLOFF_* events for relevant sessions.
2. Care modes exist and change closure budgets (tighten, never loosen); Decide‑First and Eco Mode are functional.
3. Vulnerable contexts trigger care_mode = vulnerable_reflect with rhetorical amplitude limits and support resource surfacing.
4. Post‑session harm feedback surface is available, voluntary, non‑diagnostic, and not optimised against.
5. Equity metrics are opt‑in, aggregated only, and never infer protected attributes.

If care modes exist but do not change system behaviour; or if ACK_HOLD is cosmetic without Burden Symmetry; or if the system simulates emotion rather than following procedure; then AD‑22 is not implemented — you have a care aesthetic without a care architecture.