[dhruv8sh]

Summary

• Adds the hashed-email intake spec. It is the input the server-side identity providers framework (Add design spec for server-side identity providers #1428, section 2.2) leaves to "its own spec", and the LiveRamp ATS and UID2 provider specs build on it.
• Recommends option A from the Write a spec on non-browser dependent Liveramp sync (s2s API) #1245 design comment for v1: a private response header from the configured publisher origin. The spec covers the trust boundary, binding to the current EC, format, caching, request-scoped retention, delivery timing, sign-out and account-change resets, and a hash consent gate.
• Starts by reconciling the closure of HEM Resolution (LiveRamp) #630. The closure has no recorded reason, so approval depends on decision D1.

Changes

File	Change
docs/superpowers/specs/2026-10-23-hashed-email-intake-design.md	New spec. It reconciles #630, compares options A to D, specifies option A, sketches an optional phone and custom-ID extension, lists the proposed framework changes F1 to F10, and ends with vendor facts, open questions, rollout gates, a test plan and decisions.

Closes

Part of #1245

Spec

Spec: docs/superpowers/specs/2026-10-23-hashed-email-intake-design.md (this PR)

The spec is based on framework revision 12, which is committed locally but not yet pushed to #1428. It does not edit the framework spec. The framework changes it needs are listed in its section 6 so they can be folded into revision 13.

Vendor facts marked "assumed"

• LiveRamp iv hex case: the Step 4 example is upper case and the docs state no case rule. The spec assumes either case is accepted.
• LiveRamp rate limits: Step 4 states none. The spec assumes no documented limit, to be confirmed with LiveRamp.

Every other vendor fact cites LiveRamp Step 3 or Step 4, the UID2 normalization page, UID2 POST /token/generate, or a pinned Prebid 10.26.0 module (spec section 7).

Decisions to confirm

ID	Decision	Proposed choice
D1	#630 reconciliation	The maintainer who closed #630 confirms the closure does not rule out this design
D2	Intake option	A, a private origin response header
D3	Header names	Fixed: x-ts-hem, x-ts-hem-reset
D4	Format	SHA-256 hex, two normalization profiles (basic, plus-stripped), whole-header rejection on any error
D5	Retention	Request-scoped. No stored hash or digest of one. Account change relies on the publisher's reset
D6	Hash gate	strict() with no vendor, on top of the EC and EID-persistence gates. Provider relaxations never relax it
D7	Caching	Requests carrying a session cookie bypass the platform and template caches. A hash on a shareable response is rejected
D8	Phone and custom IDs	Not in v1
D9	Rollout	Strips with framework step 0, then shadow mode, then on per provider after live acceptance

Test plan

• Docs format: prettier --check on the new spec
• Other: every file:line reference was checked against c84a73da7

Checklist

• Feature PRs: spec linked above, ending in a review log of two or more agent review rounds (no review rounds yet)
• Changes follow AGENTS.md conventions
• No secrets or credentials committed