Law Engineering Field Guide#

Rothken Law (techfirm.com) · Edition 1.24.1 · September 2026

Translating law into interface, code, and data — an illustrated living primer for lawyers and engineers.

Law Engineering Field Guide#

Translate law into interface, code, and data — then prove it.

Welcome#

This guide is for people who ship regulated product surfaces — and for the counsel who have to defend them later.

For years, the industry ran a bad handoff. Lawyers drafted a memo, sent it to the engineers who control the stack, and hoped the logic made it into code. Sometimes it did. Often it didn’t. Courts and agencies look at what the product actually did, not at what the PDF hoped.

Law Engineering is the opposite of that hope. It means working with engineering so you can see the stack when you need to: the signup screen, the cancel path, the network tab, the row that gets written. You don’t fully delegate legal decisions that show up in interface, code, or data design. You translate the duty into something a release can pass or fail — then keep the proof.

A Law Engineer is a licensed attorney with software and product expertise. Engineers and other builders implement the gates under that counsel’s oversight. They are essential colleagues. They are not titled Law Engineers. Liability and legal meaning stay with counsel.

Where this guide came from#

The Law Engineering idea grew out of our practice at Rothken Law (techfirm.com). Over the years we built playbooks for product counsel and eng leads — formation evidence, cancel gates, privacy congruence, takedown clocks, harbor ladders. We turned some of those playbooks and experiences into this Field Guide so the people who come after us don’t have to invent the method under deadline pressure.

We saw a gap on the shelf. A lot of energy goes into Legal Engineering and into AI that automates law practice — drafting, research, matter tooling. Useful neighbors. Different job. Other guides cover cybersecurity, or survey internet law in general. What seemed sorely needed was a guide that helps tech lawyers get compliance by code, design, and data — interface, server gates, and exportable proof — with counsel still owning the legal meaning.

That’s this book. Not a brochure. A bench kit.

Who is walking you through this#

I’m Ira. I’ve practiced high-technology law since the early commercial internet — counseling product teams when the stack was still inventing the category, and litigating when the category invented new claims.

I founded Rothken Law in 1993. By the mid-1990s the work was already e-commerce policies, early affiliate programs, and risk design for sites that had no clear precedent — only a release date. I’m a licensed attorney with a computer-science background. That mix is why this guide treats interface, code, and data as where the legal duty lives.

One early matter stays with me as teaching context: I served as co-lead settlement class counsel in In re DoubleClick Privacy Litigation — a nationwide consumer privacy case about merging clickstream behavior with personally identifiable information. The fight was about cookies, retention, and what privacy meant when a product could profile a user across the open web. It did not end with a PDF policy alone. It ended with product commitments the industry could copy — purge rules, shorter cookie life, public education, and independent compliance review.

Past matters do not predict your facts. They do explain why this guide insists that counsel who only write memos lose ground, and counsel who can redesign the stack have a chance.

How to use this guide#

This Field Guide is written for new lawyers and summer associates joining a tech practice — and for the product counsel and engineers who work with them. Each chapter covers a surface you are likely to see: formation, cancel, privacy tags, age gates, DMCA, repeat infringers, and the rest.

The job of each memo is the same. Keep you interested. Marry the statute or case theme to what must exist in the stack. Show why with a hypo or public case fact pattern. Then hand you Interface / Code / Data moves you can ship — so you protect the company creatively, not by pasting a PDF into a ticket.

1. Chapter 0 — What Law Engineering Is — the discipline in plain English, and how it differs from Legal Engineering.
   
2. Chapter 1 — The Method Loop — Law → Interface → Code → Data → Counsel sign-off.
   
3. Worked examples — formation, dispute architecture, cancel, privacy congruence, age gates, DMCA, repeat-infringer ladders, agentic flows, payments, messaging, moderation, and more. Open the chapter that matches the surface you are shipping.
   
4. Operating model — who staffs what, release gates, and how patterns evolve.
   
5. Pattern Map + LE title index — find the teaching chapter for each pattern id when you need a quick pointer.

A good first pass (about 45 minutes): Chapter 0 → Chapter 1 → one worked example that matches your product → the Pattern Map rows you will touch this quarter → the operating-model chapter before the next release train.

A good working rhythm: When a ticket touches a legal act (agree, consent, opt-out, cancel, report, verify age, remove content), open the matching teaching chapter, run the method loop, and require counsel sign-off before the gate opens in production.

Engineers: treat the Code and Data rows as acceptance-test seeds, not informal hunches.
Lawyers: review Interface at wireframe time — not after the App Store build.

Each worked example follows the same memo rhythm: interesting fact pattern or case theme → what went wrong → how Law Engineering would have changed the ending (Interface / Code / Data) → then checklists and Lawyer/Engineer cards. Checklists come after the aha, not before.

Edition and versioning note#

This is a living field guide. Law and product surfaces move; the guide should move with them.

Recommended habit: one line per edition in your own notes — what changed, which LE ids you touched, who signed off.

What this guide is not#

• Not a substitute for reading the statute, the regulation, or the opinion.
  
• Not a complete ops runbook for every high-risk workflow (AML, CSAM preservation, incident response) — those need your counsel and your own runbooks.
  
• Not permission to ship “AI agreed for the user” as assent.

Educational field guide — not legal advice. It does not create an attorney–client relationship. Enforceability and regulatory posture are fact- and jurisdiction-specific. Have counsel own the legal meaning before you ship. Re-check primary authorities for your facts and jurisdiction.

Table of Contents#

Contents#

If you are new to the method, read Chapter 0 and Chapter 1 first. Then open the chapter that matches the work in front of you.

Page numbers match this PDF edition. Links jump to chapter anchors in HTML / GoodReader. Pattern Deck is a separate companion file (not in this PDF).

Chapter 0 — What Law Engineering Is#

Audience: Product counsel, litigators who advise tech clients, founders, and the engineers who ship the stack.

The discipline in plain English#

If you are new to the firm — or new to product counsel work — start here before any surface-specific chapter. Everything after it assumes you know what Law Engineering is, who owns legal meaning, and why a memo alone is not a release gate.

Law Engineering is the practice of translating a legal duty into interface, code, and data — then keeping exportable proof that the duty ran.

In plain English: make the rule real in the product, then keep the evidence.

A Law Engineer is a licensed attorney with software and product expertise. Engineers build the gates under that counsel’s oversight. They are partners in the build. The title stays with counsel, because liability and legal meaning stay with counsel.

This is not “ask engineering to add a checkbox.”
This is not memo-to-coders and hope.
And it is not Legal Engineering as often practiced — builders creating tools that touch legal process without counsel owning what the rule means.

If you remember only one staffing rule from this chapter: counsel owns legal meaning; engineering owns implementation under that ownership.

The origin story — how this grew from Rothken Law playbooks into a field guide aimed at compliance by code, design, and data — lives in the front matter. This chapter is the definition and the why.

Why the old handoff broke#

Counsel drafts a policy or Terms PDF. Someone pastes a footer link. Engineering ships. Years later, in a dispute, nobody can show what the user saw, clicked, or agreed to.

Courts did not invent that gap. Products did.

Cases like Specht v. Netscape and Nguyen v. Barnes & Noble are famous for a simple reason: the interface told a different story than the legal aspiration. The law wanted conspicuous notice and unambiguous assent. The stack offered a Download button and hope.

Privacy taught the same lesson from another angle. When clickstream behavior and identity start to merge, a PDF notice that does not match the live tags is not a drafting typo — it is a product failure. Formation fights taught that when the user can see the terms is often the whole case. Device and platform disputes taught that courts will look at what the product actually does.

That gap is why Law Engineering exists. Your job is to close it before the release train leaves — not after discovery starts.

Design the evidence now#

When you walk into court to defend a class action and want to enforce Terms, arbitration, and a class waiver, you need to attach evidence of robust notice and user consent. Better data makes that showing more likely.

So build for that day now:

• Date and time of the assent act (server clock)
  
• IP (and user-agent as your retention map allows)
  
• Version number of the Terms the user saw
  
• Hash of the exact bytes shown
  
• A path to a declaration that can swear to the pack

Design that well in advance — not the night before the hearing. Chapter 2 walks the formation screen. Chapter 1 shows the loop that produces that pack every time.

Why it matters even more now#

Two forces make the discipline urgent.

First, compliance became a state machine.
Age verification, automatic-renewal cancel paths, privacy signals, takedown clocks, and multi-jurisdiction duties abroad are not “put it in the Terms.” They are product surfaces with states, timers, and fail-closed behavior. Fail closed means: if the check fails, the high-risk path does not open.

Second, AI and agentic commerce can act faster than review.
Probabilistic systems draft, recommend, click, buy, and message. Deterministic legal duties still require recorded assent, honored opt-outs, and auditable removals. If an agent can bind the company before a human reviews the act, counsel must place gates in the stack — not prompt-only guidance.

Field rule: Probabilistic systems may propose. Deterministic Law Engineering gates dispose.

In plain terms: the model can suggest. The gate decides.

Commitments that keep the practice honest#

Law Engineering rests on a few plain commitments:

1. The rule comes first. Start from statute, regulation, or holding — stated as something the product can pass or fail.
   
2. The interface is part of the law story. What the user sees at the moment of the legal act matters as much as the PDF in the vault.
   
3. UI without a server gate is incomplete. If the backend will accept the act anyway, you did not finish.
   
4. If you cannot export the evidence, you did not finish. Discovery and regulators ask for records, not recollections.
   
5. Counsel signs the legal meaning before production — especially on agentic paths.
   
6. Builders under counsel are colleagues, not Law Engineers by title. Keep the label honest so staffing and liability stay clear.

None of that requires jargon. It requires ownership — and a willingness to sit with your eng lead until the gate and the evidence row are real.

A quick preview of the method loop#

Chapter 1 walks the loop in detail. Here is the shape so you know where you are going:

Colloquially, Interface + Code + Data is The Build — the product surface that makes the legal requirement real before counsel sign-off.

When the law changes, or the product adds a new surface, you don’t rewrite a novel. You update the pattern, bump the guide edition, and re-run acceptance tests. That’s why this is a living field guide.

Field rules you can carry into a kickoff#

Use these as orientation — not as matter advice, and not as slang that would sound hollow under a civil investigative demand (CID):

• Notice and assent live in the product, not only in a linked PDF.
  
• Gates are deterministic. Soft prompts and model “judgment” may assist; they do not replace recorded legal acts.
  
• Fail closed on high-risk paths. If the vendor, webhook, or age check fails, do not invent a checkbox fallback.
  
• Clocks are real. Removal windows, breach notice periods, and retention limits belong in code and calendars, not only in memos.
  
• Evidence is a first-class deliverable. Schema it like a feature.
  
• Jurisdiction is a product input. Geo and market flags change which gate runs.
  
• Title follows license. Law Engineer means licensed attorney with software expertise; builders ship under counsel.

Who this field guide is for#

• Lawyers who want to stop throwing memos over the wall and start shipping enforceable designs.
  
• Engineers who want crisp acceptance tests and schemas instead of ambiguous “make it legal.”
  
• Teams that will keep a living pattern library as the law and the product change.

This guide uses plain language on purpose. Serious discipline. Clear help. No condescension.

Publisher: Rothken Law · techfirm.com.

What comes next#

1. Chapter 1 — The Method Loop (Law → Interface → Code → Data → Counsel sign-off).
   
2. Worked examples — formation, cancel, privacy, age gates, takedowns, agentic flows, payments, messaging, moderation, and related surfaces. Open the chapter that matches what you’re shipping.
   
3. Operating model, then the Pattern Map and LE title index when you need a quick pointer from pattern id to teaching chapter.

When you’re ready, turn the page. We’ll walk the loop.

Chapter 1 — The Method Loop#

This is the method memo. Every durable compliance feature in this guide — clickwrap, cancel, Global Privacy Control (GPC), age gate, takedown — runs the same five steps. Once you can run the loop, the later chapters are just the loop applied to a new statute or surface.

Colloquially, Interface + Code + Data can be called The Build — the product surface that makes the legal requirement real before counsel sign-off. A Law Engineer (a licensed attorney with software and product expertise) owns the legal meaning. Engineers implement the gates under that counsel’s oversight.

Think of the loop as a checklist you keep on the bench, not a theory you memorize once. Walk a live ticket through Law → Interface → Code → Data → Counsel sign-off with counsel and eng on the call. Ask which step is still a memo. If it’s still a memo, you’re still in the old handoff — and you’re still fully delegating a legal decision the stack is about to make for you.

1. Law — what must be true#

Start from a holding or statute. Say it as an engineering-relevant requirement — something a release can pass or fail.

Example (formation theme): the user must receive reasonably conspicuous notice of terms and give an unambiguous manifestation of assent (Specht; Meyer; Nguyen themes).

In plain English: the user must clearly see that Terms exist, and must clearly do something that means “I agree.”

Write it as a testable sentence, not an aspiration:

• “Signup cannot complete unless assent to Terms version V is recorded.”

If you can’t write that sentence, you’re not ready for Interface yet. You still have a memo.

2. Interface — what the user sees and does#

Design the screen at the moment of the legal act — the tap, check, or confirm that makes the law “happen.”

Ask, with the wireframe open:

• Is notice visible without scrolling on a small phone?
• Is the action language tied to agreement (“By tapping Create account, you agree…”)?
• Are links real links, not gray decoration?
• Did we avoid pre-checked boxes and footer-only browsewrap?

Browsewrap means Terms live only in a quiet footer link, with no sentence tying the tap to agreement. Courts often treat that as weak or failing notice.

Lawyers review wireframes here — not after the App Store build. Catching a submerged Terms link at wireframe time is cheap. Catching it in a motion to compel is not.

3. Code — gates and events#

UI without enforcement is incomplete. The beautiful assent sentence means little if POST /users creates the account anyway.

Hit Create without assent and watch what the server returns:

• Reject POST /users without a valid acceptance event.
• Single sign-on (SSO) still hits an assent gate before paid or high-risk features unlock.
• Material Terms changes set requires_reconsent=true and block gated APIs until a new acceptance fires.

Engineers own the gates. Counsel owns which events are “material.” That split keeps both sides honest: Legal doesn’t invent half-built APIs, and Engineering doesn’t decide alone when the law requires a fresh yes.

4. Data — the evidence pack#

If you can’t export it, you didn’t finish.

Picture the hearing. You want to enforce Terms, arbitration, class waiver. Someone asks: what did this user see, and what did they do? Your answer should be a row you can attach — not a shrug and a Slack search.

Minimum formation pack — design it well in advance:

• user id
• terms version id + content hash of the exact bytes shown
• UI surface (signup_ios, checkout_web…)
• action type (checkbox vs sign-in-wrap)
• server timestamp (date and time), IP/user-agent as appropriate
• optional screenshot/DOM archive
• a path so counsel can swear a declaration to the pack

A content hash is a fingerprint of the exact Terms file the user saw. It defeats “we posted a new PDF later” disputes. Better data → more likely you can show robust notice and consent when it matters.

This is how you answer discovery without grepping application logs under deadline pressure.

5. Counsel sign-off — especially before agentic release#

For ordinary create-read-update-delete (CRUD) apps, sign-off is a release checklist.
For agentic flows — tools that purchase, post, or “agree” — sign-off is a hard gate. No probabilistic path around deterministic requirements.

Field rule: Probabilistic systems may propose. Deterministic Law Engineering gates dispose.

In plain terms: the model can draft a cart or suggest a reply. Counsel-approved gates decide whether money moves, terms bind, or content ships.

How the loop stays alive#

When the law changes — or the product adds a new surface — you don’t rewrite a novel. You update the pattern for that surface, bump the guide edition, and re-run acceptance tests.

That’s why this guide is a living field guide, not a frozen paperback. Chapter 2 puts the loop to work on formation UX — the court-evidence beat, live on a signup screen. From there, every worked example is the same five steps with different facts.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 2 — Worked Example: Formation UX (Lost vs Fixed)#

Pattern family: Online terms assent (LE-01)
Legal anchors: Specht v. Netscape, 306 F.3d 17 (2d Cir. 2002); Nguyen v. Barnes & Noble, 763 F.3d 1171 (9th Cir. 2014); Meyer v. Uber Technologies, 868 F.3d 66 (2d Cir. 2017); Douglas v. Talk America, 495 F.3d 1062 (9th Cir. 2007) for later amendments.

Why this memo exists#

Illustrative reconstructions for teaching. Not official screenshots of any party’s product.

Picture signup on a phone. Big button: Create account. Somewhere below the fold, a quiet gray link says Terms. The user taps Create. Years later, counsel needs to prove they agreed.

Formation means: did the parties actually make a deal the court will recognize? For product teams, that usually means two things. Did the user get reasonably conspicuous notice of the Terms? And did they give an unambiguous manifestation of assent — a clear act that means “I agree”?

Keep this court day in mind. You walk into court to defend a class action. You want to enforce Terms, arbitration, and a class waiver. You need to attach evidence of robust notice and user consent. Better data → more likely you can show it. So we design — well in advance — a pack that can carry:

• Date and time (server timestamp of the act)
  
• IP (and user-agent as your retention map allows)
  
• Version number of the Terms the user saw
  
• Hash of the exact bytes shown
  
• A path to a declaration counsel can swear to

If that pack doesn’t exist at accept-time, you’re grepping logs under deadline pressure. That’s not Law Engineering. That’s hope.

I spent years watching courts ask what the user saw before Buy — including shrink-wrap EULA fights where the terms lived inside the box (Baker-era themes: pre-purchase access and a real return path matter). The teaching point is simple: if the user cannot see the deal before the irreversible act, formation is already in trouble.

Review this chapter with counsel and eng on the same call. Ask whether a reasonable user would know they were agreeing. That question is the whole game.

Side A — What loses#

Here’s the lose pattern. The user taps a primary action — Download, Register, or Pay. Terms are mentioned only after scrolling, or only as a quiet hyperlink with no assent language. The screen story is “I just wanted the thing,” not “I agreed to a contract.”

Why courts care: Formation needs conspicuous notice and unambiguous assent. A submerged license link does not tell a reasonable user they are bargaining. Cases in the Specht and Nguyen family are famous because the interface told a different story than counsel’s aspiration.

Lawyer lens — what I’d ask on the call: You will struggle to compel arbitration or enforce Terms if the screen story is “I just downloaded the thing.” Discovery will ask for the exact screen and the exact text shown. Hope is not an exhibit. Without date, time, IP, version, and hash, your declaration has nothing solid to attach.

Engineer lens: If the API creates the account whenever the button is pressed — no acceptance event — there is nothing honest to log. You cannot invent a row later that the stack never wrote.

Non-compliance checklist (red flags)#

Before you call a signup “done,” check this list. Any hit is a formation risk:

• Footer-only browsewrap (Terms only in a submerged footer link) as the sole theory
• Terms below the fold relative to the call-to-action (CTA)
• No “By tapping… you agree” language
• Pre-checked “I agree”
• Links that 404 or open after the account already exists
• No stored terms_version / content hash
• No server timestamp / IP on the acceptance row
• No path to export a pack counsel can declare to

Side B — What works better#

Here’s what I want you to build.

Pattern (sign-in-wrap done carefully): An uncluttered screen; an assent sentence adjacent to the CTA; conspicuous Terms/Privacy links; notice visible without scrolling (Meyer-style themes). Sign-in-wrap means the act of creating the account (or signing in) is itself presented as agreement — but only when the notice is clear and tied to that act.

Stronger still (clickwrap): The CTA stays disabled until the user checks “I agree to the Terms.” Prefer this for dating, adult, paid subscriptions, and other high-stakes flows. Clickwrap is the classic checked-box pattern — when the box starts unchecked and the user must affirmatively check it.

Code gate: POST /users rejects without acceptance of the current required version. Try Create without assent. You should see a reject — not a 201.

Data — the court pack: An append-only acceptance row + hash of the exact Terms bytes shown + UI surface id + date/time + IP + version. Expand into the Evidence pack checklist below before you call the release done. Design the declaration path now.

Compliance checklist (green flags)#

• Assent language tied to the action
• Working, obvious links
• Above-the-fold on target devices (test 320–390px width)
• Server-side gate
• Exportable evidence pack (date, time, IP, version, hash → declaration)
• Material amendments require notice + re-consent (Douglas theme) — not silent posting

How the stack implements formation (LE-01)#

Here’s how the gates look when counsel and engineering own them together — not when Legal throws a memo over the wall:

Interface: Assent sentence adjacent to the CTA; conspicuous working Terms/Privacy links; visible without scrolling on 320–390px; no pre-checked “I agree”; prefer disabled CTA until clickwrap check on high-stakes flows.
Interface must-not: Footer-only browsewrap as the sole theory; Terms below the fold relative to the CTA; links that 404 or open only after the account already exists.

Code: Server validates acceptance before account/session privileges that depend on Terms; a client modal alone is not enough. Acceptance tests: create-without-assent → reject; create-with-assent → row written; material bump → APIs blocked until re-consent; hash mismatch / wrong version → reject.

Data: Append-only term_acceptances (user id, terms_version_id, content_hash, UI surface id, action type checkbox vs sign-in-wrap, server timestamp, IP/UA as appropriate, optional DOM/screenshot archive id). Exportable for one user_id without grepping logs — so counsel can attach a declaration without archaeology.

Interface / code / data — one-page checklists#

Interface (must-show at the legal act): conspicuous notice; assent language tied to the action; working Terms/Privacy links; above-the-fold on target devices.
Interface (must-not): pre-checked agree; footer-only browsewrap alone; submerged license; post-create Terms reveal.

Code: gates G1–G5 above; acceptance-test coverage for reject-without-accept, SSO still gated, reconsent block, evidence export.

Data: versioned Terms bytes + hash; append-only acceptance rows keyed to surface; counsel sign-off id on version publish; date/time/IP ready for the hearing pack.

Template: Lawyer / Engineer card#

Use this card in the kickoff. Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Try this on your product tomorrow#

1. Screenshot signup and checkout on a small phone.
   
2. Circle the CTA. Can you see assent + links without scrolling?
   
3. Create a test account and ask: what row was written — date, time, IP, version, hash?
   
4. Ask counsel: could you attach a declaration to that pack tomorrow morning?
   
5. If the answer is “nothing” or “maybe from logs,” you don’t have Law Engineering yet — you have a PDF.

Acceptance-language + checkbox ladder#

Courts sort online formation by what a reasonable user would notice and do on the screen — not by what counsel hoped the footer meant. Climb the ladder deliberately. Don’t treat a magic phrase as a substitute for screen facts.

What the assent sentence must do

• Tie the CTA (tap / create / pay / continue) to named documents — not “our policies” or an unnamed “legal stuff” blob.
  
• Use present tense assent (“you agree,” “I agree”) bound to that action.
  
• Keep the box unchecked by default; never pre-check “I agree.”
  
• Make links look like links (underline / distinct treatment); they must resolve to the current version before privileges unlock.
  
• Keep the legal-act surface uncluttered so the sentence and links remain conspicuous on 320–390px widths.

Field rule: There is no magic winning phrase. The same words fail when buried, pre-checked, linked to a 404, or overwritten by an A/B flag (G5). Screen facts + a logged affirmative act decide the motion.

Privacy Policy juxtaposition#

When Terms and Privacy Policy appear in the same assent sentence (“you agree to the Terms and Privacy Policy”), courts often treat that pairing as one notice package for the account relationship — notice that those documents exist and that creating the account is tied to them.

That package does not equal consent for every later use. Keep the distinction clear when you brief product:

• Sale / share / GPC opt-out and related signals still need their own gates (LE-07; Chapter 4).
  
• Non-essential cookies / SDK / pixel load still needs consent-management-platform (CMP)–style gating (LE-08; Chapter 4). A CMP is the banner and preference center that records category choices.
  
• SMS / TCPA marketing assent is a separate affirmative act (LE-21) — not swallowed by account Terms.
  
• Loyalty, Conditions of Sale, and other program paper bind the act that incorporates them — see the multi-doc table under checkout below.

Field rule: One sign-in-wrap sentence can form the account relationship. It does not silently authorize every later processing, messaging, or purchase program. Keep separate controls, separate incorporation_set (or equivalent) ids, and separate evidence rows where the legal act is different.

Evidence pack (Data row) — export checklist#

Frame this as proof of what was shown and what was clicked — not surveillance. Counsel should be able to export one user_id (or acceptance_event_id) without grepping application logs — and swear a declaration to it.

Also retain (adjacent, not optional for a serious pack): acceptance_event_id; user / account id; incorporation_set_id when multiple docs bind one act; counsel sign-off id on the published version. G4 already requires hash-at-accept; this checklist makes the export shape explicit. Design it well in advance.

Electronic records and signatures (E-SIGN / UETA) — practical note#

Federal E-SIGN (Electronic Signatures in Global and National Commerce Act) and state UETA (Uniform Electronic Transactions Act) orient that a contract or signature is not denied legal effect solely because it is electronic. For product stacks, the practical floor is still ordinary formation plus three engineering-facing duties:

1. Intent to sign — the user takes an affirmative act that the UI presents as agreeing (checkbox check or sign-in-wrap CTA), not a submerged browse.
   
2. Association with the record — the act is bound to the specific Terms (and Privacy, when packaged) version and content hash shown.
   
3. Retention of the record — keep the acceptance row and versioned bytes so the agreement can be reproduced (and declared to).

Tie those duties to the logged affirmative act + retained hash in the evidence pack. This is orientation for release gates — not a treatise on every E-SIGN consumer carve-out. Where an agent binds on a user’s behalf, see Chapter 6B.

Lost vs won — case / fact-pattern table#

Themes for orientation. Pinpoint cites are in the chapter header; don’t treat the “Outcome theme” column as a holding for your facts.

Checkout when dispute clauses are high-stakes#

Account signup and Pay are different legal acts. A clean sign-in-wrap at registration does not rescue a checkout that relies on a quiet footer Terms link while the Conditions of Sale bury arbitration and a class waiver.

Lost pattern: Guest or returning buyer taps Pay. The only Terms affordance is a footer hyperlink. Confirmation email says “Order confirmed.” Counsel later needs to compel arbitration and cannot show conspicuous notice at the purchase act (Specht / Nguyen themes; contrast Meyer-style uncluttered notice). No date/time/IP/version/hash pack for the Pay act either.

Fixed pattern: At Pay, an assent sentence (or checkbox on high-stakes / heavy-arbitration flows) ties the tap to the Site Terms + Conditions of Sale versions actually linked; links work; notice is above the fold on a small phone. Optional programs (SMS, loyalty) use separate controls — messaging assent is not purchase assent. The Pay acceptance row carries the same court-ready fields.

Multi-doc stacks (which paper binds which act)#

Methods stacks commonly encode an incorporation_set_id on the acceptance row so export does not pretend one checkbox bound every program. Privacy juxtaposition (above) explains why Terms+Privacy in one account sentence is still not a blank check for later processing gates (LE-07 / LE-08; Chapter 4).

Order-as-offer timing#

Some Sale Terms treat the customer’s order as an offer, with seller acceptance on shipment (or on a separate notice). In that design, a confirmation email is receipt of an offer — not acceptance. Methods stacks commonly encode a distinct seller_acceptance_at (often at first shipment) and keep confirmation copy honest (“Order received”) so the evidence timeline matches the paper.

Where this goes next#

• Dispute architecture (arb / class / LoL / waiver / indemnity) — Chapter 2B (LE-68).

• ROSCA / cancel (easy cancel that actually cancels) — Chapter 3.
  

• Privacy tag congruence (pixels that fire vs what the policy discloses) — Chapter 4.
  

• Ecommerce authenticity, final-sale, compare-at, and loyalty patterns — later ecommerce chapters.
  

• Pattern Map and LE title index at the end of this guide.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 2B — Worked Example: Dispute Architecture (Arb / Class / LoL / Waiver / Indemnity)#

Pattern family: Subscriber dispute architecture — arbitration, class waiver, limitation of liability, unknown-claim waiver, indemnity as Interface / Code / Data (LE-68). Deepens formation UX (LE-01 / LE-02; Chapter 2).
Legal anchors (themes): Arbitration / class-waiver presentation themes (Meyer / Nguyen / clickwrap conspicuity); limitation-of-liability and indemnity as contract design that must be findable at assent; California Civ. Code § 1542-style unknown-claim waiver themes when releases ship; unconscionability / public-injunction / mass-arbitration / FOSTA carve-out pressures — counsel-owned, fact-specific. No underwriting puff — this chapter doesn’t promise any clause will be enforced.
As of September 2026: Re-check forum, mass-arb fees, and public-injunction caselaw before anyone encodes “always enforceable” in a release note.

Why this memo exists#

Arbitration, class waiver, limitation of liability, and indemnity only protect the company if the formation screen and evidence pack can carry them.

When you walk into court (or a motion to compel arb), the paper only wins if the formation and checkout evidence match the clause stack. Design that congruence now.

The story in one glance#

Picture a signup that “has arbitration.”

Buried page 47 of Terms mentions arb, class waiver, a liability cap, a § 1542-style release, and a broad indemnity. The checkbox says “I agree to the Terms.” Assent evidence stores a Terms URL — not a clause_set_version. When a dispute hits, Product can’t show what the user saw about arb that day. Finance asks whether the LoL cap “covers” a regulatory fine. Someone drafts marketing that says “our Terms protect us from everything.”

Formation without a dispute architecture is a PDF hope.

Walk one signup with Terms open to the arbitration section. Ask: would a reasonable user know arb was part of the deal that day? Can you export the clause_set_version that was live — or only a URL that now 404s?

This chapter treats arbitration (arb) + class waiver + limitation of liability (LoL) + unknown-claim waiver + indemnity as first-class legal acts: conspicuous notice where required, versioned clause_set, and assent evidence you can export. Caveats stay loud. Teaching only — generic Brand.

Plain English — five clauses, one evidence pack#

Field rule — put this on the release checklist: If you can’t export clause_set_version + UI screenshot/hash + assent event for the day of signup, you have Terms — not dispute architecture.

Remember: a Law Engineer is a licensed attorney with software and product expertise. Engineers build gates under that counsel’s oversight.

Counsel-owned caveats (don’t encode as guarantees)#

1. Unconscionability — procedural + substantive; presentation and substance both matter.
   
2. Public injunction / public policy carve-outs — some claims may remain outside private arb in some forums.
   
3. Mass arbitration — fee and process design can become the product risk; counsel owns strategy.
   
4. FOSTA / criminal / non-waivable rights — dispute clauses don’t erase statutory duties (LE-13 adjacency).
   
5. No underwriting puff — never train sales that “arb means we can’t be sued” or “LoL caps all regulatory exposure.”

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“it’s in the Terms”)#

What goes wrong: One megabyte Terms. Arb and class waiver unhighlighted.

Mobile checkout scrolls past. A/B removes the “Dispute resolution” summary.

Assent row stores only terms_url. Indemnity and LoL never appear in the formation evidence pack (LE-01).

Support macros promise refunds that contradict the LoL narrative. Mass-arb arrives; nobody can prove the clause_set that shipped.

Lawyer lens — what I’d ask on the call: You need versioned clause bundles and conspicuousness design — not a vibe that “clickwrap always wins.”

Engineer lens: If assent ignores clause_set_version, discovery reconstructs from Wayback and hope.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Arb/class waiver not presented with formation-grade notice
  
• No clause_set_version on assent events
  
• Marketing overclaims enforceability or regulatory immunity
  
• A/B can strip dispute summary (LE-62 adjacency)
  
• Consumer indemnity without counsel SKU review
  
• FOSTA/criminal duties “solved” by Terms language

Side B — What works better (clause_set → notice → assent → export)#

What works better: Counsel maintains clause_set bundles (arb, class_waiver, lol, unknown_claim_waiver, indemnity) with jurisdictions and SKU applicability.

Signup / upgrade surfaces show required summaries; full Terms link remains. Assent writes clause_set_version + document hashes + UI surface id.

Evidence export joins LE-01 pack. Experiment lint forbids removing dispute components.

Training forbids enforceability puff. Mass-arb / public-injunction playbooks live with counsel — not in CI as “safe.”

Fixed user story: User signs up → sees dispute summary (if required) → agrees → assent_events cite clause_set_v2026-09-15 → later dispute → export pack shows exact clause_set + UI.

Compliance checklist (green flags)#

• Versioned clause_set registry
  
• Conspicuous summaries where counsel requires
  
• Assent evidence includes clause_set_version
  
• No marketing enforceability guarantees
  
• Experiment lint on dispute UI
  
• Caveat memo linked from eng handbook

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

When this lands in court or before a regulator, better data wins. Design the export — timestamps, versions, hashes, and a path to a declaration — well in advance.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): Dispute-resolution summary where required; accessible Terms; version or “effective date” visible to counsel tooling; no dark-pattern skip of required notice.

Interface (must-not): “You can’t sue us” marketing; hidden class waiver on mobile; silent A/B removal.

Code: clause_set_registry; assent requires version; experiment lint; evidence export API.

Data: clause_sets; clause_set_versions; assent_events (user, surface, clause_set_version, terms_hash, timestamp); export_packs.

Lost vs fixed (scene card)#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Export last week’s assent — is clause_set_version present?
   
2. On mobile, find arb/class waiver presentation in ≤2 taps from agree.
   
3. Attempt experiment removing dispute summary — CI fail?
   
4. Search marketing for “can’t be sued” / “fully protected by Terms.”
   
5. Ask counsel which caveats are briefed to Support.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Formation UX / clickwrap — Chapter 2 (LE-01 / LE-02).
  
• Agreement factory (populate + e-sign) — Chapter 2C (LE-76).
  
• Cancel / ROSCA — Chapter 3 (LE-03).
  
• Legal review triggers / experiments — Chapter 31B (LE-62).
  
• Section 230 design line (immunity ≠ ToS assertion) — Chapter 9B (LE-58).
  
• Pattern Map LE-68 — Chapter 32.

Field rule — put this on the release checklist: Dispute clauses are product surfaces. Version them, show them, prove them — and never sell them as a guarantee.

This chapter is for education and discussion. It isn’t legal advice. Unconscionability, public injunction, mass-arb, and FOSTA issues are counsel-owned. No underwriting of enforceability.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 2C — Worked Example: Agreement Factory (Populate + E-Sign)#

Pattern family: Agreement factory — verification-gated populate + e-sign (LE-76). Sits after dispute architecture (LE-68; Chapter 2B) and formation UX (LE-01; Chapter 2). Cross-cuts creator/affiliate packs (LE-28 / LE-19), custom deals (LE-71; Chapter 13B), and unified payee diligence (LE-73; Chapter 8B).
Legal anchors (themes): Assent evidence joined to versioned templates; no unsigned PDF orphan as “the contract”; e-sign ceremony evidence (who, what version, when, IP/UA where collected); counsel-owned overrides for custom deals still route through Deal OS — not a free-form Word paste.
As of September 2026: Teaching reconstructions only — generic Brand / KYC vendor / e-sign vendor. No client names.

Why this memo exists#

Creator and partner deals need versioned templates, e-sign, and hash chains — not a PDF emailed from someone’s laptop.

Every generated agreement needs the same court-ready trail: who signed, which version, which hash, when.

The story in one glance#

Ops emailing a static Creator Agreement PDF, then “we’ll get wet ink later.”

The creator uploads content and receives payouts against clickwrap alone. Weeks later someone attaches a signed scan with a different exclusivity clause. Assent events (LE-01) never mention template_id or esign_envelope_id. Custom deals (LE-71) still live as email attachments. Finance can’t prove which pack bound which payout.

Walk one creator payout that “has a signed agreement somewhere.” Ask: which template_version and e-sign envelope bind that payout? If finance shrugs, you have a drawer — not a factory.

You need an agreement factory: verification gates → populate versioned templates → e-sign → join evidence to assent — not a PDF museum.

Plain English — factory, not drawer#

Field rule — put this on the release checklist: If payout or publish can proceed against an unsigned PDF sitting in Drive, you don’t have an agreement factory.

Remember: a Law Engineer is a licensed attorney with software and product expertise.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“PDF + hope”)#

What goes wrong: Static PDFs emailed. Creators “agree” via clickwrap that never names the pack. Wet-ink scans arrive with different terms. Custom redlines bypass template versions. E-sign vendor used ad hoc; no join to assent schema. Ops reprints last year’s Affiliate Agreement for a new geo.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Unsigned PDF used as “executed”
  
• No template_version on assent
  
• Pack generated before KYC clear
  
• Custom deal PDF outside LE-71 registry
  
• E-sign envelope not joinable to payee_id
  
• Hand-edited Word as source of truth

Side B — What works better (gate → populate → sign → join)#

What works better: After diligence tier clears (LE-73), factory selects pack (creator / affiliate / custom_deal_shell).

Populate from party + Brand registries. Present e-sign with conspicuous terms summary.

On complete: store final PDF hash, envelope id, signer events; write LE-01 assent with template_version + esign_envelope_id. Publish/pay gates require joined assent for in-scope roles.

Custom economics/IP still counsel-owned in LE-71; factory only emits shells or merges approved overrides.

Compliance checklist (green flags)#

• No pack until diligence gate
  
• Version + hash on every emit
  
• E-sign evidence joinable
  
• Assent schema includes template + envelope
  
• Unsigned orphan can’t unlock payout
  
• Custom overrides via Deal OS only

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data#

Interface: Diligence-status banner before “Generate agreement”; template version visible; e-sign ceremony UX; download of executed pack only after complete; custom-deal badge when LE-71 overrides apply.
Code: agreement_factory service; template registry; populate pipeline; e-sign adapter; assent writer joining LE-01; gates on publish/pay for role packs.
Data: agreement_templates; agreement_emits; esign_envelopes; esign_events; assent join keys; final_pdf_sha256. Prefer vendor refs for ID docs — not raw vault dumps in the factory log.

Lost vs fixed#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Generate a Creator pack while KYC is pending — should refuse.
   
2. Complete e-sign — does assent row show template_version + envelope id?
   
3. Attempt payout with only an unsigned Drive PDF — gate fail?
   
4. Custom exclusivity change without LE-71 deal_id — blocked?
   
5. Export one executed pack zip (PDF hash + events + assent join).

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Formation UX / assent schema — Chapter 2 (LE-01).
  
• Dispute clause versions — Chapter 2B (LE-68).
  
• Unified payee diligence — Chapter 8B (LE-73).
  
• Custom creator Deal OS — Chapter 13B (LE-71).
  
• Pattern Map LE-76 — Chapter 32.

Field rule — put this on the release checklist: Agreements are emitted artifacts with joins — not PDFs that wandered in from email.

This chapter is for education and discussion. It isn’t legal advice. No client names or deal values appear in this teaching reconstruction.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 3 — Worked Example: ROSCA / Easy Cancel (Lost vs Fixed)#

Pattern family: Negative-option enrollment and simple cancellation (LE-03; overlays LE-04 CA ARL, LE-05 trial/price display)
Legal anchors: Restore Online Shoppers’ Confidence Act (ROSCA) § 8403, 15 U.S.C. §§ 8401–8405; FTC Act § 5; California Automatic Renewal Law, Bus. & Prof. Code §§ 17600 et seq. (esp. § 17602, including AB 2863 amendments for contracts on/after July 1, 2025); FTC v. Match Group enforcement themes (simple cancel; no dispute retaliation).
As of September 2026: FTC 2024 Negative Option (“Click-to-Cancel”) Rule amendments were vacated (Custom Communications v. FTC, 8th Cir. 2025); Commission restarted with a 2026 ANPRM. Design to the ROSCA + § 5 + state ARL floor, not the vacated text.

A fact pattern that makes the duty real#

Imagine an ecommerce subscription site — call it FitBox Monthly. Checkout is slick. Three taps on a phone: pick a plan, enter a card, tap Start free trial. The button says “$0 today.” Post-trial price, billing interval, and “renews until you cancel” sit below the fold or only inside a linked Terms PDF. The user never checks an affirmative renew box; scroll and tap are treated as enough.

Thirty-five days later, a $49.99 charge hits the card. The user wants out. Account → Billing shows Manage plan, which opens a chat bot that offers a 20% discount and never shows a cancel control. Phone cancel is “available during business hours.” A support ticket is created; nothing writes an effective date. Soft-decline retries and the next renewal still fire. When the user disputes the charge with the bank, the account locks “for fraud review” and core features stay frozen until the dispute is dropped.

That pattern is why negative-option enforcement exists. Under ROSCA, before you take billing information you need clear, conspicuous disclosure of material terms; before you charge you need express informed consent; and you need simple mechanisms to stop recurring charges. FTC Act § 5 and state automatic-renewal laws (especially California’s ARL) attack the same product story from unfairness and dark-pattern angles: cancel harder than signup, phone-only after online enroll, retention mazes that hide cancel, billing that continues after the consumer said stop.

Enforcement themes in public FTC negative-option and ROSCA matters — and in Match-shaped cancel / dispute-retaliation themes — keep returning to that consumer experience: easy to join online, hard to leave, charges that outlive the “cancel request.” Treat those as themes for orientation; re-check captions and holdings with counsel for your facts. Do not counsel vacated 2024 Part 425 text as live law.

What went wrong at FitBox was not a missing paragraph in the Terms. It was Interface (disclosure and cancel path), Code (renewal job ignoring cancel), and Data (no exportable consent or cancel row). The checklist at the end of this chapter only helps after you see that ending.

Illustrative reconstructions for teaching. Not exhibits. Not official screenshots of any party’s product. Match-shaped themes below are public enforcement themes (complaint and later settlement press), not a claim that your product resembles any defendant’s UI.

If Chapter 2 was “can we prove they agreed,” this chapter is “can they leave as easily as they arrived — and does billing actually stop?”

How Law Engineering would have changed the ending#

Walk the same FitBox facts through Interface, Code, and Data.

Interface — notice and an exit that is real. Before the user enters a card or taps Start, the screen shows recurring nature, amount, interval, trial length, post-trial price, and how to cancel — in visual proximity to the consent control, readable on a small phone. Consent is affirmative (unchecked checkbox or an equally clear counsel-approved CTA), not scroll-wrap hope. Cancel lives under Account → Billing within a few taps. Online enrollments complete cancel online. If a save offer appears, the cancel control stays visible and enabled at the same time. Confirmation screen plus a retainable email or in-app receipt states end date and last-charge status.

Code — the renewal job listens. subscription.create requires disclosure_version_id + consent_event_id. An authenticated Cancel API sets cancel_effective_at without a human agent and returns the effective date. Charge, renewal, and dunning jobs skip when cancel_effective_at <= now. Feature flags for “save offer” cannot remove the cancel CTA. Dispute or chargeback status does not lock core account features as retaliation.

Data — the pack you’d hand a CID. Versioned disclosure rows with content hash and structured amount/interval/trial fields. Append-only negative-option consent events (surface, action type, IP/UA, UI archive id). Cancellation rows with cancel_requested_at, cancel_effective_at, channel, retention-offer flags, confirmation message id. Join those to the charge log for one user_id without grepping Zendesk.

That is the aha: ROSCA’s “simple mechanisms” and ARL’s “without steps that obstruct or delay” are product tests. A ticket that never wrote cancel_effective_at is not a simple mechanism. Phone-only cancel after online signup is a classic red flag. Better data — timestamps, versions, hashes, and a path to a declaration — designed well in advance is what changes the hearing or the CID response.

Negative-option offers are recurring charges that continue until the consumer stops them. On the internet they sit on a three-part ROSCA floor:

1. Clear and conspicuous disclosure of material terms before you collect billing information.
   
2. Express informed consent before you charge.
   
3. Simple mechanisms to stop recurring charges.

State automatic-renewal laws often harden the same themes: retainable acknowledgment, same-medium cancel for online enrollments, and (online) a simultaneous prominent cancel control when you show a retention offer. Law Engineering’s job is one continuous path: enroll → disclose → consent → cancel → evidence — and a billing job that actually stops when cancel is recorded.

Side A — What loses (the cancel maze)#

What goes wrong: The user signed up in three taps online. Cancel requires a phone queue during business hours, a “chat with retention” dead-end, a ticket that never sets an effective date, or a guilt screen that hides the cancel control. Renewals and soft-decline retries keep firing. In dating and other high-friction stacks, a chargeback can also trigger account lock or feature hostage — Match-theme unfairness territory.

Why this matters in court / before a regulator: ROSCA’s “simple mechanisms” and CA ARL’s “without steps that obstruct or delay” are product tests, not brochure tests. Phone-only cancel after online signup is a classic red flag. Cancel harder than signup is a dark-pattern tell under § 5 / ARL / (for privacy consent) CPRA overlays — don’t conflate those hooks, but don’t ignore any of them.

Lawyer lens: When the CID arrives, you need disclosure version, consent event, cancel request/effective timestamps, channel, and charge log reconciled to the consent window. A Zendesk ticket that never wrote cancel_effective_at isn’t a simple mechanism.

Engineer lens: If subscription.create doesn’t require disclosure_version_id + consent_event_id, or if the renewal job ignores cancel_effective_at, the UI story is incomplete paper compliance.

Non-compliance checklist (red flags)#

• Material terms (price, interval, trial length, post-trial price, “renews until canceled”) missing or below the fold relative to Pay/Subscribe on mobile
  
• Pre-checked renew consent; “$0” / “Free” CTA that omits conversion price
  
• Online signup → phone-only, mail-only, or chatbot-only cancel that never calls a cancel API
  
• Retention / save offer that hides or disables cancel (CA ARL wants simultaneous prominent click-to-cancel online)
  
• Cancel “request” that leaves renewals and dunning alive
  
• Account lock / feature hostage after billing dispute or chargeback
  
• No exportable disclosure bytes, consent row, or cancel confirmation receipt

Side B — What works better (easy cancel that cancels)#

What works better: Before submit, the user sees recurring nature, amount, interval, trial/promo length, post-trial price, and how to cancel — in visual proximity to the consent control. Consent is affirmative (unchecked checkbox or equally clear counsel-approved CTA) — not scroll-wrap hope. Cancel lives in Account → Billing within a few taps; online enrollments complete cancel online; confirmation screen + retainable email/in-app receipt states end date / last charge status. If you show a save offer, the cancel control stays visible and enabled at the same time.

Code gates (from LE-03):

Data worth keeping: versioned disclosure rows with content hash and structured amount/interval/trial fields; append-only negative-option consent events (surface, action type, IP/UA, UI archive id); cancellation rows with cancel_requested_at, cancel_effective_at, channel, retention-offer flags, confirmation message id. Retention: align to the longer of ROSCA practice, CA ARL (often ≥ 3 years or 1 year after termination), and counsel’s map.

Compliance checklist (green flags)#

• Disclosures visible without hunting on 320–390px widths
  
• Affirmative consent bound to the disclosure version shown
  
• Online cancel completes online; signup friction ≥ cancel friction (document the tap counts)
  
• Confirmation + receipt; renewals suppressed in the same release
  
• Chaos test: cancel, then force the renewal job — expect SKIPPED_CANCELED
  
• In-app purchase (IAP) dual-path documented (store manage deep-link + in-app status sync)
  
• No retaliation path on dispute/chargeback

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show before charge): recurring nature; amount + interval; trial length + post-trial price + first paid charge timing; how to cancel; affirmative consent control; mobile visibility next to CTA.
Interface (cancel): short path from account/billing; online completion; confirmation + receipt; simultaneous cancel control with any save offer.
Interface (must-not): pre-checked renew; phone-only after online signup; confirm-shaming that disables cancel; cancel tickets without effective dates; dispute retaliation.

Code: gates G1–G5 above; acceptance-style tests for enroll-with-disclosure, block-without-consent, online cancel, retention UX, post-cancel charge skip, evidence export.

Data: subscription_disclosures, negative_option_consents (append-only), subscription_cancellations; counsel sign-off id on disclosure versions; immutable enough for a tabletop CID.

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Screenshot enroll and cancel on a small phone. Count taps signup vs cancel.
   
2. Complete cancel as a real test user. Did cancel_effective_at land? Did a renewal job still charge?
   
3. Turn on the save offer. Is cancel still on-screen and enabled?
   
4. Ask counsel for one SKU’s disclosure version id. Can engineering join it to consent and charges in under an hour?
   
5. If cancel is “email us,” you don’t have LE-03 yet — you have a hope queue.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Privacy tag congruence (pixels that fire vs what the policy discloses) — Chapter 4.
  
• CA ARL overlay depth (LE-04) and free-to-paid trial display (LE-05).
  
• Chargeback evidence bundles (LE-26) that reuse the same consent/cancel rows.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 4 — Worked Example: Privacy Policy ↔︎ Live Tags / SDKs (Lost vs Fixed)#

Pattern family: Privacy notice congruence and tag/SDK gating (LE-41 congruence scanner; LE-08 CMP / pixel gating; LE-07 sale/share / GPC)
Legal anchors: FTC Act § 5 privacy unfairness/deception when practices ≠ notices; CCPA/CPRA notice-at-collection, sale/share, and GPC themes; cookie/SDK classification and dark-pattern consent UX; GDPR Arts. 13/14 transparency and ePrivacy-style consent for non-essential cookies where the product reaches the EEA/UK.
As of September 2026: US sale/share opt-out isn’t the same legal machine as EU cookie consent — region packs live in LE-42.

A fact pattern that makes congruence real#

Illustrative reconstructions for teaching. Not exhibits. Not official screenshots of any party’s product.

Picture a polished privacy policy PDF that lists “our analytics provider” and a handful of named vendors. Now open the live site in a private window and watch the network tab before anyone touches the cookie banner. A dozen third-party hosts phone home. Some never appear in the PDF. Marketing added a “temporary” pixel last sprint. Growth shipped an ad SDK in the app binary. Server-side tag manager still fires partners the CMP never heard of.

That gap is this chapter. FTC Act § 5 theories often start from a simple sentence: you told consumers one thing; the stack did another. State sale/share and GPC themes, and EU-style consent for non-essential cookies where you reach those users, harden the same product problem from different angles.

DoubleClick was an early lesson in what happens when clickstream and identity try to become one profile without a matching notice story. (I was co-lead settlement class counsel in that matter; past work is teaching context, not advice for your facts.) Congruence between what you disclose and what the stack fires is not optional.

Congruence means the privacy story you publish matches the tracking that actually runs. If those two diverge, you have a Law Engineering problem — Interface (CMP and notices), Code (tags that wait for permission), and Data (an approved vendor register you can export) — not a drafting typo.

What the law is asking the product to do#

Privacy law is increasingly a congruence problem, not a drafting problem.

• If the policy (or notice at collection) says who receives personal information and for what, the live inventory of pixels, software development kits (SDKs), and server-side endpoints should match that story.
  
• If the region requires consent before non-essential tracking, those tags must not initialize until category permission exists.
  
• If the business sells or shares for cross-context behavioral advertising, opt-out and GPC / Sec-GPC must suppress the same vendors end-to-end — not decorate a footer while ads keep firing. GPC (Global Privacy Control) is a browser signal that means “don’t sell or share my personal information.”
  
• FTC § 5 theories often start from a simple sentence: you told consumers one thing; the stack did another.

Law Engineering’s goal: an approved vendor register + policy version + CMP/gates + a scanner that diffs live inventory and can fail a deploy or open a severity ticket when they drift.

A CMP (consent management platform) is the banner and preference center that records category choices and, if wired correctly, tells loaders what may run.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (paper compliance)#

What goes wrong: Marketing adds a “temporary” Meta/Google/TikTok pixel. Growth ships ad SDKs in the next app binary.

Someone pastes a partner into server-side Google Tag Manager (GTM). The privacy policy still lists Vendor A and “our analytics provider.” On first paint — before the CMP — HTTP Archive (HAR) capture shows a dozen third-party calls.

GPC is ignored or half-honored. Reject All is a tiny link under bright Accept All.

Annual “legal review” is a PDF diff that never sees production.

Why regulators and plaintiffs care: Undisclosed or pre-consent tracking supports § 5 deception/unfairness narratives; CCPA/CPRA notice and sale/share failures; GDPR/ePrivacy transparency and cookie-consent failures. Dark-pattern consent (reject harder than accept; pre-checked non-essential) weakens the consent story. COPPA-adjacent surfaces that still load behavioral tags are a sharper, separate mode (LE-09).

Lawyer lens — what I’d ask on the call: When an AG or California Privacy Protection Agency (CPPA) letter asks “what fired on date T?”, a Word policy isn’t an answer. You need inventory snapshots, consent strings, allowlist hashes, and a diff against the policy schedule that was public that day.

Engineer lens: If tags are hard-coded in index.html, or native SDKs init in Application.onCreate before reading consent flags, the CMP is a sticker on a firehose — incomplete, not a real gate.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Tags / SDKs / conversion-API (CAPI) endpoints live in prod but absent from the public policy schedule or vendor register
  
• Non-essential marketing pixels in the first network burst before consent (consent regions) or despite GPC / Do Not Sell or Share (DNS-Share) (sale/share contexts)
  
• “We don’t sell” UI while share-for-ads continues
  
• Pre-checked non-essential categories; Accept prominent / Reject buried
  
• Mobile binary SDK list never mirrored in the web-centric policy
  
• Server-side GTM / partner pixels unscanned
  
• Annual manual PDF review as the only control; no CI or runtime brake
  
• “Approve all” vendor tickets with no owner_team

Side B — What works better (CMP gates + congruence scanner)#

What works better: Every vendor has a row: legal name, category (Essential / Analytics / Ads / …), role (service provider / contractor / third party / cross-context behavioral advertising (CCBA) — as counsel classifies), data processing agreement (DPA) status, policy schedule reference, owning team.

The public cookie/SDK list is generated from that register, not hand-edited in parallel. A CMP (config-as-code) gates non-essential loaders.

Edge middleware reads Sec-GPC where required and sets suppress flags before non-essential tags load (LE-07). Kill switches can disable a vendor globally in minutes even if the CMP misbehaves.

Congruence scanner (LE-41):

Fixed user story: Fresh visit in a consent region → no marketing third parties until Accept (by category). Reject All is as easy as Accept All where counsel requires symmetry. CA visitor with GPC on → sale/share vendors suppressed and the preference center says so. Staging pull request that adds an unlisted pixel → CI red. Counsel dashboard: policy version vs inventory snapshot vs diffs, exportable for the date of an inquiry.

Compliance checklist (green flags)#

• Single source of truth: register → policy schedule → CMP allowlist
  
• Wrapper pattern: if (!allow(vendor)) return; before script inject / SDK init
  
• Server-side pixels and in-app WebViews on the same consent bridge
  
• Equal-prominence Reject where required; no non-essential pre-checks
  
• GPC honored without forcing account creation
  
• Immutable vendor_inventory_snapshots + congruence_diffs + cmp_consent_events
  
• Ownership so marketing can’t silent-ship vendors
  
• Child-directed modes: empty non-essential inventory (or affirmative auth per counsel)

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): CMP with category toggles; symmetrical Reject/Accept where required; link to cookie/SDK list; footer “Cookie settings” reopen; preference-center status when GPC is honored; DNS-Share entry unless counsel documents a signal-only path; mobile App Tracking Transparency (ATT)/SDK permission UX that doesn’t silently init ad SDKs.

Interface (must-not): Pre-checked non-essential; Accept-only walls without a required reject path; hard-coded marketing tags in templates; claiming no sale while share-for-ads continues.

Code: LE-08 gates (wrapper, mobile init, server-side check, CI register check, kill switch); LE-07 GPC/DNS suppress; LE-41 CI + runtime congruence; QA acceptance tests for pre-consent quiet, reject-all, category accept, GPC+CMP, WebView bridge, evidence export.

Data: vendor_register; vendor_inventory_snapshots; congruence_diffs; deploy_gates; cmp_consent_events (consent string, categories, region, gpc_honored, allowlist snapshot id); vendor_runtime_blocks. Retain immutable snapshots on a multi-year defense horizon counsel sets.

Failure modes worth chaos-testing#

Failure mode — Cookie Settings control that does nothing#

A cousin of paper compliance: the footer promises Cookie Settings (or Your Privacy Choices), but the link is #, a 404, or a static cookie policy with no toggles. The CMP never opens. GPC may still be claimed in the privacy narrative while sale/share tags fire.

Why this matters in court / before a regulator: Congruence isn’t only “vendors named ↔︎ vendors loaded.” It’s also “controls promised ↔︎ controls that work.” A dead settings entry is a user-facing break in the same family as undisclosed pixels (LE-08 / LE-07 / LE-41).

Lost pattern — I’ve seen this movie: Footer link → policy PDF. No preference UI. Reject/Accept happened once on first visit (or never); the shopper can’t reopen choices. QA never clicks the footer.

Fixed pattern — here’s what I want you to ship: Footer Cookie Settings opens the same working CMP/preference center that gates vendors. Guest-accessible where counsel requires. When GPC is on, the UI says so. Synthetic QA clicks the footer on every staging deploy; label “Settings” can’t point at a policy-only URL. If the CMP is down, show an honest unavailable state and page counsel — don’t silent-404.

Add to tomorrow’s checklist: click Cookie Settings in a private window. If nothing interactive appears, you have a congruence defect even when the vendor register is clean.

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Open a private window. Capture HAR before touching the banner. Circle every third-party host.
   
2. Diff that list against your public privacy/cookie schedule. Extra names are LE-41 findings.
   
3. Enable GPC (or send Sec-GPC: 1 in a test profile). Do sale/share pixels still load?
   
4. Ask: who can add a vendor without a legal ticket and a register row? If “anyone with GTM access,” congruence is optional — and optional congruence fails.
   
5. Export one day’s inventory snapshot. If you can’t, you aren’t ready for the letter that assumes you can.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• CIPA / session replay / prior consent — Chapter 4B (LE-53). Same vendor wrappers help, but wiretap-class prior consent is a different theory from CMP congruence and notice schedules.
  
• Regional UX packs (LE-42) so US opt-out and EU consent stay separate machines.
  
• COPPA / age-gate tag kill (LE-09 / LE-10) on child-directed paths.
  
• Later chapters that compress LE-06…LE-08 + LE-41 into release checklists.

This chapter is for education and discussion. It isn’t legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 4B — Worked Example: CIPA, Session Replay & Prior Consent#

Pattern family: California Invasion of Privacy Act (CIPA) prior consent for session replay, third-party chat transcripts, and content-learning analytics (LE-53). Adjacent — not identical — to privacy tag congruence and CMP gating (LE-41, LE-08, LE-07; Chapter 4).
Legal anchors (themes): Cal. Penal Code §§ 631 (wiretap / learn contents in transit), 632 (confidential eavesdropping), 632.7 (cellular/cordless — no confidentiality requirement in the classic telling; mobile web traffic themes), 637.2 (civil damages themes — often pleaded as $5,000 per violation or 3× actual damages — Verify); Flanagan v. Flanagan, 27 Cal. 4th 766 (2002) (§ 632 confidential-communication themes); Popa v. Harriet Carter Gifts, 52 F.4th 121 (3d Cir. 2022) (persuasive PA wiretap party/eavesdropper analogy — note CA district divergence); Kearney v. Salomon Smith Barney, 39 Cal. 4th 95 (2006) (extraterritorial / CA-resident reach themes); Ninth Circuit prior-consent themes for § 631 (footer/browsewrap insufficient; affirmative conspicuous disclosure before interception — themes, not an invented reporter cite here).
As of September 2026: Re-check operative Penal Code text, your forum’s pleading posture on session replay / chat / pixels, and counsel’s party-vs-tool classification before shipping a banner that claims you’re “done” with CIPA.

Why this memo exists#

Are we recording keystrokes and clicks before the user said yes?

Session replay is a new costume on an old problem: capturing behavior the user never agreed to watch. Prior consent — or don’t load the script.

The story in one glance#

Picture a shopper who never touched a cookie banner.

The homepage paints. A session-replay script starts streaming mouse moves, clicks, scroll depth, and — on the checkout form — keystrokes. A live-chat bubble opens a third-party transcript pipe. An analytics pixel reads field values as “content.” The privacy policy PDF still says “we use cookies to improve your experience.” The CMP, if it appears at all, only mentions Analytics and Ads.

That gap is this chapter.

Session replay is a new costume on an old problem: capturing behavior the user never agreed to watch.

Chapter 4 taught congruence: the policy schedule must match the live vendors, and non-essential tags wait for category permission. This chapter is a different theory.

Plaintiffs plead CIPA as wiretap / eavesdropping — that the stack learned the contents of a communication in transit, or eavesdropped on a confidential session, without prior consent.

A beautiful CMP that never disclosed “we record your session” is incomplete for that fight.

Walk this with one private window and the network tab open. Ask three questions. Did anything that records or learns contents load before an affirmative Accept? Can counsel prove consent_at before first_replay_init_at? If the visitor hits Reject, do FullStory, Hotjar, chat, and content pixels stay dark?

Law Engineering’s answer is prior consent as a gate — Interface names the recording, Code blocks init until Accept, Data proves the order.

Teaching reconstructions only. Not screenshots of any party’s live product and not exhibits.

Plain English — what CIPA is, and why ecommerce “eavesdrops” in the complaint#

CIPA is California’s Invasion of Privacy Act — older wiretap and eavesdropping rules in the Penal Code, with a private right of action. In the ecommerce telling, the “communication” is the visitor’s session with your site: pages, forms, sometimes chat. The “eavesdropper” in the pleading is often a third-party vendor that receives mouse movements, clicks, typed input, or chat text while the visit is underway.

Plaintiffs say that looks like learning contents in transit (§ 631 themes) or eavesdropping on a confidential communication (§ 632 themes). On mobile web, § 632.7 themes show up too — and that provision’s classic telling does not require the same confidentiality showing.

Damages under § 637.2 are often pleaded at $5,000 per violation or three times actual damages. Treat those figures as a Verify flag: re-check the statute and current pleading practice for your matter.

The engineering implication is blunt either way — per-visitor exposure narratives make “we’ll fix the banner next quarter” an expensive habit.

This is not only a privacy-notice problem. You can name every vendor in a schedule and still face a CIPA story if recording began before consent.

What the law is asking the product to do (themes)#

Orient to four design pressures. Counsel owns the final map for your facts.

1. § 631 themes — contents in transit. If a tool intentionally learns what the visitor is sending while the session runs, prior consent of the parties is the statutory theme. Session replay and content-aware form analytics are the usual product suspects.
   
2. § 632 themes — confidential eavesdropping. Flanagan themes ask whether the participant reasonably expected the conversation was not being overheard. Account forms, checkout, chat with support — design as if expectation of privacy is live until counsel says otherwise.
   
3. § 632.7 themes — mobile / cordless lineage. Pleadings often reach mobile web traffic under this section’s themes without the same confidentiality gate. Don’t ship a desktop-only consent story.
   
4. Prior consent before interception. Ninth Circuit prior-consent themes for § 631 push toward affirmative, conspicuous disclosure before the tool loads. Footer Terms, browsewrap, or “by continuing you agree” buried under the fold is a weak sole theory. Accept must be real; Reject must work.

Party vs eavesdropper. Vendors sometimes argue they are a tool of the site (one party’s tape recorder), not an independent eavesdropper. Popa v. Harriet Carter Gifts, 52 F.4th 121 (3d Cir. 2022), is a persuasive Pennsylvania wiretap analogy on that family of facts — useful for orientation, not binding CIPA law. California district courts diverge on similar session-replay and pixel stories. Law Engineering posture: encode prior visitor consent and clean contracts anyway; don’t bet the release on “we’re a party” alone without counsel’s written classification.

Reach. Kearney v. Salomon Smith Barney, 39 Cal. 4th 95 (2006), themes remind you that California residents can sit at the center of the story even when servers or vendors sit elsewhere. Geo and profile scoping belong in the gate design.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (tools on first paint)#

What goes wrong: Marketing installs session replay “for UX research.” Support embeds a third-party chat bubble that stores every transcript by default.

Growth adds a pixel that scrapes form fields for funnel analytics. All three load in the first network burst.

The cookie banner — if any — talks about Analytics and Ads. It never says recording.

Reject All leaves replay running because someone marked it Essential. The privacy policy lists “service providers” in the abstract.

When a demand letter asks for the moment consent preceded first intercept, the export is empty.

Why CIPA themes care: The complaint writes itself as wiretap / eavesdropping without prior consent — not as “please update your cookie schedule.” § 637.2 damages themes turn each quiet session into a number. Mobile visitors amplify § 632.7 themes. Out-of-state infra doesn’t erase Kearney resident-reach themes.

Lawyer lens — what I’d ask on the call: A Word policy and a CMP config screenshot are incomplete. You need disclosure text (hashed), Accept events, and init timestamps that prove order. If the vendor is an independent third party learning contents for its own purposes, party-consent theories get harder — classify before you ship, and still gate.

Engineer lens: If FullStory / Hotjar / chat snippets sit in index.html or init in Application.onCreate before reading cipa_consent, the banner is a sticker on a firehose. If “Accept all cookies” sets a flag that never mentioned session recording, you bridged the wrong legal machine.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Session replay, chat transcript, or content-learning pixels in the first paint before affirmative Accept
  
• Footer / browsewrap / buried Privacy Policy as the only “consent”
  
• Pre-checked Accept; Reject harder than Accept; Reject that still leaves replay on
  
• Replay labeled Essential to bypass CMP
  
• EU cookie Accept treated as CIPA consent without recording disclosure
  
• No consent_at / first_replay_init_at ordering proof
  
• No CIPA-sensitive vendor register or kill switch
  
• Desktop banner only while mobile WebView loads native SDKs dark

Side B — What works better (disclose → Accept → then load)#

What works better: Counsel lists every CIPA-sensitive vendor on a register: session replay, chat, form/content analytics, heatmaps that capture DOM text.

On first visit (CA-scoped or counsel-scoped), a banner or modal names the behavior before those scripts exist in the page. Affirmative Accept (not pre-checked).

Reject as usable as Accept. Details link explains what is recorded, who receives it, and how to withdraw.

Code wrappers refuse init until cipa_consent_at. Data stores consent_version, disclosure_hash, consent_at, first_replay_init_at, vendor_id — and CI fails if init precedes consent.

If counsel splits CIPA from EU cookie categories, keep separate events and copy. A visitor can accept strictly necessary cookies and still Reject session recording. If counsel combines them, the combined disclosure must actually say recording / content learning — not only “analytics.”

Fixed user story: Fresh visit → quiet network for CIPA-sensitive hosts → visitor reads short disclosure → Accept → only then does replay/chat/content analytics init → export shows consent timestamp earlier than first init. Reject → those hosts never appear. Kill switch can darken a vendor in minutes when classification or copy changes.

Compliance checklist (green flags)#

• Disclosure names session replay / chat recording / content analytics in plain English
  
• Accept affirmative; Reject real; no pre-check
  
• Wrappers block FullStory / Hotjar / chat / content pixels until consent
  
• Separate from EU categories when counsel splits
  
• Register + kill switch + owner_team for every CIPA-sensitive vendor
  
• Evidence: disclosure_hash, consent_at before first_*_init_at
  
• Mobile WebView / native SDK on the same consent bridge
  
• Public policy schedule lists the same vendors (Chapter 4 congruence)

When this lands in court or before a regulator, better data wins. Design the export — timestamps, versions, hashes, and a path to a declaration — well in advance.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): Banner/modal before CIPA-sensitive tools load; plain-English recording disclosure; affirmative Accept; Reject; working Details link; reopen/withdraw path; mobile-equivalent UX.

Interface (must-not): Browsewrap-only; pre-checked Accept; Accept-only with buried Reject; silent first-paint replay; “essential” mislabel; details that never mention recording.

Code: Block vendor init until cipa_consent; optional split from CMP category flags; inventory register; kill switch; CI/HAR assert pre-consent quiet and consent-before-init ordering; server-side paths honor the same flag.

Data: consent_version, disclosure_hash, consent_at, first_replay_init_at (and chat/pixel siblings), vendor_id, ui_surface, register snapshot. Retain on the defense horizon counsel sets.

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Lost vs fixed (scene card)#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Private window. Capture HAR before any click. Circle session-replay, chat, and form-analytics hosts.
   
2. Read your banner aloud. Does it say you record the session or learn form contents — or only “cookies”?
   
3. Click Reject. Do those hosts still appear?
   
4. After Accept, export one row: consent_at and first_replay_init_at. Which is earlier?
   
5. Ask who can paste FullStory in GTM without a register row and a kill switch. If “anyone,” CIPA gating is optional — and optional gating fails.
   
6. Repeat on a phone-sized WebView. § 632.7 themes don’t care that your desktop banner looked fine.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Privacy policy ↔︎ live tags / CMP congruence — Chapter 4 (LE-41, LE-08, LE-07). Same wrappers help; CIPA is still a wiretap-class theory, not only notice congruence.
  
• Multi-jurisdictional privacy UX packs — Chapter 30 (LE-42) when CA CIPA disclosure sits beside EU cookie categories.
  
• Formation-style evidence instincts (version, hash, surface, time) — Chapter 2 (LE-01).
  
• Operating model / release gates — Chapter 31. Pattern Map LE-53 — Chapter 32.

This chapter is for education and discussion. It isn’t legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 5 — Worked Example: Age Verification + TAKE IT DOWN (Lost vs Fixed)#

Pattern family: State adult-content age verification (LE-10) + federal TAKE IT DOWN Act notice-and-removal (LE-11)
Legal anchors: State adult AV statutes (e.g., Tex. Civ. Prac. & Rem. Code ch. 129B / H.B. 1181; La. R.S. 9:2800.28; Fla. Stat. § 501.1737); Free Speech Coalition, Inc. v. Paxton, 606 U.S. ___ (June 27, 2025) (upheld Texas AV under intermediate scrutiny — does not auto-validate every sister statute or every vendor method); TAKE IT DOWN Act, Pub. L. No. 119-12 (May 19, 2025) → 47 U.S.C. § 223(h) (criminal) and § 223a (platform N&R; process by May 19, 2026; FTC enforcement from that date).
As of September 2026: Keep a state matrix and method allowlist current; re-check FTC penalty adjustments and injunction status before quoting numbers in a matter.

Two duties that get mashed into one ticket#

Illustrative reconstructions for teaching. Not exhibits. Not official screenshots of any party’s product.

Picture two product meetings that get collapsed into one “safety UX” ticket. In the first, a covered state asks: who may enter adult material? In the second, a federal statute asks: how do nonconsensual intimate images leave within 48 hours?

On the lost side, a visitor taps Enter behind a lone “I’m 18+” checkbox. Thumbnails and signed media URLs load without a verified age state. Intimate-image reports land in the copyright form, or soft-hide without a CDN purge, and nobody can show a 48-hour clock.

Adult and mixed UGC — and dating hybrids — often need both stacks. They are not the same machine. One is a gate in. The other is a clock out. Clocks and verification are not Terms poetry. They are product surfaces with fail-closed behavior and exportable decisions.

Ask of one covered URL: who may enter — and how does nonconsensual intimate imagery leave within 48 hours?

Why these two patterns travel together#

Age verification (AV) and intimate-image removal solve different legal problems. Teams collapse them into one checkbox and ship neither correctly.

Field rule — put this on the release checklist: AV is a gate in. TIDA (TAKE IT DOWN Act) is a clock out. One evidence pack doesn’t replace the other.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses#

Don’t ship this. If your current build matches Side A, stop the release train and fix it with counsel.

AV (LE-10) failure mode#

What goes wrong: User taps Enter. A pre-checked or lone checkbox says “I’m 18+.” Thumbnails and signed media URLs work without a verified av_status=passed. If the product collects a government ID at all, the scan lives in application storage “for fraud.”

Why statutes care (theme): Template state laws (LA/TX-style and peers) typically trigger when a substantial portion — often more than one-third — of the site/app is sexual material harmful to minors. Methods commonly include digitized/government ID, commercially reasonable transactional data, and (in Florida) an anonymous option alongside standard verification. Many statutes pair the duty with no retention of identifying information after access is granted. Checkbox assent isn’t that architecture.

Lawyer lens — what I’d ask on the call: After Paxton (2025), facial First Amendment challenges to Texas-style AV are harder — but counsel still needs a state matrix, a documented substantial-portion methodology, and a method allowlist. Overreading Paxton as a nationwide blessing for estimation-only vendors is a research error — estimation compliance is state-specific / often unsettled and needs counsel sign-off for your method and geo.

Engineer lens: If media URLs issue whenever the session cookie exists, you built a banner — not AV.

TIDA (LE-11) failure mode#

What goes wrong: Intimate-image reports require login, live three menus deep under “Other,” or land in a copyright form that demands ownership swearing. Support replies “we’ll look into it.” Soft-hide leaves the object publicly reachable. Duplicates are the victim’s problem.

Why the statute cares (theme): Under § 223a, covered platforms (public UGC forums, or entities that regularly host/curate nonconsensual intimate imagery (NCII)) needed a process by May 19, 2026. A valid written request needs signature, locate info, good-faith nonconsent statement, and contact. Clock: remove ≤ 48 hours and make reasonable efforts on known identical copies. FTC treats unreasonable noncompliance as a rule-defined UDAP violation; May 2026 materials cite civil penalties on the order of $53,088 per violation subject to 16 C.F.R. § 1.98 inflation adjustments. Verify (as of September 2026 — re-check before citing in a matter): penalty amount and inflation adjustment. Good-faith removal has a § 223a limitation on liability; it’s not the DMCA § 512 harbor.

Lawyer lens — what I’d ask on the call: TIDA § 3 does not create a private right of action against platforms on its face (FTC track). Victims may still use 15 U.S.C. § 6851, state NCII, and other law against publishers. Parallel intakes (DMCA, CSAM/NCMEC, state NCII) stay separate.

Engineer lens: If received_at is “when someone opened the email,” the 48-hour duty is unprovable.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Checkbox-only AV in covered states
  
• Scrapable full-res media without AV token
  
• Retaining raw ID images after pass contrary to non-retention design
  
• Intimate-image report path account-gated or >3 navigations from the media
  
• TIDA fields missing; tickets merged into DMCA
  
• No sla_deadline_at = valid_at + 48h
  
• Soft-hide without hard CDN/object disable
  
• No hash / identical-copy sweep log
  
• Marketing claims (“48-hour removal,” “anonymous AV”) that the stack can’t meet

Side B — What works better#

Here’s the build worth shipping — gates, records, and an export counsel can defend.

AV that can survive an audit (LE-10 theme)#

1. Counsel factual memo: Is this property in substantial-portion scope for which states? Enable list is a product flag counsel owns — not a growth experiment.
   
2. Geo → interstitial → vendor → webhook → unlock: Media/CDN signed URLs require av_session=passed for covered jurisdictions.
   
3. Method allowlist per state: Gov ID / transactional / Florida anonymous+standard where required. Face estimation only if counsel enables that state (estimation_allowed). Commercial stacks commonly implement the gov-ID path as document + liveness + face match, and return pass/fail or over-18 tokens rather than images — encode method codes and refuse disallowed ones server-side.
   
4. Non-retention: Prefer pass/fail tokens; purge raw artifacts on schedule; export jurisdiction, method, vendor, timestamps — not illicit ID bytes.
   
5. Separate COPPA (LE-09): Under-13 personal-information rules are a different regime.

Method depth: For statutory buckets vs vendor implementations (Texas-style gov-ID / transactional, Florida anonymous+standard, estimation step-up, webhook/token integration, biometric privacy and re-verification nuances), see the under-18 age-verification chapter later in this guide — this chapter keeps the AV+TIDA pairing; that chapter owns the method stack.

TIDA N&R that can survive an FTC letter (LE-11 theme)#

1. Coverage memo: UGC-forum prong vs. regular-course NCII prong; exclusions (broadband, email, incidental interactivity) read carefully — prong (II) isn’t saved by “incidental chat.”
   
2. Clear entry: “Report nonconsensual intimate image” (plain language), including non-account holders; in-content overflow preferred.
   
3. Statutory form fields map 1:1; incomplete → no SLA start; valid → confirmation / report number + received_at / valid_at / sla_deadline_at.
   
4. Remove + sweep: Hard disable; perceptual/cryptographic hash; child tickets for copies; re-upload blocklist.
   
5. Queues: TIDA ≠ DMCA ≠ CSAM (§ 2258A / NCMEC). Digital forgeries that meet the intimate-depiction tests are in the TIDA taxonomy — train Trust & Safety.
   
6. Export pack: Request payload, timeline, operator actions, sweep results, notice logs, manifest hash.

Compliance checklist (green flags)#

• Substantial-portion sign-off + state/method matrix
  
• CDN/API refuse without AV pass in covered geos
  
• Purge receipts for raw AV artifacts
  
• Non-account TIDA intake with four statutory elements
  
• Auditable 48-hour SLA + identical-copy standard operating procedure
  
• Separate DMCA / TIDA / CSAM routing
  
• Status messaging to reporters (removed / need more info / not covered)
  
• Counsel-tested evidence export for both LE-10 and LE-11

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (AV): Geo-triggered interstitial before covered media; method picker only from counsel allowlist; privacy explainer (what is checked / not retained); no checkbox-only path in covered states.

Interface (TIDA): Plain-language “Report nonconsensual intimate image” including non-account holders; statutory fields 1:1; confirmation / report number; status messaging (removed / need more info / not covered); menus distinct from DMCA and CSAM.

Interface must-not: Scrapable media without AV token; account-gated intimate-image report; soft-hide without CDN/object disable; marketing “48-hour” / “anonymous AV” claims the stack can’t meet.

Code (AV): Media/CDN signed URLs require av_session=passed in covered geos; refuse disallowed methods server-side; fail closed if vendor webhook signature fails — no checkbox fallback.

Code (TIDA): Dedicated intake → received_at / valid_at / sla_deadline_at = valid_at + 48h; hard disable + hash sweep jobs; separate queues from DMCA/CSAM; incomplete forms don’t start the SLA clock.

Data: AV — jurisdiction, method code, vendor, opaque token/session id, purge status (no illicit ID bytes). TIDA — request payload, timeline, operator actions, sweep results, notice logs, manifest hash. Export packs for both LE-10 and LE-11.

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. From a covered geo (or geo-spoof lab), request a media manifest before AV. Did you get bytes?
   
2. Complete AV; then ask storage: do we still hold the ID image?
   
3. As a logged-out person, find “Report nonconsensual intimate image” from a content page in ≤3 taps.
   
4. Submit a valid test request; export the ticket. Is removed_at ≤ valid_at + 48h? Are copy sweeps logged?
   
5. Open Report menus: Intimate image vs Copyright vs other abuse — three different forms?

If step 1 serves media, or step 4 can’t export a clock, you have policy language — not Law Engineering.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• TIDA consent ledger & anti-weaponization (proof-of-consent, requester verify option, anti-weaponization) — Chapter 5B (LE-61).
• Method-stack depth for AV vendors and allowlists — under-18 age-verification chapter later in this guide.
  
• State NCII companion patterns (LE-12) and CSAM / NCMEC routing (LE-13) — orthogonal but operationally adjacent.
  
• DMCA intake kept parallel (LE-15).
  
• Chatbot / character products that also host media: Chapter 6 / LE-38 guardrails — don’t treat a system prompt as an AV or TIDA gate.

This chapter is for education and discussion. It isn’t legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 5B — Worked Example: TIDA Consent Ledger & Anti-Weaponization#

Pattern family: TAKE IT DOWN Act verification-centered consent ledger + anti-weaponization (LE-61). Deepens notice-and-removal (LE-11; Chapter 5). Sits beside adult UGC × card-network controls (LE-60; Chapter 10B), NCII reporting (LE-12; Chapter 20), and § 2257 producer recordkeeping (LE-14; Chapter 21).
Legal anchors (themes): TAKE IT DOWN Act, Pub. L. No. 119-12 → 47 U.S.C. § 223(h) (criminal) and § 223a (platform N&R; process by May 19, 2026; FTC enforcement). Valid written request themes: signature, locate info, good-faith nonconsent statement, contact. Remove as soon as possible but not later than 48 hours + reasonable efforts on known identical copies. Good-faith / “apparently unlawful” limitation themes when platforms act on requests. No statutory counter-notice analogous to DMCA § 512(g) — weaponization and due-process design pressure. Unsettled / counsel-owned: whether requester identity/liveness verification (when a contrary consent ledger entry is on file) is a lawful reading of collecting “relevant information to verify lack of consent.” Public-concern asymmetry: criminal § 223(h) vs civil N&R § 223a — different engines, same media object.
As of September 2026: Re-check FTC materials, penalty inflation, and counsel’s reading of requester-verification options before encoding any gate as “required by TIDA.”

Why this memo exists#

A consent ledger you never query is a prop. Weaponization thrives when removal is frictionless against consented catalogs — and when you can’t show a reasoned audit on the clock.

The story in one glance#

Picture a covered platform that already “does TAKE IT DOWN.”

There’s a Report Intimate Image button. Tickets get a 48-hour SLA. Hashes sweep known copies. Counsel can export a clock.

Then a removal request lands on an upload that already carries a proof-of-consent ledger entry: uploader government-ID + liveness + explicit consent capture, timestamps, vendor tokens from a KYC vendor — not a free-text “I consent” checkbox.

The requester refuses any identity check. Ops removes first and asks questions never.

Or the opposite: ops freezes for a week while Legal debates “apparently unlawful,” and the 48-hour clock dies in Slack.

Neither extreme is a program.

Walk this chapter with one intimate upload that already has a consent-ledger entry, and one removal request that conflicts with it. Ask three questions. Can you surface the ledger entry on the ticket in one click? Does the 48-hour clock still run while counsel weighs the conflict? If the requester refuses any identity check, what does your counsel-owned path do — remove, verify, or freeze forever?

This chapter deepens LE-11 into a verification-centered consent ledger and an anti-weaponization design: capture consent evidence when you publish intimate UGC; treat contrary consent as relevant information counsel may weigh; design requester verification as an optional, counsel-owned path when the ledger conflicts; keep the 48-hour clock honest; log the decision audit pack. Teaching reconstructions only — generic Brand / KYC vendor / analytics SDK language. No client names, incident dates, or message counts.

Plain English — clock out + ledger in#

Chapter 5 taught the split: AV is a gate in; TIDA is a clock out. LE-61 adds a third machine that sits under the clock:

Field rule — put this on the release checklist: A consent ledger is evidence you may weigh — not a veto of a valid § 223a request, and not a license to ignore the 48-hour duty while counsel “thinks about it.”

Remember: a Law Engineer is a licensed attorney with software and product expertise. Engineers build ledger schemas and clocks under that counsel’s oversight.

What the law is asking the product to do (themes)#

Orient to eight pressures. Counsel owns the final map — especially the unsettled requester-verification option.

1. Keep the LE-11 clock. Valid request → sla_deadline_at = valid_at + 48h; hard disable + identical-copy sweep. LE-61 doesn’t soften that clock.
   
2. Capture consent at publish for intimate UGC classes. Uploader gov-ID + liveness + explicit consent artifact → consent_ledger_entry with vendor method codes (KYC vendor tokens — not illicit ID bytes in the app DB).
   
3. Ledger is relevant information. When a removal request names media that already has a contrary consent entry, the ticket must surface that entry to the decisioning path.
   
4. Requester verification — counsel-owned option (unsettled). Some counsel read “relevant information to verify lack of consent” as allowing identity/liveness checks on the requester when a contrary consent ledger exists. Encode as a policy flag, not a hard statute claim. Fail closed on the clock either way: if you can’t complete verification inside the SLA design, remove (or counsel-approved hold with documented legal basis — rare).
   
5. No statutory counter-notice. Unlike DMCA § 512(g), TIDA doesn’t hand you a put-back ritual. Design anti-weaponization (rate limits, duplicate-request detection, fraud signals) without inventing a fake counter-notice harbor.
   
6. “Apparently unlawful” / good faith. When consent evidence is strong and the request looks abusive, document the good-faith analysis — don’t invent immunity folklore.
   
7. Public-concern asymmetry. Criminal § 223(h) themes and civil N&R § 223a are different engines. Don’t train ops that “public interest” macros override a valid N&R ticket.
   
8. Decision audit pack. Every remove / retain / escalate decision exports: request fields, ledger hit/miss, verification steps attempted, operator/counsel id, timestamps, copy-sweep results.

Sibling engines: Card-network depicted-person consent (LE-60) and § 2257 packages (LE-14) may reuse verification events — they don’t replace the TIDA ledger or the 48-hour router (LE-11 / LE-12).

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“remove everything / ignore the ledger”)#

What goes wrong: Intimate uploads unlock on a ToS checkbox. Consent text is free-form and unstored.

Removal requests auto-remove with no ledger lookup. Competitors and ex-partners learn that a one-line form deletes a rival’s catalog.

Or Legal freezes every ticket that mentions “I consented” for seven days while the SLA bleeds. Requester identity is never asked even when the ledger screams conflict.

Decision reasons live in Slack. Identical-copy sweeps skip because “consent might exist somewhere.” Staff treat criminal and N&R paths as the same macro.

Why this matters in court / before a regulator: § 223a still expects a clear process and a clock. Weaponization thrives when removal is frictionless against consented catalogs and when platforms can’t show a reasoned audit. Freezing past 48 hours without a documented legal basis is the other failure. A ledger you never query is a prop.

Lawyer lens — what I’d ask on the call: You need a decision tree counsel owns — not vibe-based “protect creators” or “always trust reporters.”

Engineer lens: If tida_tickets never join consent_ledger_entries, the 48-hour export can’t explain retain-or-remove. If requester verification is hardcoded as “always required,” you may have overclaimed unsettled law.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Intimate publish without gov-ID/liveness/explicit consent capture where product policy requires it
  
• Consent only as unchecked free text; no durable ledger object
  
• TIDA tickets that never surface contrary ledger hits
  
• Auto-remove with no audit pack
  
• Multi-day “Legal reviewing consent” without SLA math
  
• Fake DMCA-style counter-notice marketed as a TIDA right
  
• Requester verification sold as “required by TIDA” without counsel memo
  
• Criminal § 223(h) macros answering N&R tickets (or the reverse)
  
• Soft-hide; no identical-copy sweep log
  
• Client/vendor brand names or incident folklore in the runbook

Side B — What works better (ledger → surface conflict → decide on the clock)#

What works better: Publish path for covered intimate classes: KYC vendor gov-ID + liveness + structured consent → consent_ledger_entry (opaque tokens, method codes, consent_version, timestamps).

TIDA intake (LE-11) remains first-class. On valid request, job joins ledger by media id.

If no hit → standard remove + sweep. If hit → ticket UI shows ledger summary; counsel policy chooses: (a) remove on clock (default safe), (b) optional requester verification step inside SLA budget, (c) escalate to named counsel with kill-clock rules.

Anti-weaponization: velocity caps, duplicate detection, account-linkage signals — logged, not silent. Every terminal state writes tida_decision_audit.

Card-program and § 2257 paths may reference the same verification events (LE-60 / LE-14) without merging schemas.

Fixed user story: Uploader publishes intimate UGC → ledger entry written → later, removal request → clock starts → ledger join → conflict UI → optional requester verify (if policy on) or remove → identical copies swept → audit pack exportable for FTC/tabletop.

Compliance checklist (green flags)#

• Covered intimate publish hard-fails without ledger predicates (policy-defined classes)
  
• consent_ledger_entries queryable by media id; tokens not raw ID images
  
• TIDA tickets show ledger hit/miss before decision
  
• sla_deadline_at always set; freeze paths are counsel-gated and rare
  
• Requester verification behind requester_verify_policy_version (default off until counsel enables)
  
• No fake statutory counter-notice UX
  
• Anti-weaponization signals logged
  
• Decision audit pack: request + ledger + steps + actors + sweep
  
• Parallel LE-12 / LE-60 / LE-14 links without schema collapse

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): Intimate publish consent checklist + KYC vendor status; TIDA report path distinct from DMCA; ticket view with ledger summary + SLA countdown; optional requester verify UX only when policy on; decision reason picker; reporter status without leaking ledger PII.

Interface (must-not): “Counter-notice under TIDA”; publish anyway for top earners; Slack-only decisions; requester verify as always-on friction for every ticket; merging criminal and N&R into one button.

Code: consent_ledger_write on publish; TIDA router join; sla_deadline_at; optional requester_verification_session; anti-abuse velocity; identical-copy sweep; tida_decision_audit writer; kill-switch publish on ledger schema break; no soft-hide.

Data: consent_ledger_entries (media_id, uploader_subject_id, kyc_method_codes, consent_version, vendor_token_refs, created_at); tida_requests; ledger_joins; requester_verify_events; tida_decision_audits; identical_copy_sweep_results; links to LE-60 / LE-14 objects without collapse.

Lost vs fixed (scene card)#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Pick one intimate UGC class. Can you export a consent ledger entry with method codes and timestamps — without dumping ID images?
   
2. File a test TIDA request against media with a ledger hit. Does the ticket UI show the conflict?
   
3. Confirm removed_at ≤ valid_at + 48h still holds when Legal is “looking at consent.”
   
4. Is requester verification off by default until a counsel memo enables it?
   
5. Search the UX for “counter-notice” on intimate-image flows — remove any TIDA-branded fake.
   
6. Export one decision audit pack. Missing ledger join or sweep rows = demo.
   
7. Confirm LE-60 / LE-14 packages reference verification events without owning the TIDA router.

If step 3 fails, you deepened the wrong machine.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Base AV + TIDA clocks — Chapter 5 (LE-10 / LE-11).
  
• Content advisories & ratings UX — Chapter 5C (LE-75).
  
• Adult UGC × card-network consent / KYC themes — Chapter 10B (LE-60).
  
• State NCII reporting — Chapter 20 (LE-12).
  
• § 2257 producer recordkeeping — Chapter 21 (LE-14) — sibling evidence, not substitute.
  
• T&S moderation / decision logs — Chapter 29 (LE-36); AI decision logging Chapter 6F (LE-66).
  
• Pattern Map LE-61 — Chapter 32.

Field rule — put this on the release checklist: The 48-hour clock still runs. A consent ledger is evidence you weigh on that clock — not a veto, and not an excuse to invent a counter-notice harbor.

This chapter is for education and discussion. It isn’t legal advice. Requester-verification options are unsettled — counsel owns enablement. No client names, incident dates, or employee names appear in this teaching reconstruction.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 5C — Worked Example: Content Advisories & Ratings UX#

Pattern family: Content advisories & ratings UX (LE-75). Sits after TIDA consent ledger (LE-61; Chapter 5B) in the AV / intimate-imagery cluster (LE-10 / LE-11; Chapter 5). Cross-cuts T&S moderation (LE-36; Chapter 29).
Legal anchors (themes): Mature / suggestive platforms — even with a “no nudity” product rule — still need clear advisories and ratings before access; distinct from age-verification gates and from a buried Community Guidelines PDF; evidence that the advisory was shown (not merely published somewhere). Unfair/deceptive practice and youth-protection themes when the landing experience hides intensity.
As of September 2026: Teaching reconstructions — generic Brand. No client stack names.

Why this memo exists#

Ratings, warnings, and age overlays are product surfaces. Soft-pedaling them for conversion is how you lose the advisory story.

If the advisory is theater and the media still plays, you didn’t finish. Gate playback; log the ack.

The story in one glance#

Picture a “PG-13 social” that markets soft lifestyle content.

Landing is bright and vague. Users enter feeds of suggestive thumbnails with no rating chip, no advisory interstitial, and no record that anyone saw a warning. AV (LE-10) may or may not fire by geo. Community Guidelines live as a PDF in the footer. When parents, app stores, or regulators ask what users were told, Support pastes the PDF link.

Advisories are a product surface — not a policy attachment.

Picture a ratings badge that Marketing wants to soft-pedal. Ask: is the advisory persistent at the moment of access — or a one-time interstitial nobody can prove?

Plain English — advisory ≠ AV ≠ guidelines PDF#

Field rule — put this on the release checklist: If the only “warning” is a footer PDF, you don’t have ratings UX.

Remember: a Law Engineer is a licensed attorney with software and product expertise.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“footer PDF”)#

What goes wrong: Marketing softens intensity. No interstitial. Ratings exist in a CMS no user sees. AV conflated with advisory (“we age-gated, so we’re done”). Suggestive thumbnails above the fold on the marketing domain. No advisory_shown event. A/B removes the soft warning for conversion.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• No pre-access advisory on mature/suggestive surfaces
  
• Guidelines PDF treated as the warning
  
• AV gate reused as content advisory
  
• No evidence of display/ack
  
• Experiments can strip advisory UI
  
• Thumbnail intensity exceeds disclosed rating

Side B — What works better (rate → show → record → gate)#

What works better: Surface-level content_rating + advisory copy versioned by counsel. Before first access to rated surfaces, interstitial or equivalent unavoidable notice; optional ack where counsel requires. Store advisory_shown / advisory_ack with rating_version. Feeds and deep links respect rating. Distinct from AV state machine (LE-10) and from TIDA/NCII paths (LE-11 / LE-61). T&S (LE-36) can escalate rating on content class changes. Experiment lint forbids removing advisory components (LE-62).

Compliance checklist (green flags)#

• Pre-access advisory on in-scope surfaces
  
• Rating version on evidence events
  
• AV and advisory separately logged
  
• CG PDF not substituted for advisory
  
• Re-show on material rating change
  
• Experiment CI protects advisory UI

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data#

Interface: Pre-access advisory interstitial / modal; persistent rating chip on mature surfaces; settings re-view; no reliance on footer-only PDF.
Code: rating registry; advisory gate middleware; deep-link respect; experiment allowlist; join points with AV without merging machines.
Data: content_ratings; advisory_copy_versions; advisory_shown_events; advisory_ack_events; surface_id links.

Lost vs fixed#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Cold session to a suggestive feed — is an advisory unavoidable before content?
   
2. Export last 100 sessions — advisory_shown present where rating requires it?
   
3. Confirm AV pass alone doesn’t skip advisory.
   
4. Attempt experiment hiding advisory — CI fail?
   
5. Change rating version — do returning users re-see?

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Age verification + TAKE IT DOWN — Chapter 5 (LE-10 / LE-11).
  
• TIDA consent ledger — Chapter 5B (LE-61).
  
• T&S moderation stack — Chapter 29 (LE-36).
  
• Legal review triggers (experiment lint) — Chapter 31B (LE-62).
  
• Pattern Map LE-75 — Chapter 32.

Field rule — put this on the release checklist: Ratings are shown before access — or they are decoration.

This chapter is for education and discussion. It isn’t legal advice. No client names appear in this teaching reconstruction.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 6 — Worked Example: Agentic Chatbot Guardrails (Lost vs Fixed)#

Pattern family: “AI isn’t advice” + human-in-the-loop (LE-30) and character / customer-support chatbot guardrails (LE-38)
Legal anchors: Negligent-misrepresentation and reliance themes (Restatement (Second) of Torts § 552); FTC Act § 5 accuracy / deception themes for AI marketing claims; EU AI Act Art. 50 chatbot transparency where Union-facing interactive AI is in scope (transparency in force as of 2 Aug 2026 for covered systems — confirm matter facts; Art. 50 is not a U.S. HITL statute); COPPA / under-13 overlays (LE-09); state adult AV when sexual character modes are in scope (LE-10). Garcia v. Character Techs. is cited here only for a pleading-stage design-vs-expression distinction — not as a merits rule or a national “AI is a product” holding.
As of September 2026: Confirm EU Art. 50 applicability and U.S. FTC posture for your facts before you ship agentic surfaces.

Why this memo exists#

Can the agent click Buy, post, or ‘agree’ without a human gate?

Probabilistic systems may propose. Deterministic Law Engineering gates dispose. Put the gate in the stack — not only in the prompt.

The story in one glance#

Illustrative teaching figures. Character apps, “AI companions,” and agentic commerce assistants share one failure: a probabilistic model is asked to carry a deterministic legal duty — assent, age, cancel, payment, professional advice boundaries — without a gate counsel can prove.

Pull up a chat window while you read. Ask: if this bot could spend money, change billing, or “agree” for the user, what would stop it? If the answer is “the system prompt,” keep reading.

Picture the bot with tool-calling enabled. Ask: if it tried to buy, file, or “agree” for the user right now, what server gate would stop it — a confirm id, or a hopeful system prompt?

Why counsel must gate release before agents can bind the company#

An agent that can draft is useful. An agent that can click, buy, post, file, or message a counterparty is a company actor with a stochastic keyboard.

Human-in-the-loop (HITL) means a human must confirm before a high-stakes tool runs — and the server must enforce that confirm. A modal the API can skip isn’t HITL.

Field rule — put this on the release checklist: Probabilistic systems may propose. Deterministic Law Engineering gates dispose. Counsel signs the release that turns tools on — not a prompt that hopes they behave.

Rubber-stamp HITL (pre-checked, auto-advanced, or API clients that skip the modal) is weak mitigation. Terms-of-service-only disclaimers do not universally defeat negligence, products, discrimination, or FTC § 5 theories when the surface tells a different story.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses#

Don’t ship this. If your current build matches Side A, stop the release train and fix it with counsel.

What goes wrong: Marketing calls the bot a “therapist,” “robot lawyer,” or “guaranteed picks.” The only “AI can be wrong” language lives in a footer PDF. Character catalog opens without age assurance. Tool-calling is open: the model can invoke payment, email, or ticketing APIs whenever the conversation vibes that way. Jailbreak tests are a Slack thread, not continuous integration (CI). Support bots apologize forever; no human queue id.

Why this matters in court / before a regulator:

1. Reliance risk. Users treat fluent output as professional advice. Buried disclaimers fight prominent overclaims — and lose the narrative.
   
2. Agency without evidence. If the agent “agrees,” purchases, or sends a letter, discovery asks for the confirm event. A chat transcript isn’t a formation or HITL record.
   
3. Minors / sexual modes. Child-directed or unknown-age romantic/sexual paths are a design failure mode, not a content-moderation afterthought (pair LE-09 / LE-10 where facts fit).
   
4. Injection & tool abuse. Prompt injection that exfiltrates tools or secrets is an engineering acceptance-test problem. Soft system-prompt rules aren’t gates.
   
5. Missing transparency. Where EU Art. 50 applies, users must know they interact with AI — persistent UI, not a one-time toast.

Lawyer lens — what I’d ask on the call: You’ll defend design choices (safeguards tested, age gates, crisis scripts, tool allowlists) — not only particular model words. Don’t invent a U.S. statute that “requires HITL”; document why your gates exist under consumer-protection, negligence, contract, and (if applicable) foreign transparency duties.

Engineer lens: If POST /tools/pay succeeds without a server-validated confirm token, the modal was decoration — incomplete, not a gate.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Professional-title marketing without licenses / substantiation
  
• Disclosure only in ToS or first-run modal that never returns
  
• High-stakes tools callable from raw model output
  
• Pre-checked or sub-second HITL
  
• No age gate before adult/romantic character modes
  
• No refusal path for medical dosage / legal filing / self-harm categories (counsel-set scripts)
  
• Jailbreak corpus absent from CI
  
• Support bot with no escalate-to-human control
  
• No export of disclosures, confirms, model versions, safety events

Side B — What works better#

Here’s the build worth shipping — gates, records, and an export counsel can defend.

LE-30 — notice + HITL that actually blocks#

1. Persistent disclosure on every AI surface: AI-generated; not a substitute for legal / medical / financial advice when those domains are in product scope.
   
2. High-stakes category list owned by counsel: send letter, move money, change account legal settings, medical triage claims, etc.
   
3. Confirm modal shows action summary + disclaimer; server requires hitl_confirm_id matching output_hash.
   
4. Enterprise mode: named reviewer role enforced server-side — not only in the web client.
   
5. Claim review gate: Content management system (CMS) blocks marketing strings that contradict the approved disclosure set.
   
6. Evidence: ai_disclosure_impressions, ai_hitl_confirms, ai_model_versions, ai_high_stakes_actions.

LE-38 — chat / character / customer-support specifics#

1. Badge every turn: “You’re chatting with AI / not a real person / not a lawyer, doctor, or financial advisor.” EU Art. 50 wording where deployment requires it.
   
2. Policy classifier on every turn; log safety_category; fail closed on unknown high-risk tools.
   
3. Age / AV before sexual or romantic modes policy forbids for minors or unknown age.
   
4. Crisis / self-harm: refusal template + resource links (counsel-approved); optional human escalate — not engagement that prolongs harm.
   
5. Tool allowlist server-side; payment/legal-file APIs never free-floating.
   
6. Eval harness in CI: jailbreak and policy suites must pass on the commit that ships.
   
7. Handoff: human_handoff_id with transcript reference; max-turn force handoff for CS loops.
   
8. Retention: minimize intimate chat memory; time-to-live (TTL) + purpose limitation; legal-hold flag when needed.

Compliance checklist (green flags)#

• Disclosure visible without scroll on mobile chat
  
• HITL token required for high-stakes tool endpoints
  
• Age-fail blocks adult character modes
  
• Safety refusals exportable by model_version
  
• Jailbreak suite red on CI blocks release
  
• Human escalate always visible when humans exist
  
• Counsel sign-off checklist completed before agentic tools go live in production

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): persistent AI disclosure / badge every turn (locale-aware where EU Art. 50 applies); confirm modal with action summary + disclaimer before high-stakes tools; age/AV gate before forbidden character modes; visible human escalate when humans exist; counsel-approved crisis refusal copy.

Interface (must-not): professional-title overclaims; disclosure only in ToS or a one-time toast; pre-checked or sub-second HITL; romantic/sexual modes for age-unknown or under-age profiles; support loops with no handoff control.

Code: Server-side tool allowlist; high-stakes endpoints require hitl_confirm_id matching output_hash; classifier on every turn with fail-closed unknown high-risk tools; age-fail blocks adult modes; CMS/claim review fails contradictory marketing; jailbreak + policy suites in CI gate release; max-turn forces human_handoff_id.

Data: ai_disclosure_impressions (surface, locale, model_version); ai_hitl_confirms; ai_model_versions; ai_high_stakes_actions; ai_safety_events (safety_category); human_handoff_id + transcript reference. Exportable incident pack for counsel.

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Agentic commerce — the same loop, sharper teeth#

Checkout agents and “buy for me” assistants amplify formation, ROSCA cancel, and payment risks from earlier chapters:

• An agent that accepts Terms for a user without a recorded assent event recreates Specht-style proof problems in a new costume.
  
• An agent that renews or purchases without a deterministic cancel path recreates easy-cancel failures.
  
• An agent that shares intimate images or deepfakes trips LE-11 / LE-32 overlays — the chat UI is still a covered surface if the product hosts UGC.

Release gate: Counsel doesn’t “review the prompt.” Counsel signs that Interface → Code → Data gates exist for every tool that can create legal consequences — and that probabilistic paths can’t skip them.

For dual-consent gaps, pre-flight bot policy, terms ledgers, payment mandates, and UETA/E-SIGN orientation when an agent binds, continue in Chapter 6B (Agentic Commerce & Automated Legal Decisions) — LE-43…LE-47. This chapter keeps disclosure, classifiers, tool allowlists, and HITL; Chapter 6B owns commerce binds.

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Open character or CS chat on a 390px-wide viewport. Is the AI disclosure visible without scrolling?
   
2. Ask the bot to send money, email counsel letterhead, or change billing. Does the API 403 without a confirm id?
   
3. Create an under-age or age-unknown test profile. Are romantic/sexual modes hard-blocked?
   
4. Run your jailbreak corpus in CI against the build you would ship.
   
5. Force a support loop past max turns — does a human_handoff_id appear?
   
6. Export one incident pack. Missing marketing/model/confirm rows means a demo — not a release.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Co-pilot skin (draft≠send / PVS) — Chapter 6H (LE-70); AI Terms congruence — Chapter 6G (LE-69).

• AI surface inventory / model register — Chapter 6D (LE-64); shadow AI egress — Chapter 6E (LE-65); decision logs / CoT — Chapter 6F (LE-66).

• Chapter 6B — agentic commerce / automated legal decisions (LE-43…LE-47) when agents buy, renew, or agree.
  

• Enterprise no-training defaults (LE-31) and synthetic media labels (LE-32).
  

• Broader Trust & Safety patterns (LE-36) when chat sits on UGC platforms.
  

• Revisit formation (LE-01, Chapter 2) and cancel (LE-03, Chapter 3) whenever agents touch checkout.

This chapter is for education and discussion. It isn’t legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 6B — Worked Example: Agentic Commerce & Automated Legal Decisions#

Pattern family: Agentic commerce / automated legal decisions (LE-43…LE-47; overlaps LE-30 / LE-38)
Legal anchors: Uniform Electronic Transactions Act (UETA) § 14 (automated transactions / electronic agents) and § 10 (change or error; opportunity to prevent or correct); federal E-SIGN orientation that a transaction isn’t denied legal effect solely because an electronic agent was involved (15 U.S.C. § 7001(h) themes); ordinary agency, formation, and consumer-protection overlays when an agent buys, renews, or “agrees.” Soft orientation only — not a national holding that every unsupervised LLM click is (or isn’t) binding.
As of September 2026: Confirm your state’s UETA text, E-SIGN carve-outs, card-network mandate rules for agent spend, and counterparty bot / API policies before shipping unsupervised checkout tools.

Why this memo exists#

When an agent proposes a cart, a human still has to confirm the consequential legal acts — or you invent assent out of automation.

If an agent can bind money or terms without a recorded human confirm, counsel hasn’t finished the design.

The story in one glance#

Illustrative teaching figure. Chapter 6 covered disclosure, classifiers, tool allowlists, and “can’t silent-agree.” This chapter is the sharper commerce problem.

Picture a “buy for me” assistant. It finds a deal, clicks Agree, pays, and emails a receipt. Who agreed to arbitration? Who authorized that spend ceiling? If those answers are fuzzy, you’re in this chapter.

An agent that binds — purchase, renew, arbitration/IP grant, payment — when neither human principal nor merchant clearly consented to that mode of dealing is the core risk.

Picture an agent with a payment tool and a vague user prompt. Ask: which automated legal decision (ALD) gate requires human confirm before money moves?

The dual consent gap#

Classic online formation asks: did this human get conspicuous notice and unambiguous assent? Agentic checkout splits the question:

1. Principal side. The human never reviewed the Terms, price, renew cadence, or dispute clause the agent accepted. A chat log saying “sure, buy it” isn’t a formation or HITL record.
   
2. Counterparty side. The site’s ToS, robots rules, or machine-readable policy may prohibit bots / automated checkout. Preferring an authorized API avoids a deal the merchant never offered.

When both fail, neither party clearly consented to the mode of dealing. Close the gap with deterministic gates — not a system prompt that hopes the model behaves.

Field rule (commerce edition): Probabilistic systems may propose carts and clause summaries. Deterministic gates dispose assent, payment, and consequential binds. Full autonomy that deletes checkpoints is a design risk, not a feature.

Soft statute orientation (1999 carts vs 2026 ALD)#

Automated legal decisions (ALD) here means agent tool-calls that create legal consequences — buy, renew, accept dispute clauses, grant IP, move money.

UETA § 14 contemplates that a contract may be formed by interacting electronic agents — even if no individual reviewed the agents’ actions or resulting terms — and by an individual interacting with an electronic agent when they know (or have reason to know) their action will complete the deal. E-SIGN similarly orients that legal effect isn’t denied solely because an electronic agent participated.

That architecture assumed 1999-style carts and electronic data interchange (EDI): deterministic scripts under a known mandate. 2026 probabilistic ALD — LLM tool-calling that paraphrases Terms, improvises clicks, and invents “I agreed for you” — is different. Soft reading: § 14 tells designers that agency can bind; it does not excuse missing mandates, spoofed identity, bot-banned surfaces, or deleted error checkpoints.

UETA § 10 turns, in automated transactions involving an individual, in part on whether the electronic agent provided an opportunity to prevent or correct the error — plus related prompt-notice / unwind conditions. Design implication: preserve review and correction surfaces before consequential bind. “Fully autonomous” checkout that removes those checkpoints is a deliberate § 10-facing design risk (and a formation / UDAP narrative gift).

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses#

Don’t ship this. If your current build matches Side A, stop the release train and fix it with counsel.

What goes wrong: A “buy for me” agent scrapes checkout, spoofs a browser user-agent (UA) — the string that identifies the browser to the server — clicks I Agree and Pay, and emails a receipt. The human never saw arbitration, IP license, auto-renew, or total price. The merchant’s ToS bans bots. No terms ledger, no payment mandate from a verified principal, no human confirm on consequential binds. Support can only say “the agent handled it.”

Why this matters in court / before a regulator: (1) Dual consent gap — mode of dealing never bargained. (2) Evidence vacuum — no terms_hash, key-term summary, or hitl_confirm_id. (3) Identity evasion — spoof stacks invite ToS breach and merchant repudiation (detect and refuse; do not build evasion). (4) Spend without mandate — networks/issuers expect principal authorization, not an orphaned agent credential. (5) Governance blank — no pre-flight, materiality breakers, or spend approver to show later.

Lawyer lens — what I’d ask on the call: You defend (or attack) the mode of dealing and the mandate, not only the SKU. “The model meant well” isn’t assent.

Engineer lens: If checkout.complete succeeds without pre-flight allow, honest identity, payment-mandate token, and (for consequential classes) HITL confirm, the agent is a liability keyboard — incomplete paper compliance dressed as automation.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Agent accepts Terms / buys / renews with no human-reviewed key-term summary
  
• No pre-flight of ToS, robots, or machine-readable bot policy
  
• Spoofed UA / “look human” stack; scrape-checkout when an authorized API exists
  
• No terms ledger; high-risk clauses (arb, IP assignment, auto-renew) never escalate
  
• Agent spend without verified principal mandate / spend ceiling
  
• Full autonomy path that removes prevent/correct checkpoints before bind

Side B — What works better (LE-43…LE-47)#

Fixed building blocks#

1. Pre-flight (LE-43). Before act: evaluate ToS bot clauses, robots.txt, and any published machine-readable agent policy. Surface bot bans; prefer authorized APIs; fail closed when policy is unknown or prohibitive.
   
2. Honest identification. Truthful agent identity/purpose in headers or API client metadata. No evasion stack absent explicit human direction for a counsel-scoped exception — and log that direction. Circumvention is out of scope; refusing it’s in scope.
   
3. Consequential-bind HITL (LE-44). Purchase, renew, arbitration assent, IP grant/license, account-legal changes: human confirm + key-term summary (price, interval, cancel path, dispute clause, unusual IP). Server requires hitl_confirm_id bound to summary hash.
   
4. Terms ledger + materiality breakers (LE-45). Append-only ledger of URLs/versions/content_hash/clause flags. Breakers pause + HITL on arb/class waiver, broad IP assignment, auto-renew, unusual liability shifts, or hash drift mid-flow.
   
5. Payment mandate (LE-46). Verified principal authorization: who, instrument token, ceiling, merchant category code (MCC)/merchant class, expiry. Card-network reality at high level: mandate story tied to the cardholder/principal — not an orphaned agent secret.
   
6. Optional machine-readable policy (LE-47). Publish/consume emerging .well-known/… / structured agent policies (allowed agents, required identity, bind rules). Emerging pattern — not enacted law. Interoperability aid; not a substitute for ToS review or human gates.

Short governance-evidence box#

Boards and officers need evidence of a system — pre-flight logs, mandate registers, HITL confirms, terms ledgers — not a memo that “AI is exciting.” One exportable incident pack is stronger oversight evidence than a slide deck alone. Ordinary oversight hygiene only; this chapter isn’t a fiduciary treatise.

Compliance checklist (green flags)#

• Pre-flight allow/deny logged before first consequential tool call
  
• Honest agent identity; evasion paths absent from default builds
  
• Consequential classes blocked without HITL + key-term summary hash
  
• Terms ledger exportable; materiality breaker pauses on arb / IP / renew / hash drift
  
• Payment mandate token + spend ceiling enforced server-side
  
• Optional consume/publish of machine-readable agent policy where offered
  
• Chaos test: bot-banned site → stop and surface reason, not “try harder”

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface: Pre-flight status (allowed / banned / unknown) before act; key-term summary + confirm on purchase/renew/arb/IP; honest “acting as agent for [principal]” disclosure; clear stop when policy blocks; optional link to counterparty machine-readable agent policy.
Interface must-not: Silent agree; spoof-as-human chrome; confirm-shaming past materiality breakers; spend without showing ceiling/mandate scope.

Code: Gates: pre-flight allow → identity assert → mandate check → (if consequential) HITL confirm → ledger write → bind tool. Prefer official APIs over HTML checkout automation. Counsel-owned materiality rules; fail closed on unknown high-risk clauses. No production path that strips prevent/correct steps for bind classes.

Data: agent_preflight_events, agent_identity_assertions, terms_ledger (url, version, hash, clause flags), agent_hitl_confirms, payment_mandates, agent_bind_actions (append-only); retain for disputes/chargebacks/CID tabletop.

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Point a staging agent at a site that bans bots. Does it stop and explain — or invent a workaround?
   
2. Attempt a renew or arb-accept without HITL. Expect API 403.
   
3. Complete one allowed purchase. Export terms ledger + mandate id + confirm hash.
   
4. Change Terms mid-flow (hash drift). Does a materiality breaker fire?
   
5. Ask finance: which principal authorized this agent’s spend ceiling? If “the model has the card,” you don’t have LE-46 yet.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• AI surface inventory — Chapter 6D (LE-64); shadow AI — Chapter 6E; decision logs — Chapter 6F.
• Revisit formation (LE-01, Chapter 2), ROSCA/cancel (LE-03, Chapter 3), and payment evidence when agents touch checkout.
  
• Keep Chapter 6 guardrails (LE-30 / LE-38) for disclosure, classifiers, and tool allowlists — this chapter doesn’t replace them.
  
• Operating-model release gates later in this guide: counsel signs Interface → Code → Data for every tool that can create legal consequences.

This chapter is for education and discussion. It isn’t legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 6D — Worked Example: AI Surface Inventory & Model Register#

Pattern family: AI surface inventory / model–vendor register (LE-64). Sits after agentic chatbot guardrails (LE-30 / LE-38; Chapter 6) and agentic commerce / ALD (LE-43…LE-47; Chapter 6B). Feeds shadow-AI egress (LE-65; Chapter 6E) and AI decision logging (LE-66; Chapter 6F).
Legal anchors (themes — checklist against inventory, not treatise): EU AI Act risk-class / transparency themes; DSA systemic-risk / recommender themes for very large platforms; Colorado AI Act (and peer state AI laws) high-risk system duties; GDPR Art. 22 automated decision-making / profiling themes; US sector and FTC unfairness themes when AI claims overreach. Orientation only — counsel maps which regimes actually attach.
As of September 2026: Re-check AI Act applicability dates, Colorado rulemaking, and your Art. 22 DPIA posture before anyone claims “we inventoried, therefore compliant.”

Why this memo exists#

Before you argue about guardrails, inventory every model, tool call, and place output can leave the building.

You can’t gate what you haven’t named. Inventory first; then attach counsel-owned gates.

The story in one glance#

Picture a product counsel asking a simple question in a release meeting: Where does generative AI touch the user?

Engineering answers with three branded chat widgets. Growth mentions a “smart reply” that shipped last quarter. Support uses a summarizer nobody filed. A vendor SDK silently embeds embeddings for “personalization.” The privacy notice still says the company doesn’t use automated decision-making.

Legal can’t govern what Legal can’t see.

Walk the release meeting with a blank inventory open. Ask: if an AG letter named every AI surface that touched a user’s data last quarter, could you export the list tonight — or would you be inventing it from Slack?

This chapter builds the missing artifact: every generative and review surface → model → endpoint → vendor/DPA (data processing agreement) → data classes. The inventory is the gate. Regimes (AI Act / DSA / Colorado AI / Art. 22) are then checked against the map — not waved as a slogan. Teaching reconstructions only; generic Brand / analytics SDK / KYC vendor language.

Plain English — if it isn’t on the register, it isn’t governed#

Field rule — put this on the release checklist: An unlisted AI surface is an ungoverned legal act waiting for a CID.

Remember: a Law Engineer is a licensed attorney with software and product expertise. Engineers maintain the register under that counsel’s oversight.

What the law is asking the product to do (themes)#

1. Inventory first. You can’t apply AI Act risk tiers, Colorado high-risk duties, DSA recommender transparency, or Art. 22 notices to ghosts.
   
2. Separate generative vs review. Different disclosure and logging needs (LE-66).
   
3. Vendor honesty. Personal SaaS keys and “free tier” models aren’t enterprise DPAs (LE-65).
   
4. Data-class tags. Same model with support tickets vs public FAQ isn’t the same row.
   
5. Checklist, not treatise. Map each in-scope row to: transparency / labeling, risk management, logging, human oversight, user rights — as counsel directs.
   
6. Release gate. New surface or model bump without register update = blocked merge.
   
7. Congruence. Privacy notice and marketing claims must match the register (LE-41 adjacency).

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“we have a chatbot policy”)#

What goes wrong: One PDF covers “AI use.” Shadow features ship behind flags. Vendor list is a spreadsheet from 2024.

Art. 22 notice says “we don’t do ADM” while a credit-like scorer ranks creators. EU pages lack labels the AI Act themes expect for generative outputs.

Nobody can list endpoints that receive user contents. When a regulator asks for the model inventory, Legal opens Slack.

Why this matters in court / before a regulator: Regimes attach to systems and uses, not to brand slogans. An incomplete register makes every downstream control (HITL, logging, no-training, shadow-AI bans) unenforceable.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• AI features live that are absent from the register
  
• Generative and review collapsed into one row
  
• Vendor “DPA” is a clickwrap free tier
  
• Data classes blank or “misc user data”
  
• Privacy notice contradicts register
  
• Model version unpinned (“latest”) in production
  
• No counsel owner on high-risk rows
  
• Checklist regimes never mapped to rows

Side B — What works better (register → classify → gate)#

What works better: Living ai_surface_register in the same discipline as the data map (Chapter 7). CI fails if a new inference client ships without a register id.

Counsel reviews high-risk / ADM-shaped rows before enable. Generative outputs route labeling/disclosure policies; review models route decision-log policies (LE-66).

Vendor rows require enterprise account + DPA id. Quarterly diff: runtime telemetry of model endpoints vs register.

Fixed user story: Squad proposes “smart compose” → opens register PR → data classes + vendor + HITL → counsel classifies risk / Art. 22 posture → enable flag only with register_version → runtime emits surface_id on every call.

Compliance checklist (green flags)#

• Every generative/review surface has a register id in prod telemetry
  
• Model version pinned; endpoint allowlisted
  
• Vendor/DPA id required for external calls
  
• Data-class tags drive redaction / no-training defaults (LE-31)
  
• Regime checklist completed for in-scope rows
  
• Privacy/marketing congruence scan includes AI claims (LE-41)
  
• Named counsel + eng owners

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): Admin register UI (or reviewed markdown-as-code); user-facing AI disclosures tied to surface_id; vendor/status for ops.

Interface (must-not): Undocumented “smart” features; “AI-powered” marketing for unlisted surfaces.

Code: ai_surface_register version; allowlisted endpoints; client SDK requires surface_id; CI grep for raw vendor hosts; kill switch by surface.

Data: surfaces, models, endpoints, vendor_dpa_ids, data_class_tags, risk_class_counsel, hitl_required, owners, changelog.

Lost vs fixed (scene card)#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. List every feature that calls an LLM or classifier in prod — compare to the register. Diff is your backlog.
   
2. Pick one generative surface: can you name model version, endpoint, vendor DPA, and data classes in one screen?
   
3. Block a staging deploy that calls a host not on the allowlist — did CI catch it?
   
4. Diff privacy notice “automated decision” language against register ADM-shaped rows.
   
5. Confirm Chapter 6 / 6B features appear as rows — not “covered by vibe.”

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• AI Terms congruence — Chapter 6G (LE-69); co-pilot skin — Chapter 6H (LE-70).

• Chatbot guardrails — Chapter 6; agentic commerce — Chapter 6B.
  

• Shadow AI / personal LLM egress — Chapter 6E (LE-65).
  

• Decision logs / CoT containment — Chapter 6F (LE-66).
  

• Enterprise no-training — Chapter 26 (LE-31).
  

• Living data map — Chapter 7; privacy threshold inventory — Chapter 7C (LE-67).
  

• Pattern Map LE-64 — Chapter 32.

Field rule — put this on the release checklist: Regimes attach to systems you can name. Name them first — then apply the checklist.

This chapter is for education and discussion. It isn’t legal advice. AI Act / DSA / Colorado AI / Art. 22 citations are orientation checklists against your inventory — not a compliance certificate.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 6E — Worked Example: Shadow AI & Personal LLM Egress#

Pattern family: Shadow AI / personal LLM accounts / data egress (LE-65). Follows AI surface inventory (LE-64; Chapter 6D). Sits with enterprise no-training (LE-31; Chapter 26) and privacy congruence (LE-41; Chapter 4).
Legal anchors (themes): Confidentiality / trade-secret and employment-policy themes; privacy-notice accuracy when staff paste user data into consumer AI tools; vendor retention/training defaults on consumer tiers; security / breach themes when regulated data leaves the perimeter; GDPR / state privacy “processor instructions” themes when staff become an accidental disclosure path.
As of September 2026: Consumer-tier training and retention defaults change — verify current enterprise vs consumer terms before policy copy ships.

Why this memo exists#

Where did that paste into a personal LLM go?

Shadow AI isn’t a training footnote — it’s an egress and confidentiality problem. Detect, block, log.

The story in one glance#

Picture an engineer debugging a thornier support ticket.

They paste the user’s message thread — emails, photos metadata, maybe a payment dispute — into a personal consumer chat account on a public LLM. It’s fast. It’s helpful. It’s also the company exfiltrating itself through a browser tab.

Legal’s enterprise no-training clause never saw that traffic. The privacy notice never disclosed that path. The AI surface register (Chapter 6D) never listed it. Data loss prevention (DLP) watched USB sticks and ignored HTTPS to a consumer AI host.

Walk this with your network allowlist beside you. Ask: which consumer AI hosts can staff reach from a corp laptop? If the answer is “all of them,” you don’t have an AI program — you have a browser.

This chapter treats shadow AI as an egress problem: enterprise accounts only; DLP/egress gates; notice accuracy; vendor retention/training unknowns as first-class risks.

Plain English — personal accounts aren’t a vendor program#

Field rule — put this on the release checklist: If the company can’t point to a DPA, a register row, and a retention answer, staff aren’t “using AI” — they are sending company and user data to a stranger’s product.

Remember: a Law Engineer is a licensed attorney with software and product expertise.

What the law / policy is asking the product to do (themes)#

1. Ban personal-account use for company/user data — written policy + technical friction.
   
2. Enterprise-only allowlist of AI hosts (ties to LE-64).
   
3. DLP / egress gates on known consumer AI domains and paste patterns where proportionate.
   
4. Privacy notice honesty — don’t claim processors you don’t control; don’t omit known staff tools if they are in scope.
   
5. Vendor unknowns — consumer tiers may train / retain; encode “unknown = disallowed for PII/contents.”
   
6. Culture + detection — training without telemetry is a pep talk.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“we trust people”)#

What goes wrong: Acceptable-use PDF forbids ChatGPT; everyone still uses it. API keys for consumer accounts live in engineers’ password managers. Support macros say “summarize in your AI tool.” DLP allowlists nothing AI-related. When a journalist asks whether user DMs train public models, Marketing says “we never share data with AI vendors” while staff paste daily.

Why this matters in court / before a regulator: Notice accuracy, security, and processor control fail together. “Is the company exfiltrating itself?” isn’t rhetorical.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Personal LLM accounts used on company devices/networks for work data
  
• No egress controls toward consumer AI hosts
  
• Privacy notice claims no AI processors while shadow use is rampant
  
• Enterprise no-training marketing (LE-31) while consumer paste continues
  
• Unlisted surfaces in register (LE-64 miss)
  
• No incident path for suspected paste exfiltration

Side B — What works better (policy → allowlist → DLP → culture)#

What works better: Written ban on personal AI for work data. SSO enterprise tenants only; consumer hosts blocked at network/CASB where proportionate.

Browser and endpoint DLP rules for paste-to-AI patterns on high-sensitivity apps. Register (LE-64) is the allowlist source.

Safe approved tools for summarization with redaction. Tabletop: “paste user DM into consumer AI” as a privacy incident drill.

Privacy notice and staff handbook stay congruent.

Fixed user story: Staff need a summary → open approved enterprise surface → auto-redaction → logged surface_id → no consumer host route.

Compliance checklist (green flags)#

• Enterprise AI SSO enforced; consumer AI hosts blocked or alerted
  
• Register allowlist drives egress policy
  
• DLP rules tested on staging paste fixtures
  
• Notice + handbook + marketing aligned
  
• Incident runbook for shadow-AI egress
  
• Metrics: block/alert counts reviewed by counsel + security

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface: Staff portal lists approved AI tools; block interstitial when consumer AI host hit; redaction UX on approved summarizers.

Code: Egress allowlist; CASB/DLP policies-as-code; browser extension inventory; kill personal API keys in secrets scanners.

Data: egress_alerts; approved_tool_logins; shadow_ai_incident_tickets; register_version used for allowlist.

Lost vs fixed (scene card)#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. From a corp laptop, open a consumer LLM host — blocked, warned, or free?
   
2. Secrets-scan repos for personal AI API keys.
   
3. Ask three support agents how they summarize tickets today — compare to the allowlist.
   
4. Diff privacy notice processor list vs register + known shadow tools.
   
5. Run one tabletop paste incident — is severity defined?

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• AI surface register — Chapter 6D (LE-64).
  
• Decision logging — Chapter 6F (LE-66).
  
• Enterprise no-training — Chapter 26 (LE-31).
  
• Privacy congruence — Chapter 4 (LE-41); threshold inventory — Chapter 7C (LE-67).
  
• Pattern Map LE-65 — Chapter 32.

Field rule — put this on the release checklist: Personal LLM accounts are egress paths. If you can’t name the DPA, you can’t claim control.

This chapter is for education and discussion. It isn’t legal advice. Vendor retention/training defaults change — verify current enterprise terms with counsel.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 6F — Worked Example: AI Decision Logs, Criteria & CoT Containment#

Pattern family: AI decision logging, criteria versions, chain-of-thought (CoT) containment, Legal retrieval (LE-66). Deepens automated T&S moderation (LE-36; Chapter 29) without replacing that chapter; stitches logging / ESI store-vs-create (LE-55; Chapter 7B). Follows inventory (LE-64) and shadow-AI (LE-65).
Legal anchors (themes): Accountability / explainability expectations for automated decisions (EU AI Act logging themes; DSA statements of reasons themes for certain moderation; Colorado AI documentation themes; GDPR Art. 22 / access themes where automated decisions produce legal or similarly significant effects); discovery / regulatory production of decision records; privilege and over-disclosure risk when raw CoT / reasoning traces are dumped into user-facing or over-broad logs.
As of September 2026: Verify which logging duties attach to your risk class and forum before promising “full model reasoning” to users or agencies.

Why this memo exists#

If a model Approve/Deny matters legally, you need inputs, model id, human override, and outcome in an exportable log.

When a regulator or plaintiff asks why the system did X, you need a row — not a vibe.

The story in one glance#

Picture a Trust & Safety model that returns Approve / Deny / Ignore on a piece of UGC.

Product stores the label. Policy drifts next week; nobody pinned criteria_version. A bulk “Ignore → Delete” job fires on a bad threshold. Counsel learns from Twitter. When Legal asks why item 88421 was denied in March, Engineering offers a screenshot of today’s prompt. Somewhere, a debug flag wrote the model’s chain-of-thought (CoT — the model’s inner reasoning trace) into an analytics SDK — now discoverable far beyond the T&S ticket.

Walk this chapter with one denied item open beside you. Ask three questions. Which criteria_version was live that day? Can Legal export the decision record in hours, not weeks? Did anyone dump raw CoT into a sink that will show up in discovery?

This chapter encodes: versioned criteria, HITL override events, durable decision logs with a Legal retrieval SLA, CoT containment, and a mass-action kill switch + counsel notify for bulk delete/archive. Deepen LE-36; don’t reprint the whole moderation OS.

Plain English — decisions need ledgers, not vibes#

Field rule — put this on the release checklist: Store the decision record you can defend. Don’t store the model’s inner monologue in every sink you have.

Remember: a Law Engineer is a licensed attorney with software and product expertise.

What the law is asking the product to do (themes)#

1. Pin criteria. Taxonomy / prompt / threshold bundle gets criteria_version counsel signs (LE-36 adjacency).
   
2. Log Approve/Deny/Ignore (or equivalents) with subject id, surface id (LE-64), model version, criteria version, timestamp.
   
3. HITL override events are first-class — not silent admin edits.
   
4. Legal retrieval SLA — export path tested; not “we’ll write a script.”
   
5. CoT / reasoning-trace containment — default deny to user UI, tickets, and analytics SDKs; separate privileged debug store if counsel allows.
   
6. User-facing reasons use approved reason codes — not raw CoT.
   
7. Mass-action kill switch — bulk delete/archive/score-flip requires dual control + counsel notify (LE-55 store-vs-create awareness: don’t fabricate logs after the fact).
   
8. Stitch LE-55: decision logs you chose to store are ESI candidates; turning on verbose CoT “for the lawsuit” is a create-path counsel owns.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“label only / dump the CoT”)#

What goes wrong: Decisions are a boolean column. Criteria live in a Google Doc. Overrides happen in SQL. Bulk jobs have no brake. Debug CoT streams into a generic analytics SDK. Legal retrieval is a heroic weekend. User sees a 900-token rationale that hallucinates policy.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• No criteria_version on decisions
  
• HITL edits without override events
  
• CoT in user email or broad logs
  
• Bulk delete without counsel notify
  
• Can’t export March decisions by id within SLA
  
• “We’ll enable full traces for discovery” without counsel create-path (LE-55)

Side B — What works better (version → decide → log → contain → brake)#

What works better: Criteria bundles versioned like code. Inference writes decision_events with foreign keys to surface/model/criteria.

HITL console writes override_events. Reason-code mapper for user/DSA-style notices.

CoT only in sealed debug tier with ACL + retention. Bulk actions require mass_action_token + paging kill switch; pager to counsel on threshold.

Legal portal retrieves by subject/time within SLA. Tabletop with LE-36 queues.

Compliance checklist (green flags)#

• Every automated decision carries criteria + model + surface versions
  
• Overrides logged
  
• CoT not in user-facing or analytics sinks
  
• Mass-action dual control + counsel notify tested
  
• Legal retrieval drill passes SLA
  
• LE-55 map marks decision log storage_tier

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface: Moderator reason codes; override UI with required note; mass-action confirm with impact count; Legal retrieval portal.

Code: criteria_version pin; decision_events writer; override API; CoT redaction middleware; mass-action kill switch; retrieval export.

Data: criteria_bundles; decision_events; override_events; mass_action_events; sealed_cot_objects (ACL); retrieval_audit.

Lost vs fixed (scene card)#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Export one Deny from last week — criteria_version and model id present?
   
2. Perform a HITL override in staging — override_event written?
   
3. Grep logs/analytics for raw CoT fields.
   
4. Dry-run bulk archive at 1% — kill switch and counsel notify fire?
   
5. Time a Legal retrieval drill against the SLA.
   
6. Confirm Chapter 29 (LE-36) taxonomy versions match criteria bundles.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• AI Terms ↔︎ product disclosure congruence — Chapter 6G (LE-69); co-pilot skin — Chapter 6H (LE-70).

• T&S moderation OS — Chapter 29 (LE-36) — this chapter deepens logging, not queues.
  

• ESI store vs create — Chapter 7B (LE-55).
  

• AI inventory / shadow AI — Chapters 6D / 6E.
  

• Enterprise no-training — Chapter 26 (LE-31).
  

• Pattern Map LE-66 — Chapter 32.

Field rule — put this on the release checklist: Log the decision you can retrieve. Contain the reasoning you can’t defend in every sink.

This chapter is for education and discussion. It isn’t legal advice. It deepens LE-36 logging themes — it doesn’t replace the Trust & Safety chapter.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 6G — Worked Example: AI Terms ↔︎ Product Disclosure Congruence#

Pattern family: AI Terms ↔︎ product disclosure congruence (LE-69). Sits after AI inventory / shadow AI / decision logs (LE-64…66; Chapters 6D–6F) and mirrors privacy tag congruence (LE-41; Chapter 4).
Legal anchors (themes): Unfair/deceptive practice themes when ToS “fictional simulation / not a real person / no emotional reliance / AI LoL” language diverges from shipped UI that invites reliance, romance, or human-seeming intimacy; notice and disclosure accuracy; contract formation congruence with product reality.
As of September 2026: Treat this as a scanner discipline like LE-41 — not a new statute.

Why this memo exists#

Do they tell the same story?

If marketing says ‘your data isn’t used for training’ and the pipeline does, congruence failed before the lawsuit.

The story in one glance#

Terms that say: Characters are fictional simulations. Don’t rely on them for advice or emotional support. AI outputs may be wrong. Liability is limited.

The product ships a co-pilot that says “I’m here for you,” offers crisis-shaped intimacy, omits persistent AI labeling on mobile, and markets “someone who understands.” Support quietly treats bot promises as binding. The AI LoL in ToS never appears near the feature.

Privacy congruence (LE-41) taught notice ↔︎ tags. This chapter teaches AI Terms ↔︎ product disclosures with the same habit: inventory claims, diff against UI, fail the release when they diverge.

Walk one AI surface with Terms open in the other tab. Ask: does the chrome invite reliance the PDF forbids? If a regulator played the UI next to the disclaimer, who wins the story?

Plain English — if Terms say simulation, UI can’t sell a person#

Field rule — put this on the release checklist: ToS AI disclaimers that the UI contradicts are evidence against you — not a shield.

Remember: a Law Engineer is a licensed attorney with software and product expertise.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“Legal owns Terms; Growth owns UI”)#

What goes wrong: Terms updated yearly. Chat UI redesigned weekly. Labels A/B’d away. Emotional-reliance ban exists only in PDF. Congruence never scanned. Inventory (LE-64) lists surfaces; nobody diffs disclosure strings.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Terms “simulation” vs UI “your person”
  
• Missing persistent AI disclosure on a Terms-covered surface
  
• AI LoL contradicted by ads
  
• No scanner/diff job for AI claim packs
  
• Support macros ignore Terms limits

Side B — What works better (claim pack → surface map → scanner)#

What works better: Counsel maintains ai_terms_claim_pack (simulation, reliance, accuracy, LoL pointers, HITL promises) versioned with Terms. Each surface_id (LE-64) maps required disclosures. CI/visual or string scanner diffs pack ↔︎ UI like LE-41. Failures block release (LE-62). Co-pilot skins (LE-70) inherit the pack.

Compliance checklist (green flags)#

• Versioned AI claim pack
  
• Surface → required disclosure map
  
• Scanner in CI / release train
  
• Marketing/review includes pack
  
• Drift tickets with owners

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data#

Interface: Persistent AI labels; no human-impersonation chrome; crisis routing; claim-consistent empty states.
Code: ai_terms_claim_pack_version; surface disclosure map; scanner job; release gate.
Data: claim_packs; surface_disclosure_requirements; scan_results; drift_tickets.

Lost vs fixed#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Quote three AI Terms sentences; find matching UI on each generative surface.
   
2. Turn off AI disclosure in staging — does scanner fail?
   
3. Diff ads vs AI LoL language.
   
4. Confirm LE-64 register rows point at disclosure requirements.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• AI inventory / shadow / logs — Chapters 6D–6F.
  
• Co-pilot skin — Chapter 6H (LE-70).
  
• Privacy congruence method — Chapter 4 (LE-41).
  
• Pattern Map LE-69 — Chapter 32.

Field rule — put this on the release checklist: AI Terms are product specs. If the UI tells a different story, the Terms won’t save the launch.

This chapter is for education and discussion. It isn’t legal advice.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 6H — Worked Example: Conversational Co-Pilot Skin (HITL / PVS / No Impersonation)#

Pattern family: Conversational platform co-pilot / AI skin — draft≠send, user ratification, no synthetic persona impersonation, PVS matrix, kill switch (LE-70). Builds on chatbot guardrails (LE-30 / LE-38; Chapter 6), inventory/logs (LE-64 / LE-66), Terms congruence (LE-69), and inherits AV / § 2257 / consent gates on tool calls (LE-10 / LE-14 / LE-61).
Legal anchors (themes): Disclosure of AI; prohibition on deceptive impersonation / fake-human presentation; human-in-the-loop for consequential sends; product-safety style kill switches for alpha surfaces; tool-call inheritance of age / records / consent predicates; RAG scope limitation to authorized corpora.
As of September 2026: Teaching reconstructions only — no brand names, no product URLs.

Why this memo exists#

A co-pilot skin raises a simple question: what can it see, say, and do — and does the user know it is not the human?

A friendly skin doesn’t waive the gates. Scope the tools; log the consequential acts.

The story in one glance#

Picture a “co-pilot” skin over chat or creator messaging.

It drafts replies in a beloved persona’s voice. A toggle auto-sends. Users can’t tell where the human stopped and the model began. Tools can fetch private media, tip, or publish. Alpha builds live on sticky URLs with no kill switch. Retrieval-augmented generation (RAG) pulls from another customer’s tickets. Age verification (AV) and consent ledgers never see the tool path.

Walk one co-pilot message end-to-end. Ask: can it send without the user tapping Send? Does the UI claim “it’s really them”? If the alpha URL leaks tonight, is there a one-switch kill?

This chapter encodes: draft ≠ send; user ratification; no synthetic persona / impersonation; a PVS (policy / voice / safety) matrix; alpha URL kill switch; tool calls that inherit AV / 2257 / consent; RAG scope allowlists. Cross-ref LE-64/65/66 — don’t invent a parallel register.

Plain English — skin, not sockpuppet#

Field rule — put this on the release checklist: A co-pilot that can send as you without you isn’t assistance — it’s agency without assent.

Remember: a Law Engineer is a licensed attorney with software and product expertise.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“auto-send in their voice”)#

What goes wrong: Persona skin without AI label. Auto-send on. Tools bypass publish gates. Alpha link shared publicly. RAG “helpful” across tenants. Shadow personal LLM keys (LE-65) power the skin. Decision logs missing (LE-66). Terms say simulation; UI says “it’s really them” (LE-69 fail).

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Auto-send without ratification
  
• Missing AI disclosure / human impersonation chrome
  
• Tool calls skipping AV/2257/consent
  
• No kill switch on alpha URLs
  
• Unscoped RAG
  
• Unlisted surface_id (LE-64)

Side B — What works better (draft → show → ratify → send)#

What works better: Co-pilot listed on register (LE-64). PVS triple versioned.

Composer shows draft + AI badge; Send disabled until ratify. Impersonation lint bans “I’m {creator}” system prompts without disclosure template.

Tools wrap existing gates. Alpha hosts behind flag + kill.

RAG allowlist per tenant. Logs: draft_events, ratify_events, send_events (LE-66).

Terms congruence scanned (LE-69).

Compliance checklist (green flags)#

• surface_id + PVS versions on every call
  
• Draft≠send enforced in API
  
• Disclosure persistent
  
• Tool gates inherited
  
• Kill switch tested
  
• RAG allowlist tested for cross-tenant deny
  
• Congruence scan green

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data#

Interface: Draft pane; AI badge; ratify/send; refuse impersonation; kill banner for alpha.
Code: draft≠send; ratify token; PVS pin; tool gate wrappers; RAG allowlist; kill switch; register surface_id.
Data: pvs_versions; draft_events; ratify_events; send_events; tool_call_events; rag_corpus_allowlists; kill_events.

Lost vs fixed#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Attempt send without ratify_id — expect 403.
   
2. Strip AI badge in staging — congruence/scanner fail?
   
3. Tool-publish without consent ledger — hard fail?
   
4. Kill alpha flag — URLs die?
   
5. RAG query other tenant — deny?

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Guardrails — Chapter 6; inventory/logs — 6D/6F; Terms congruence — 6G.
  
• AV/TIDA/2257 — Chapters 5 / 5B / 21.
  
• Pattern Map LE-70 — Chapter 32.

Field rule — put this on the release checklist: Draft is cheap. Send is a legal act. Skins disclose; tools inherit; alpha dies on command.

This chapter is for education and discussion. It isn’t legal advice. No brand names or product URLs appear in this teaching reconstruction.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 7 — Worked Example: Legal Process, Data Maps & Counsel Portals#

Pattern family: SCA/ECPA / legal process response (LE-24); overlaps privacy rights portals and data-mapping themes (LE-06)
Legal anchors: Stored Communications Act / ECPA themes for compelled and voluntary disclosure; preservation pending process; sealed / gagged / delayed-notice matters where nondisclosure binds the provider; civil process distinguished from criminal process for contents. Global privacy rights (access, deletion, inventory) share the same data map problem as subpoena and warrant response.
As of September 2026: Process classification and production scope are counsel calls for each matter — confirm primary authorities and your facts before shipping disclosure tools.

Why this memo exists#

When process arrives, counsel needs systems, processors, retention, and legal-hold hooks — not a Slack archaeology project.

When a CID or subpoena lands, scavenger hunts fail. The map is how counsel and eng see the stack together.

The story in one glance#

Illustrative teaching figure. a PDF that lands in Slack. Someone greps production. Counsel tells a court what the company “has” from a stale slide. Six months later, nobody can prove what was searched — or what was not.

Now picture the fixed version: a living data map feeds a counsel portal with production jobs, preservation flags, sealed-matter access-control lists (ACLs), and an auditable trail of what was searched and produced.

This chapter is about making counsel’s representations true. If you remember only one line: a living map beats a war-room improvisation.

Picture a CID that asks for “all data related to user X.” Ask: does your living data map tell counsel where to look — or do you start a Slack scavenger hunt?

Why this is a Law Engineering primer#

In trenches tech-law practice: responding to subpoenas, search warrants, and sometimes secret or gagged government process is a fundamental Law Engineering exercise — not a war-room improvisation.

A Law Engineer — a licensed attorney with software and product expertise — must be able to say, in good faith, what the company holds and what it produced. Noncompliance can mean contempt. Incomplete access to the stack, incomplete processes, or a fictional data map can push lawyers into inaccurate representations to law enforcement and the court. That isn’t a drafting problem; it’s an engineering and inventory problem.

Put policed automations in place with traceability to company-wide data and a living data map, so counsel can form a good-faith belief in what they are providing — and so objections (process insufficient, overbreadth, wrong data class, map gap) are made in good faith rather than from hope.

This work overlaps global privacy compliance. The inventory for consumer access and deletion is largely the same inventory needed to answer: Where does this account’s data live, and what can we lawfully produce? The privacy rights portal for user review and deletion can be reworked into a lawyer-internal portal for subpoena and warrant response — same systems checklist, different authentication, roles, and legal gates.

The Stored Communications Act (SCA) and broader Electronic Communications Privacy Act (ECPA) themes shape how and when providers may disclose contents and non-content records. Process classification is a counsel call — not an engineering shortcut.

Field rule — put this on the release checklist: If counsel can’t reconstruct what was searched, held, objected to, and produced — with who, when, and under which process type — the company doesn’t have a legal-process program. It has a Slack habit.

Side A — What loses (PDF → Slack → guess)#

What goes wrong: Process arrives as a PDF. It hits Slack. An engineer greps a primary database and dumps CSVs. Counsel, under a short return date, names systems from memory or a stale “privacy data map” slide. The consumer data-subject access request (DSAR) / delete portal exists for paper compliance, but legal ops can’t reuse it: different auth, no process classification, no gag controls, no production hash. Nobody can later prove what was not searched. Sealed or gagged matters leak into the wrong room through the same informal channels.

Why this matters in court / before a regulator: (1) Contempt / representation risk — a fiction map makes inaccurate statements likely even when counsel intends good faith. (2) Process misclassification — civil contents, thin process for sensitive classes, or undocumented emergencies are invited by informal tools. (3) No preservation or production audit — without holds, scoped jobs, and hashes, claims are unprovable. (4) Privacy map ≠ legal map — a privacy slide doesn’t unlock warrant-scoped exports or sealed ACLs; dual drifting portals invent two truths.

Lawyer lens — what I’d ask on the call: Your signature on a cover letter or declaration is only as honest as the inventory behind it. Without systems searched and excluded (map version), you can’t object from a map gap — only apologize later.

Engineer lens: If support can SELECT * into a laptop, the SCA/ECPA ladder is incomplete paper compliance. Content export must require a classified legal_process_id, not a Slack ping.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Intake via unverified DM / social / personal email only
  
• Informal “export user” buttons for support
  
• Counsel names systems from a stale slide, not a living map
  
• Privacy DSAR portal can’t be reused by legal ops
  
• No hold distinct from production; no production hash/scope/actor
  
• No sealed-matter ACL; gagged matters in general tickets
  
• Civil contents unlock the same export path as warrants
  
• No “map gap / unknown system” objection reason code

Side B — What works better (living map + counsel portal)#

What works better: A living data map lists systems, data classes (basic subscriber, other non-content, contents, sensitive location — as counsel taxonomizes), retention, owners, and export connectors. Privacy and legal-process inventory are one register with two consumers. Authenticated intake classifies process type before any disclosure tool unlocks. Counsel / legal-ops open an internal portal — reusing privacy rights fulfillment machinery (system checklist, jobs, clocks) — with different auth, matter ACLs, gag/notice controls, and objection states. Production jobs emit trace IDs; preservations are distinct from productions; sealed matters stay need-to-know.

Fixed building blocks#

1. Living data map — versioned; data classes, owner, export connector, last_verified_at. Unknown/stale rows drive objection — not silent omission.
   
2. Counsel portal — same inventory/workers as DSAR know/delete; legal_ops / counsel only; sealed ACL.
   
3. Process classification gate — warrant / criminal / civil / preservation / emergency / foreign unlock different allowlists. Civil contents blocked absent counsel override + reason.
   
4. Preservation ≠ production — immutable snapshot on request; disclosure is a separate scoped, hashed job.
   
5. Policed production jobs — legal_process_id + scope + actor + production_trace_id + hash; append-only register.
   
6. Gag / notice controls — sealed or delayed-notice suppresses user-notice jobs; default safe.
   
7. Objection workflow tied to the map — process insufficient, overbreadth, wrong class, map gap, third-party custody — each linked to map version and systems considered.

Compliance checklist (green flags)#

• Public law-enforcement guidelines + authenticated intake
  
• One living map feeds privacy and legal-process fulfillment
  
• Content export requires classified process id; informal paths killed
  
• Hold creates snapshot without disclosure; sealed tickets ACL-scoped
  
• Register exportable without dumping payloads into chat
  
• Good-faith search scope reconstructible from map version + job logs
  
• Tabletop: warrant contents, civil contents objection, preservation, gag, map-gap objection

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / Code / Data — Law Engineering rubric#

Interface (must-show): Public guidelines (process types, required elements, emergency contact); authenticated intake (agency, matter id, process type, targets, return date, attachment); taxonomy matching process types; production UI showing data class before unlock; notify / delayed / gagged controls (default safe); counsel views of map version, systems searched, holds, objections, productions; sealed-matter banner and restricted search.

Interface (must-not): Support “export user” dumping contents; auto-produce contents on civil subpoena alone; auto-notify when gag/delayed-notice is flagged; process solely via social DMs or unverified email; general Slack as system of record for sealed matters.

Code: Role-gated disclosure (legal_ops / counsel); process-type matrix gates content vs non-content; preservation without produce; gag suppresses notice jobs; civil contents → PROCESS_INSUFFICIENT + objection unless counsel override + reason; kill informal CSV paths; production jobs write hashed register rows; sealed ACL on tickets, search, notifications.

Data: Living data_map (shared with privacy); legal_process_matters; legal_preservations; legal_productions (scope, hash, actor, production_trace_id); legal_objections (including map gap); legal_user_notices. Prefer write-once-read-many (WORM) / append-only. Retention: counsel-set multi-year horizon aligned with holds and transparency reporting.

Overlap table — Privacy rights portal ↔︎ Counsel legal-process portal#

Same inventory; different gates.

Field rule — put this on the release checklist: Don’t maintain two inventories. Maintain one map, two portals (consumer-facing rights vs lawyer-internal process), with gates that match the legal regime.

What this chapter is NOT#

This chapter is not a public playbook for evading lawful process, defeating warrants, or coaching nondisclosure beyond what sealed/gagged process already requires. It’s how you make compliance and good-faith advocacy possible: so the company can preserve, produce, and object accurately — and so counsel’s representations rest on a policed map and an auditable trail, not folklore.

Escalate novel, foreign, national-security, wiretap/pen-trap, or emergency matters to specialized counsel. Process classification isn’t an engineering shortcut.

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Ask counsel to name every system that could hold DM/email-like contents for user X; diff against the living map.
   
2. Attempt content export without a classified legal-process id — does the API 403?
   
3. Open a fake civil-contents ticket — block + objection path?
   
4. Preservation-only matter — snapshot without disclosure?
   
5. Gag a matter — notices suppressed and ticket ACL-scoped?
   
6. Run one DSAR delete and one legal production on the same test account — same system checklist?
   
7. Export a register row (scope, actor, hash, map version). Missing fields = demo, not a program.

SOP deepen — legal process as code (LE-24)#

Chapter 7 already taught the living map and counsel portal. This section hardens the operating SOP so intake doesn’t depend on tribal knowledge. Teaching only — no client letterhead.

1. § 2703(c)(2) subscriber allowlist as code#

Encode the subscriber-information categories counsel treats as § 2703(c)(2)-style basics (name, address, records of session times/durations, length of service, types of services, subscriber number/identity, means/source of payment — verify current statute text with counsel) as an allowlist enum in the production policy engine. Requests that ask only for allowlisted fields can route to the matching template; anything outside the allowlist fails closed into a higher process_type (warrant / court order path) — never “just this once” in Slack.

2. Do-Not-Disclose-Without-Warrant list joined to the map#

Maintain a versioned dnd_without_warrant list (contents, location info beyond the allowlist, message bodies, etc. — counsel-owned). Join it to the living data map so every system/field row declares: subscriber_allowlist | dnd_without_warrant | other_legal_hold_only. Portal export refuses dnd fields unless process_type ∈ warrant-class.

3. Intake → classify → versioned template letters#

1. Intake — ticket with raw demand + channel + received_at.
   
2. Classify — process_type enum: preservation, subscriber_2703c2, dnd_warrant, civil_subpoena, foreign_mlat, emergency, etc.
   
3. Template — versioned response / objection / production cover letters (generic Firm templates — no client letterhead in the guide). Classification locks which template versions may send.
   
4. Send + hash — store template_version, actor, hash of outgoing.

4. Foreign / MLAT process_type#

Foreign mutual legal assistance and non-US compulsory process get their own process_type and playbook pointer — not a US subscriber template with the caption tippexed. Counsel owns whether to object, narrow, or route through MLAT channels.

5. Production meta (secure channel, hours/cost)#

Every production event records: secure channel id (SFTP/portal — not personal email), estimated/actual hours, cost center / invoice refs if charged, and byte/hash manifests. Meta is part of the evidence pack when fee-shifting or reasonableness is later disputed.

6. Training / audit cadence#

Quarterly tabletop: one subscriber allowlist request, one dnd/warrant request, one foreign/MLAT-shaped demand, one preservation-only. Audit sample of tickets for classification accuracy and template_version presence. Results feed release gates for portal changes (LE-62 adjacency).

Field rule — put this on the release checklist: If the map can’t say which fields are allowlist vs warrant-gated, Legal is improvising under a clock.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

Privacy engineering threshold inventory (eleven inputs → living map) — Chapter 7C (LE-67). Logging/ESI deepen — Chapter 7B (LE-55). Privacy notice and rights UX (LE-06) and tag/notice congruence (Chapter 4). Breach clocks when legal process overlaps incident response. Operating-model chapter later in this guide: who owns the living map, who signs process matrices, and how tabletops become release gates.

This chapter is for education and discussion. It isn’t legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 7B — Worked Example: Logging & ESI — Store vs Create#

Pattern family: Logging & ESI — store vs create (LE-55). Deepens the living data map and counsel portal from Chapter 7 (LE-24 themes) — doesn’t replace them. Adjacent privacy inventory (LE-06 themes). Not CIPA session-replay consent (Chapter 4B / LE-53).
Legal anchors (themes): Fed. R. Civ. P. 34 — produce electronically stored information already within possession, custody, or control, not a blank order to invent new surveillance logs; Alexander v. FBI, 194 F.R.D. 305, 310 (D.D.C. 2000) (Rule 34 produces documents already in existence); ReplayTV / Paramount discovery briefing themes (no Rule 34 duty to design software that creates usage data you never stored); Torrentspy teaching story — Columbia Pictures Indus. v. Bunnell, 245 F.R.D. 443 (C.D. Cal. 2007) and related practice — transient RAM / HTTP headers / “turn on logging,” privacy chill, discovery order as de facto injunction themes. Fact-specific and contested — don’t overclaim a nationwide rule that RAM always is, or never is, ESI.
As of September 2026: Remember: a Law Engineer is a licensed attorney with software and product expertise. Re-check Rule 34, your forum’s ESI orders, and counsel’s create-vs-produce posture before anyone flips access_log_enabled because Slack said “discovery.”

Why this memo exists#

Under a hold, the hard question is what you already store versus what you invent by flipping logging on.

ESI fights punish systems that create records after the fact. Decide store-vs-create on purpose, with counsel.

The story in one glance#

Picture a PDF hold letter.

It asks for “all server logs, IP addresses, and HTTP header data” for visitors who touched a feature. An engineer opens the edge config. Access logging has been off for years — privacy posture, cost, or habit. Someone types in Slack: “Just turn it on. It’s a hold.”

That’s the fork this chapter exists for.

Chapter 7 taught you to stop guessing from a stale slide: a living data map, a counsel portal, preservation separate from production, and objections that name map gaps. This chapter adds one sharper question the map must answer out loud:

Did we ever store that — or are they asking us to start capturing what only ever flickered through RAM?

Walk it with counsel beside the whiteboard. Point at the web tier. Ask: disk log, object store, backup — or transient memory that evaporates when the request ends? If the honest answer is “we never wrote it down,” a hold isn’t a permission slip to build a surveillance stream. It’s a brief, an objection path, or — only if counsel and the court so require — a commence-capture decision with eyes open to privacy chill.

Teaching reconstructions only. Not screenshots of any party’s live product and not exhibits. Torrentspy appears here as a teaching story, not as settled ESI gospel.

Picture the night someone suggests “turn on verbose logging for the lawsuit.” Ask: are you storing what already exists — or creating a new discoverable record?

Plain English — store, preserve, create#

Three verbs get mashed together in war rooms. Keep them apart.

1. Produce (store → export). Rule 34 themes ask for ESI you already have — or that sits in systems under your possession, custody, or control in a form the rule reaches. Export the table. Hash the production. Chapter 7’s trail.
   
2. Preserve. Stop deleting what you already keep. Snapshot. Hold flag. Still not disclosure — Chapter 7’s “preservation ≠ production” line.
   
3. Create / commence capture. Flip access_log_enabled. Write a collector. Reduce fleeting HTTP headers in RAM into permanent log files because someone sued. That’s a different legal machine. Alexander themes say Rule 34 is about documents already in existence. ReplayTV-era briefing themes push the same instinct: designing software to invent usage data you never collected isn’t ordinary document production.

If you remember only one sentence: a hold on nothing still yields nothing — until counsel decides whether “start logging” is ordered, agreed, or fought.

What the law is asking the product to do (themes)#

Orient to five design pressures. Counsel owns the final call for your matter.

1. FRCP 34 themes — existence first. The request assumes there’s something to produce. Your map must say what is retained and what isn’t — including “never_persisted.”
   
2. Alexander themes — no create-by-default. “Produce documents already in existence” is the teaching baseline. “Build us a new log” is advocacy territory, not an engineer’s silent favor.
   
3. ReplayTV themes — software to create data. When the ask is months of engineering to capture customer usage you never stored, treat it as create — even if opponents call it “discovery.” Offers to produce raw data you already collect are a different conversation.
   
4. Torrentspy teaching story — RAM, headers, chill. In that fight, logging had been off; opponents pressed that user HTTP information flashed through server RAM and should be stored, preserved, and handed over. Defense themes (from contemporaneous teaching posts): create vs provide; RAM as ephemeral; “turn on logging” as a de facto injunction without bond; privacy chill if a privacy-centric site must start tracking IP/clickstream for the other side; overbreadth if all visitors get logged over a narrow claim set. Courts can order case-specific steps after burden and relevance analysis — Bunnell is real and fact-bound. Teach the pressure. Don’t invent a universal holding that every web server must log RAM, or that no court may ever order capture.
   
5. Chapter 7 still owns the portal. Process classification, sealed ACLs, hashed productions, map-gap objections — reuse them. LE-55 only deepens the map’s honesty about RAM vs disk and the counsel path when someone asks to start capturing.

Field rule — put this on the release checklist: If counsel can’t tell a court what was never stored, the company doesn’t have an ESI story. It has a panic toggle.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (Slack flips the logger)#

What goes wrong: Hold PDF hits Slack. Eng enables access logs “to be safe.” Overnight the edge writes IP, URL, and headers for every visitor. Privacy policy still says logging is minimal. Nobody scopes geo or claim. Three months later counsel is asked what the company “has.” The honest answer is a mess: new logs exist only after the flip; earlier periods never existed; nobody can prove what was searched on day one. Or the opposite failure: eng refuses all logging talk, but the data map still lists “server logs” as if they were on disk — and a declaration overclaims.

Why store-vs-create themes care: You either created a surveillance artifact under discovery pressure without a counsel path, or you misdescribed transient systems as stored ESI. Privacy chill isn’t abstract — users who chose a low-log product now feed a lawsuit’s clickstream. Overbreadth is free: global logging for a fourteen-work complaint shape of case.

Lawyer lens — what I’d ask on the call: Your signature needs a map version that distinguishes disk / object / backup from transient_ram / never_persisted. Objections need reason codes — never stored, create not produce, overbroad capture — tied to that map (Chapter 7). Citing Torrentspy as “we always win on RAM” is as weak as ignoring that courts sometimes order case-specific preservation.

Engineer lens: If access_log_enabled is a Friday hotfix during an active matter, the audit trail is a chat scrollback. If the map has no persistence tier, every production job is a guess. Empty files labeled “logs for Q1” are fiction — and fiction is how representations die.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Hold or Rule 34 request auto-enables logging without counsel ticket
  
• Data map lists “logs” with no RAM vs disk vs never-persisted label
  
• Slack as system of record for “we turned logging on for the case”
  
• Privacy schedule promises minimal IP logging while discovery quietly enables it
  
• Production of empty or post-flip-only logs sold as complete history
  
• Global capture for a narrow claim set with no scope fields
  
• Chapter 7 portal exists but commence-capture and preserve-extant are the same button

Side B — What works better (map truth + counsel path)#

What works better: The living map from Chapter 7 gains columns: persistence tier, logging flag state, retention if enabled, owner, last verified. Edge and API rows say never_persisted or transient_ram when that’s true — and disk when rotated logs actually exist. A hold on a never-logged service opens Preserve extant (nothing to snapshot but the config truth) and, separately, a Commence capture counsel ticket — not a silent config flip.

When opposing counsel demands RAM-derived clickstream, legal ops uses objection codes the portal already knows how to attach to a map version: never stored; create not produce; overbroad. If a court orders a scoped capture — or counsel agrees to one — eng flips access_log_enabled only under a counsel_capture_order_id, with scope (fields, geo, window), a privacy-notice delta if public statements change, and an append-only audit of when capture started and stopped.

Fixed user story: Request arrives → map shows which systems stored what for period T → preserve extant logs where they exist → produce with hash and map version → for never-stored periods, counsel briefs create-vs-produce (Rule 34 / Alexander / ReplayTV themes; Torrentspy pressure as teaching context) → if capture must start, gated config + notice review + scoped window — not a global panic log.

Compliance checklist (green flags)#

• Map columns: RAM vs disk vs never; logging flag visible
  
• Preserve extant ≠ commence capture in the UI
  
• access_log_enabled gated during matters; audit who flipped and why
  
• Objection codes for never-stored / create / overbroad / map gap
  
• Productions never invent rows for periods that never persisted
  
• Privacy schedule checked before voluntary or ordered capture starts
  
• Tabletop: hold on never-logged edge; Rule 34 for headers/RAM; preserve-only extant disk logs

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): Data-map persistence tier and logging-flag state; hold actions split into preserve-extant vs commence-capture; commence-capture wizard (scope, retention, privacy impact, counsel sign-off); production UI limited to persisted allowlists; objection reason codes including never-stored and create-not-produce.

Interface (must-not): One “enable logs for lawsuit” button for any eng; hold that silently flips global logging; map that calls RAM “stored” without a tier label; Slack-only record of capture decisions.

Code: Config gates on access_log_enabled (and header/IP siblings) when a discovery matter or hold is active — require counsel_capture_order_id; preservation jobs refuse to “preserve” pure never-persisted rows without the commence path; production API fails closed with NEVER_STORED rather than shipping a fake complete log; audit capture start/stop; kill/revert leaves a historical window for honest later declarations.

Data: Extend the same Chapter 7 living map — storage_tier, logging config versions, counsel capture orders (matter, optional court order id, scope hash, privacy review), preservations, productions, objections. Prefer append-only. Retention on the discovery horizon counsel sets.

Lost vs fixed (scene card)#

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Open the living data map (Chapter 7). Pick the public edge or API tier. Circle whether access logs are on disk, in an object store, or never written. If the cell is blank, that’s the bug.
   
2. Read access_log_enabled (or your equivalent). Who can flip it today — and does a hold auto-flip it?
   
3. Ask counsel to role-play a Rule 34 request for “all HTTP headers in RAM” for last quarter. What objection codes and map rows do you attach?
   
4. Run a preserve-only job on a never-logged service. Did anything silent enable capture?
   
5. Diff the privacy schedule against a hypothetical commence-capture. What sentence would become false overnight?
   
6. Export one pretend declaration pack: map version, systems searched, systems marked never_persisted, any capture window. Missing fields mean the war room still owns you.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Privacy engineering threshold inventory — Chapter 7C (LE-67). AI decision logs stitch — Chapter 6F (LE-66).
• Living data map, counsel portal, preservation ≠ production, map-gap objections — Chapter 7 (LE-24 themes). This chapter only deepens RAM vs disk and the create path.
  
• Privacy rights inventory on the same map — LE-06 themes / privacy chapters earlier in this guide.
  
• CIPA prior consent for session replay is a different theory — Chapter 4B (LE-53). Don’t confuse “don’t start logging for discovery” with “don’t load FullStory before Accept.”
  
• Operating model / who signs commence-capture — later operating-model chapter. Pattern Map LE-55 when the index catches up.

Field rule — put this on the release checklist: Rule 34 themes reach what you stored. Starting a log you never kept is counsel’s create path — not an engineer’s favor.

This chapter is for education and discussion. It isn’t legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 7C — Worked Example: Privacy Engineering Threshold Inventory#

Pattern family: Privacy engineering threshold inventory — eleven Engineering→Legal inputs as a living intake gate (LE-67). Sits after legal process & data maps (LE-24; Chapter 7) and logging/ESI store-vs-create (LE-55; Chapter 7B). Feeds the living data map and tag congruence (LE-41; Chapter 4) — doesn’t duplicate those chapters.
Legal anchors (themes): Notice-at-collection / purpose limitation / processor & subprocessor transparency (CCPA/CPRA, GDPR Arts. 13–14 / 28, peer state laws); DSAR access/delete themes; cookie/SDK/consent regimes (LE-08); AI/ML training disclosures (LE-31 / LE-64); security-as-privacy control themes. Orientation: productize the threshold questions Engineering must answer before Legal can green-light a surface — then keep them continuously true.
As of September 2026: Re-check your geo matrix and notice templates; this chapter teaches intake discipline, not a new statute.

Why this memo exists#

A privacy review two days before launch is too late. Inventory PI categories, purposes, and vendors while the design is still cheap to change.

You can’t honor rights you haven’t inventoried. Threshold triggers are product inputs, not annual PDF chores.

The story in one glance#

Counsel receiving a “privacy review” ticket two days before launch.

The ticket says: “New social feature — please approve.” There’s a Figma. There’s no field list. Storage is “the cloud.” Purposes are “product improvement.” Third-party SDKs are “the usual.” AI training is “maybe later.” Deletion is “we can figure it out.” DSAR export is “Support downloads CSV.” Cookies are “Marketing owns that.” Security is “SOC2.”

Counsel can’t map what counsel can’t see. The living data map (Chapter 7) stays a museum piece. Tag congruence (Chapter 4) fails because nobody inventoried the new pixel.

Walk the ticket as if you were counsel arriving cold. Ask: can Engineering answer the eleven inputs below without a scavenger hunt? If any answer is “we’ll figure it out after launch,” the review isn’t ready — and neither is the release.

This chapter productizes eleven Engineering→Legal inputs as Law Engineering requirements: a threshold intake before Legal review is meaningful, plus a continuous update gate when any input drifts. Generic Brand / analytics SDK / KYC vendor only.

Plain English — eleven inputs, one living habit#

Teach Engineering to arrive with these eleven answers. Legal then maps duties. Do not reprint the full data-map chapter or the congruence scanner chapter — link them.

Field rule — put this on the release checklist: Legal review without these eleven is theater. Shipping without updating them after change is amnesia.

Remember: a Law Engineer is a licensed attorney with software and product expertise. Engineers own the intake accuracy under counsel oversight.

What the law is asking the product to do (themes)#

1. Threshold gate. No “privacy LGTM” without inventory id + version covering the eleven inputs for that surface.
   
2. Continuous update. Schema/SDK/purpose/AI changes reopen the gate — not annual privacy week.
   
3. Feed, don’t fork. Inventory rows update the living map (Chapter 7) and trigger congruence scans (Chapter 4) — separate UIs, same truth.
   
4. Honesty about impossibilities. If backups or derived embeddings can’t be deleted on the same TTL, say so in intake and notices.
   
5. AI isn’t optional row 6. “We don’t think of it as ML” still needs a register pointer (LE-64).
   
6. Generic vendors. Describe analytics SDK / KYC vendor / Brand acquirer — never client stack folklore.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“approve the Figma”)#

What goes wrong: Privacy review is a checkbox on the launch template. Engineers paste last quarter’s answers.

New analytics SDK ships under “bugfix.” AI summarizer added to support without row 6. DSAR still claims full delete.

Living map updated “someday.” Congruence scanner fails red; launch proceeds. When an AG asks for categories of sources and third parties, Legal reconstructs from HAR files and memory.

Why this matters in court / before a regulator: Notice, sale/share, DSAR, and security narratives all require the same underlying inventory. Skipping threshold intake makes every downstream pattern (LE-06/07/08/24/41/64) brittle.

Lawyer lens — what I’d ask on the call: Refuse to sign until the eleven are filled or explicitly N/A with reason.

Engineer lens: If your PR can ship a new field or SDK without touching inventory version, the gate is fake.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Privacy tickets without inventory version
  
• “Same as before” with no diff
  
• Blank third-party matrix
  
• AI/ML row omitted for generative/review features
  
• Deletion claimed absolute where impossibilities exist
  
• DSAR path untested against new fields
  
• Cookie/SDK list diverges from production (LE-41 failure)
  
• Security row is a logo, not controls per store
  
• Client/vendor brand folklore in the intake form

Side B — What works better (intake → sign → map sync → reopen on drift)#

What works better: privacy_threshold_inventory records (per surface/release) with eleven sections, owners, and inventory_version.

Counsel sign-off references that version (Chapter 31 / 31B). On merge, automation proposes living-map patches (Chapter 7) and queues congruence scan (Chapter 4).

AI rows must cite surface_id (LE-64). Deletion impossibilities become notice footnotes counsel approves.

Continuous: schema migration hooks and SDK register changes invalidate inventory freshness.

Fixed user story: Squad opens feature → fills eleven inputs → counsel reviews → sign-off artifact cites inventory_version → map/congruence update → ship. Later SDK bump → freshness fail → reopen rows 5/10/11 → re-sign.

Compliance checklist (green flags)#

• Threshold inventory required artifact on privacy-gated launches
  
• Eleven sections complete or N/A-with-reason
  
• Map sync + congruence trigger on approve
  
• AI row linked to register
  
• Deletion impossibilities documented
  
• Freshness SLA (e.g., invalid on SDK/schema/AI change)
  
• Generic vendor language only in templates

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): Intake form/UI with eleven sections; stale banner; links to map & congruence results; counsel sign-off view.

Interface (must-not): Single “privacy approved” checkbox; optional blank AI row for AI features; vendor name drop-downs filled with client folklore.

Code: privacy_threshold_inventory versioning; PR check for inventory freshness; webhooks from SDK register / AI register / schema migrations; map-patch proposer; congruence job trigger.

Data: inventory_records (11 sections JSON); freshness_events; sign_off_ids; links to data_map_version, congruence_scan_id, ai_surface_ids.

Lost vs fixed (scene card)#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Pick a feature that shipped last month. Fill the eleven inputs from memory — where do you blank? That blank is the bug.
   
2. Diff production SDKs against the last inventory’s row 5/10.
   
3. Confirm AI features cite register ids in row 6.
   
4. Run a DSAR export for a test user — does it include fields added after the last inventory?
   
5. Ask whether schema migrations reopen freshness — if not, wire the hook.
   
6. Open Chapter 7 and Chapter 4: inventory should update them, not replace them.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Living data map / counsel portals — Chapter 7 (LE-24).
  
• Logging & ESI store vs create — Chapter 7B (LE-55).
  
• Privacy ↔︎ tags congruence — Chapter 4 (LE-41); CIPA replay — Chapter 4B (LE-53).
  
• AI register / shadow AI — Chapters 6D / 6E.
  
• Operating model / legal review triggers — Chapters 31 / 31B.
  
• Pattern Map LE-67 — Chapter 32.

Field rule — put this on the release checklist: The eleven inputs are how Engineering speaks Legal’s language before launch — and how both notice when the truth moves.

This chapter is for education and discussion. It isn’t legal advice. It teaches threshold intake and continuous update — it doesn’t replace Chapters 4 or 7.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 8 — Worked Example: Affiliate KYC & Endorsement Disclosures#

Pattern family: Affiliate onboarding KYC gates (LE-19) + FTC endorsement / affiliate #ad disclosures (LE-18)
Legal anchors: FTC Act § 5, 15 U.S.C. § 45(a); FTC v. LeadClick Media, LLC, 838 F.3d 158 (2d Cir. 2016) (network participation/control); FTC v. Credit Bureau Center, LLC, 325 F. Supp. 3d 852 (N.D. Ill. 2018) (agency/ratification themes); FTC Endorsement Guides, 16 C.F.R. Part 255 (revised 2023; 88 Fed. Reg. 48092)—§§ 255.5 / 255.0(f) / 255.1(d),(f); affiliate Example 11. Guides interpret § 5; they aren’t statutory safe harbors.
As of September 2026: Re-check eCFR Part 255, current FTC staff FAQ language, and your program’s monitoring cadence before quoting disclosure templates in a matter. KYC/KYB gates here are practice controls—not a money-services AML program unless the client is otherwise regulated.

Why this memo exists#

Affiliate programs fail on KYC gaps and FTC endorsement hygiene — tracking links without either are not a compliance program.

Payees who promote you’re an ad surface. Track who they are and what they must disclose.

The story in one glance#

Illustrative teaching figure. Not official screenshots of any party’s product.

Open your affiliate portal. Can a stranger mint a tracking link the day they apply? Can a commissionable post go live with “#ad” only in the bio? If monitoring finds a fake-news lander tonight, do commissions still pay in the morning?

That’s the whole chapter in three questions.

Lost: pay-per-click affiliates get tracking links on apply day; posts ship without clear #ad; rogue landers keep earning. Fixed: identity/KYB and risk rating clear before links; disclosure templates gate publish; tagged links and a kill switch stop commissions when monitoring flags deception.

Why this is an engineering problem#

Affiliate programs fail in two places that look separate on an org chart and fuse into one FTC story.

First: Who are you paying? If anyone can mint a tracking link before you know their identity, traffic method, and risk tier, you aren’t running a program — you’re renting your brand to strangers.

Second: Do consumers know this is an ad? Commissionable posts without a clear material-connection disclosure (or with “#ad” buried under “more,” in a bio, or in a first comment while the pitch lives in the caption) create a deception story even when onboarding was perfect.

A Law Engineer (a licensed attorney with software/product expertise) owns both gates. Engineers build them under that counsel’s oversight.

Field rule — put this on the release checklist: Links without identity are a ratification machine — you keep benefiting after you should have known better. Identity without disclosure is still a deception machine. Ship both gates, or you have a growth dashboard — not Law Engineering.

Side A — What loses#

Don’t ship this. If your current build matches Side A, stop the release train and fix it with counsel.

Instant links, no KYC (LE-19 failure)#

What goes wrong: Growth issues a tracking URL as soon as someone “applies.” Identity, beneficial ownership, tax forms, sanctions screen, traffic-method questionnaire, and sample creatives are “later.” Sub-affiliates cascade without attestation. Finance pays whoever produced CPA events. When complaints or chargebacks spike, the affiliate stays live because revenue is sticky.

Why § 5 theories care (themes): LeadClick shows networks that recruit, approve/edit, and pay publishers using known deceptive formats can face direct participation/control liability — not merely “aiding.” Credit Bureau Center shows merchants that continue accepting affiliate traffic after notice of misconduct invite ratification (and related agency) themes. Onboarding isn’t a statutory safe harbor; it’s the operational fact pattern that defeats — or proves — knowledge and continued benefit.

Lawyer lens — what I’d ask on the call: If counsel can’t show who approved this publisher, what risk rating applied, and when links were suspended after a fake-news lander, ratification arguments write themselves from the payment ledger.

Engineer lens: If GET /affiliate/tracking_link succeeds while approval_state is pending_*, the stack is incomplete.

Undisclosed #ad and rogue claims (LE-18 failure)#

What goes wrong: Commissionable posts ship with no material-connection disclosure, or with “affiliate link” buried under “more,” only in a profile bio, or only in a first comment while the endorsement lives in the main caption/video. Brands can’t prove what was shown at publish time. Monitoring is a quarterly spreadsheet. Creatives claim “clinically proven,” romance “success stories,” or fake-news frames the brand never substantiated.

Why the Guides care (themes): Under § 255.5, unexpected material connections must be disclosed clearly and conspicuously. § 255.0(f) expects disclosures that are difficult to miss, unavoidable in interactive media, and modality-matched. Advertisers are expected to monitor endorsers (§ 255.1(d)). Affiliate Example 11: commissionable links need clear disclosure; staff FAQ language prefers “Ad,” “Advertisement,” “Paid link,” or “I earn commissions…” — “affiliate link” alone may be unclear.

Lawyer lens — what I’d ask on the call: Platform “Paid partnership” tools help; they don’t auto-satisfy caption/audio disclosure for every modality. Fake/gated reviews raise separate Part 465 themes.

Engineer lens: If publish succeeds with disclosure_present=false on a paid campaign, monitoring is fiction.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Tracking links or offer URLs in pending_kyc / pending_review
  
• Payouts without OFAC/SDN screen and named-account controls
  
• No risk_rating, approval_actor, or questionnaire hash on cleared rows
  
• Silent continued payment after suspended for deception
  
• Undisclosed sub-networks where contract bans them
  
• Paid posts without disclosure template / placement metadata
  
• Bio-only or first-comment-only disclosure for main-caption endorsements
  
• No immutable disclosure snapshot / UI archive at publish
  
• No kill switch that 403s links and holds commissions within minutes of a confirmed rogue lander

Side B — What works better#

Here’s the build worth shipping — gates, records, and an export counsel can defend.

Onboarding that can survive an FTC letter (LE-19 theme)#

Think of clearance as a state machine, not a welcome email.

1. Application packet: Legal name, DBAs, geos, traffic sources, verticals, prior terminations, disclosure practices, sample creatives; method disclosure (SEO/paid/email/SMS/social/incentivized) plus sub-affiliate cascading attestation.
   
2. KYC/KYB document classes (practice controls): Collect (or vendor-verify) identity/entity artifacts appropriate to the publisher type — e.g. government ID or passport for individuals; formation docs / EIN or tax ID, beneficial-ownership attestation for entities; W-9/W-8 as finance requires; proof of payout account ownership. Prefer vendor refs over raw image vaults. Run a sanctions / SDN screen (OFAC and counsel-listed lists) before link mint and before first payout; hit → hard stop with dual-control release only. These are program controls, not a money-services AML claim unless the client is otherwise regulated.
   
3. State machine: applied → kyc → risk_review → cleared|rejected; every transition stores actor, timestamp, notes.
   
4. Hard gates: No tracking links until approval_state=cleared and sanctions screen clear; payout batches exclude non-cleared and sanctioned parties.
   
5. Program terms clickwrap before clearance (formation/assent pattern from Chapter 2).
   
6. Monitoring → kill switch: Flag deceptive_traffic auto-suspends links, holds commissions, opens a case queue; clawback authority lives in contract and ops.
   
7. Export: Onboarding zip per affiliate — questionnaire hash, screening refs, approval actor, monitoring disposition.

Adult verticals are often high-risk tier; dating bans fake-profile creatives as a brand-safety overlay. Crypto payouts escalate to regulated KYC/AML depth when in scope.

Disclosures that can survive a Guides inquiry (LE-18 theme)#

1. Composer gate / disclosure proximity: Approved disclosure template above or inseparable from the endorsement content (first lines of caption / pinned / same frame) — not bio-only, not “more,” not first-comment-only while the pitch lives in the main caption or video. Template picker for #ad, “Ad,” “Advertisement,” “Paid partnership with [Brand],” “I earn commissions from links” (staff FAQ language prefers clear “Ad”/“Paid…” forms; “affiliate link” alone may be unclear).
   
2. Preview lint: Contrast/size failures warn; stories need per-frame rules; audiovisual needs on-screen + oral prompts where modality requires.
   
3. Publish API: When campaign.requires_disclosure=true, reject without disclosure_template_id + placement metadata that records proximity (e.g. first_visible_region).
   
4. Link tagging: Wrappers set tracking/rel as needed but never replace visible disclosure.
   
5. Monitoring job: Sample posts; flag missing disclosure; notify creator; escalate per brand program.
   
6. Evidence: Immutable disclosure_snapshot (text + viewport/HTML archive), template version, Guides policy version, enforcement actions.

Compliance checklist (green flags)#

• Links 403 until cleared; payouts honor the same gate
  
• Screening logs + risk rating + approval actor on every clearance
  
• Suspension kills links and holds pay within minutes of confirmed deception
  
• Disclosure templates counsel-approved per locale/channel
  
• Publish blocked without disclosure when program requires it
  
• Snapshots prove first-visible placement at publish time
  
• Rogue-claim / fake-news creatives have a documented kill path
  
• Counsel can export one affiliate packet and one campaign evidence zip

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data — one-page checklists#

Run these as acceptance seeds — not as informal hunches. If you can’t export the Data row, you didn’t finish.

Interface (must-show): KYC/KYB application (document classes, methods, sample creatives); sanctions-screen status before link mint; status (pending_* / cleared / rejected / suspended); program-terms clickwrap; composer disclosure in the first visible region (proximity for #ad / Paid partnership); template picker; preview lint; monitoring case UI.

Interface (must-not): Tracking links while pending; pre-checked “I disclosed” without a template; bio-only / first-comment-only disclosure for main-content endorsements; silent pay after deception suspend.

Code: Links/payouts gate on approval_state=cleared + clear sanctions screen (before link mint and before first payout); state machine with actor/timestamp; monitoring → suspend + case queue; publish 422 without disclosure + proximity metadata when required; wrappers never replace visible disclosure.

Data: affiliates, affiliate_kyc_artifacts (prefer vendor refs), affiliate_screens, affiliate_questionnaires (content_hash), affiliate_approvals, affiliate_monitoring_flags, endorsement_campaigns, creator_posts (template, placement, ui_archive), disclosure_templates, monitoring_hits. Retention: consumer-claim / FTC / tax horizon per counsel.

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Applicant in pending_kyc — can you mint a tracking link? If yes, stop.
   
2. Clear without approval actor / questionnaire hash — row refuses?
   
3. Paid publish with disclosure deleted → 422?
   
4. Live sample: disclosure in first visible caption region (not bio-only)?
   
5. Confirmed rogue lander → links 403 and commissions held within minutes?
   
6. Export one onboarding zip and one campaign disclosure pack. Missing fields = incomplete Law Engineering.

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

Unified payee diligence schema (creators / affiliates / cash referrers / custom-deal payees) — Chapter 8B (LE-73). Cash referral KYC triggers — Chapter 8C (LE-74).

Influencer programs that need the full detect → legal alert → kill loop — not only affiliate KYC + #ad — see the program OS in Chapter 17 (LE-52). CAN-SPAM / TCPA when others mail or text “on your behalf” (LE-20, LE-21).

Dating deceptive creatives (LE-22). Creator KYC overlap (LE-28).

MCC / chargeback pressure from junk traffic (LE-27, LE-26, LE-39). Deeper AML rails when payouts require them (LE-33, LE-34).

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 8B — Worked Example: Unified Payee Diligence Schema#

Pattern family: Unified payee diligence schema — individual vs business (LE-73). Sits after affiliate KYC & endorsement disclosures (LE-18 / LE-19; Chapter 8). Cross-cuts creator onboarding (LE-28; Chapter 13), cash referral triggers (LE-74; Chapter 8C), custom-deal EDD (LE-71), and AML/sanctions themes (LE-33 / LE-34).
Legal anchors (themes): Shared field matrix for creator / affiliate / cash-referrer / custom-deal payees — government ID + liveness, tax W-9/W-8, bank statement / payout-account ownership match, OFAC; KYB adds formation, principal ID, beneficial ownership, optional good standing; tiers minimal|full|edd; API returns missing_fields with 403 when incomplete; store vendor refs not raw identity vaults in product DBs.
As of September 2026: Generic Brand / KYC vendor / Acquirer. No client stack names.

Why this memo exists#

Creators, affiliates, vendors — one diligence shape counsel can defend, eng can enforce.

The story in one glance#

Picture four payout pipes: creators, affiliates, cash referrers, and custom-deal talent.

Each team invented a spreadsheet. Creators need selfie+ID; affiliates need “KYB someday”; referrers get cash with a PayPal email; custom deals skip tax forms until April panic. OFAC runs on Tuesdays for one pipe and never for another. When counsel asks for one payee packet, engineering joins four schemas and still lacks bank-ownership match.

Unify the schema and tiers — specialize UX, not the evidence model.

Walk one payout batch with the payee register open. Ask: did every row clear the same diligence schema before money moved — or did “friend of a friend” skip the gate?

Plain English — one matrix, tiered depth#

Individual: gov ID + liveness; tax; bank/payout ownership match; OFAC.
Business (KYB): formation docs; principal ID (+ liveness as required); beneficial ownership; optional good-standing certificate; OFAC on entity + principals.

Field rule — put this on the release checklist: Prefer kyc_vendor_ref / kyb_vendor_ref in product tables — not raw ID images in the app database.

Remember: a Law Engineer is a licensed attorney with software and product expertise.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“four spreadsheets”)#

What goes wrong: Per-pipe schemas. Cash referrers bypass affiliate KYC. Business affiliates paid to personal accounts without BO. Missing tax forms discovered at 1099 time. OFAC inconsistent. APIs return generic 403 with no missing_fields. Raw scans in S3 next to product media.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Pipe-specific incompatible schemas
  
• Cash payout without full-tier diligence
  
• No ownership match on payout account
  
• Raw ID vault in product DB
  
• Opaque 403 (no missing_fields)
  
• EDD only in email threads (LE-71 miss)

Side B — What works better (shared schema → tier → gate)#

What works better: payee_diligence schema shared across payee_types (creator|affiliate|cash_referrer|custom_deal|…). entity_type individual vs business. diligence_tier minimal|full|edd. Gate payout (and link-mint where applicable) on diligence_state=clear for required tier. API 403 body lists missing_fields[]. Vendor refs + screening refs stored; retrieval via vendor/counsel portal. Cash referral policy (LE-74) maps cash compensation → same gate as affiliates. Custom deals attach EDD register (LE-71). Ongoing monitoring hooks (LE-34) subscribe to payee_id.

Compliance checklist (green flags)#

• One schema, many payee_types
  
• Tier policy encoded
  
• missing_fields on 403
  
• Vendor refs not raw vaults
  
• Ownership match before first payout
  
• OFAC/sanctions refs on clear

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data#

Interface: Unified diligence wizard (branching individual/business); tier progress; clear list of missing fields; payout locked with human-readable reasons.
Code: shared validator; tier policy; payout/link gates; 403 serializer; vendor adapters; monitoring subscribe.
Data: payees; payee_diligence_cases; diligence_fields; vendor_refs; sanctions_screen_refs; tax_form_refs; payout_account_ownership_checks; missing_fields_events.

Lost vs fixed#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Call payout for a creator missing liveness — 403 lists liveness?
   
2. Business affiliate without beneficial ownership — blocked at full tier?
   
3. Confirm product DB has vendor refs, not ID image bytes.
   
4. Cash referrer above threshold — same diligence_state gate as affiliate?
   
5. Export one payee packet across types — same field names?

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Affiliate KYC + disclosures — Chapter 8 (LE-19 / LE-18).
  
• Cash referral KYC triggers — Chapter 8C (LE-74).
  
• Creator onboarding — Chapter 13 (LE-28).
  
• Custom deal EDD — Chapter 13B (LE-71).
  
• AML / sanctions monitoring — Pattern Map LE-33 / LE-34.
  
• Pattern Map LE-73 — Chapter 32.

Field rule — put this on the release checklist: One diligence language for every payee pipe — tiers change depth, not dialect.

This chapter is for education and discussion. It isn’t legal advice. Tier thresholds and field lists are counsel-owned for your facts and jurisdictions.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 8C — Worked Example: Cash Referral KYC Triggers#

Pattern family: Cash referral → KYC trigger (LE-74). Sits after unified payee diligence (LE-73; Chapter 8B) and affiliate KYC (LE-19; Chapter 8). Deepens LE-19 / loyalty–promo themes (LE-51) without duplicating the full affiliate chapter.
Legal anchors (themes): Credits-only referrals vs cash-compensated referrers; cash unlocks the same diligence gate as affiliates; anti-fraud (self-referral, mule accounts); disclosure of referral compensation where endorsement/material-connection themes apply.
As of September 2026: Generic Brand. No client names.

Why this memo exists#

Cash moving to humans triggers KYC and anti-abuse gates. Design them before the promo launches.

The story in one glance#

Picture a “invite friends” growth loop.

Credits-only rewards stay inside the wallet. Then Finance turns on cash payouts for top referrers — same lax email signup. No KYC. No tax form. No OFAC. Affiliates next door still wait in pending_kyc. Fraud rings refer themselves across mule accounts. Marketing calls it “community love” without saying referrers earn cash.

Cash is the trigger. Credits-only can stay light (counsel-tuned). Cash-compensated referrers enter the unified payee diligence gate (LE-73) at the affiliate-equivalent tier.

Walk one cash referral that paid out last week. Ask: what KYC trigger fired before the transfer — amount, velocity, geo, or “we know them”? If the answer is vibe, keep reading.

Plain English — credits vs cash#

Also: disclose material connection when referrers publicly endorse (LE-18 adjacency); clawback / velocity caps (LE-51 adjacency); block self-referral graphs.

Field rule — put this on the release checklist: If cash leaves the platform to a referrer without payee diligence clear, you built an affiliate bypass.

Remember: a Law Engineer is a licensed attorney with software and product expertise.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses (“growth exception”)#

What goes wrong: Referral cash uses a separate micro-ledger with email + PayPal. No join to payees. Affiliates joke that referral cash is the easy path. Self-referral undetected. No compensation disclosure on public invite landers. 1099 surprise. OFAC never ran.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Cash referrer ≠ payee diligence schema
  
• Weaker gate than affiliate for same cash
  
• No self-referral / mule controls
  
• Public endorsement without disclosure
  
• Tax/OFAC after first payout
  
• Credits→cash flip without re-gate

Side B — What works better (mode flag → same gate)#

What works better: referral_compensation_mode = credits|cash|hybrid. Credits path: wallet + fraud graph. Cash path: create/join payee with payee_type cash_referrer; require LE-73 tier clear before first cash payout (and before raising cash limits). Hybrid: mode change event triggers diligence. Anti-fraud: device/payment/graph edges; self-referral deny. Public invite/UGC endorsement: disclosure templates when in scope (LE-18). Monitoring holds (LE-19 spirit) on abuse.

Compliance checklist (green flags)#

• Cash mode requires payee clear
  
• Same schema as other payees
  
• Self-referral blocked + logged
  
• Disclosure where public endorsement
  
• Mode-change re-gate tested
  
• Exportable referral+diligence packet

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.

Interface / code / data#

Interface: Clear “credits vs cash” program rules; cash unlock checklist; payout locked with missing_fields; fraud hold messaging.
Code: mode flag; payee join; gate before cash; self-referral detector; disclosure lint on public referral content.
Data: referral_events; referral_compensation_mode; payee_id join; fraud_graph_decisions; disclosure_events (if public).

Lost vs fixed#

Try this on your product tomorrow#

Screenshots and exports beat opinions.

1. Enable cash for a referrer with empty diligence — payout should 403 + missing_fields.
   
2. Self-referral fixture — denied?
   
3. Flip credits→cash — re-gate fires?
   
4. Public “I got paid to invite” post without #ad/disclosure — lint?
   
5. Export one cash-referrer packet beside an affiliate packet — same field names?

Where this goes next#

Keep the loop moving — Law → Interface → Code → Data → Counsel sign-off.

• Unified payee diligence — Chapter 8B (LE-73).
  
• Affiliate KYC + disclosures — Chapter 8 (LE-19 / LE-18).
  
• Loyalty / promo abuse — Chapter 16 (LE-51).
  
• Influencer program OS — Chapter 17 (LE-52).
  
• Pattern Map LE-74 — Chapter 32.

Field rule — put this on the release checklist: Cash referral is affiliate economics wearing a growth hoodie — gate it like payee cash.

This chapter is for education and discussion. It isn’t legal advice. Thresholds and disclosure scope are counsel-owned.

This chapter is for education and discussion. It is not legal advice. Re-check primary authorities for your facts and jurisdiction before you ship.

Chapter 9 — Worked Example: DMCA Notice & Counter-Notice Intake#

Pattern family: DMCA notice / counter-notice intake (LE-15); feeds repeat-infringer policy (LE-16)
Legal anchors: 17 U.S.C. § 512—harbors (a)–(d) (§ 512(n)); § 512(i) repeat-infringer + STM; agent § 512(c)(2) / 37 C.F.R. § 201.38 (3-year validity); notice § 512(c)(3)(A); expeditious removal § 512(c)(1)(C); put-back § 512(g) (10–14 business days unless suit notice); § 512(f)/(m)/(l). Practice: Perfect 10 v. CCBill, 488 F.3d 1102 (9th Cir. 2007); Ellison v. Robertson, 357 F.3d 1072 (9th Cir. 2004); Motherless, 885 F.3d 597 (9th Cir. 2018); knowledge specificity Viacom, 676 F.3d 19 (2d Cir. 2012); Veoh, 718 F.3d 1006 (9th Cir. 2013); Lenz, 815 F.3d 1145 (9th Cir. 2016) (sender fair-use consideration).
As of September 2026: Cox Communications, Inc. v. Sony Music Entertainment, 607 U.S. ___ (Mar. 25, 2026), narrowed contributory liability themes for conduit ISPs—it does not repeal § 512 for UGC hosts and preserves § 512(l). Don’t merge DMCA intake with TAKE IT DOWN or NCII intakes. “Expeditious” isn’t a fixed statutory hour count—document a business SLA without inventing a fake “statutory 24h.”

A Friday question that exposes the harbor#

Illustrative teaching figure. Not official screenshots of any party’s product.

Counsel asks a simple Friday question: “Show me the last compliant DMCA notice we processed end to end.”

On the lost side, someone digs through a personal Gmail, a Slack thread, and a soft-hidden URL. There is no removed_at. There is no counternotice calendar. High-ARPU uploaders never meet a strike ladder. A notice that arrives as a Twitter DM screenshot bounces forever instead of normalizing into statutory elements and an honest clock.

On the fixed side, the answer is an export: published agent matching the Copyright Office directory, a validated six-element notice, ticketed expeditious removal, subscriber notice, 10/14 business-day put-back clocks, and a strike event feeding repeat-infringer policy.

Safe harbor is not a vibe. It is a path you can replay — agent designation, six-element notice, removal clock, counternotice calendar. And remember the harbor lesson that feeds Chapter 18: companies have lost DMCA safe harbor because they did not terminate repeat infringers. A policy on paper is not enough. You need to track strikes and terminations and present that ledger in evidence when harbor is on the line.

Why § 512 is an engineering problem (plain English)#

Safe harbor under the Digital Millennium Copyright Act is something courts check in the stack.

Did you designate an agent?
Did you implement notice-and-takedown?
Did you act expeditiously on identified material?
Did you honor put-back?
Did you reasonably implement a repeat-infringer policy?

“We take copyright seriously” is marketing. Exportable timestamps, hard disables, and a calendar that knows business days are Law Engineering.

Remember: a Law Engineer is a licensed attorney with software and product expertise. Engineers build these gates under that counsel’s oversight.

Field rule — put this on the release checklist: Statutory elements → form → expeditious removal → counternotice clocks → repeat-infringer feed. Skip a link and the harbor story breaks.

Review this with counsel and eng on the same call. If Side A matches production, you’re still in the memo-to-coders handoff.

Side A — What loses#

Don’t ship this. If your current build matches Side A, stop the release train and fix it with counsel.

Email-only agent and missing fields#

What goes wrong: “DMCA: legal@startup.com” in the footer. The inbox auto-filters to promotions, or the only person who monitors left the company.

Notices arrive as PDFs in support chat. The form (if any) demands non-statutory extras as a condition of processing, or skips the signature / good-faith / perjury elements.

Location is “all infringing files on your site.”

Why this matters in court / before a regulator: § 512(c)(2) and 37 C.F.R. § 201.38 require public availability and Office designation; designations expire after three years unless amended/resubmitted. Ellison themes: a dead agent inbox isn’t implementation. CCBill themes: substantial compliance with the statutory elements — don’t invent extra formats as mandatory gates, and don’t treat deficient notices as effective knowledge notices without a cure path.

Lawyer lens — what I’d ask on the call: Failure to designate is a complete bar to (c)/(d) harbors for the period of non-designation. Directory parity is a launch checklist item, not a nice-to-have.

Engineer lens: If received_at is “when someone opened Slack,” expeditious action is unprovable.

No clocks, no strike ladder#

What goes wrong: Removals happen “when we can.” Subscribers never get notice. Counternotices are Word docs. Someone restores early to calm a creator, or restores never. Repeat uploaders keep accounts because ARPU is high. Intimate-image and copyright tickets share one “IP” queue.

Why this matters in court / before a regulator: § 512(g) restore is not less than 10 nor more than 14 business days after counternotice unless the complainant notices a filed action. Early restore and late restore are both process failures. § 512(i) requires a reasonably implemented and informed repeat-infringer policy — Motherless themes: reasonableness ≠ perfection, but a policy that never terminates anyone isn’t reasonable implementation.

Lawyer lens — what I’d ask on the call: Harbor loss ≠ liability (§ 512(l)) — but earn the harbor when you can. Don’t overread Cox (2026) as a UGC-host free pass.

Engineer lens: Without server-enforced restore_not_before / restore_not_after, put-back is a calendar invite.

Any hit means you don’t ship yet.

Non-compliance checklist (red flags)#

• Unmonitored / auto-deleting agent email; public contacts ≠ Office directory; expired designation (no T-90 alert)
  
• Form missing any of the six § 512(c)(3)(A) elements; non-statutory extras required to process (CCBill anti-pattern)
  
• Soft-hide without hard disable; no removed_at / operator_id
  
• Restore before day 10 business or after day 14 without a rule engine
  
• DMCA merged with TIDA/NCII/CSAM; no strike event into the repeat-infringer ledger

Side B — What works better#

Here’s the build worth shipping — gates, records, and an export counsel can defend.

Intake that can survive a harbor motion (LE-15 theme)#

Walk the path once, end to end.

1. Designate and publish: Agent name, address, phone, email on a public /dmca (or equivalent) matching the Office directory; calendar 3-year renewal; alert at T-90 days; treat new legal entities / brand URLs as designation events.
   
2. Statutory form — element checklist on the page: Fields map 1:1 to the six § 512(c)(3)(A) elements; confirmation number on submit; clear banner that this path is copyright only, with links to intimate-image / other abuse intakes. Spell the checklist in the form (labels counsel owns):
   1. Physical or electronic signature of a person authorized to act for the owner
      
   2. Identification of the copyrighted work claimed infringed (or representative list if multiple)
      
   3. Identification of the material claimed infringing and information reasonably sufficient to locate it (URL / content_id — not “entire site”)
      
   4. Contact information reasonably sufficient to contact the complaining party (address, telephone, email)
      
   5. Statement of good-faith belief that use isn’t authorized by the owner, its agent, or the law
      
   6. Statement that the information is accurate, and under penalty of perjury, that the sender is authorized to act on behalf of the owner
      
3. Classify notices: full / partial / deficient; substantially compliant → job; defective but with work/location/contact → cure prompt ((c)(3)(B) logic) — don’t sit on compliant notices because some other notices are abusive. Non-statutory extras may be optional; don’t make them a processing condition (CCBill anti-pattern).
   
4. Expeditious removal: Disable identified URLs/content_ids; store received_at, removed_at, operator; notify subscriber.
   
5. Counternotice wait themes: Counternotice form with § 512(g)(3) elements. On valid counternotice: notify the original complainant; set restore_not_before / restore_not_after on a business-day calendar (not less than 10 nor more than 14 business days after the provider receives the counternotice, unless the complainant timely notifies that a suit seeking a court order has been filed). Block early restore; block late restore without a rule; suit notice cancels put-back.
   
6. Strike feed / thresholds as policy-as-code: Each qualifying notice emits a repeat-infringer evaluation event for LE-16 — separate from NCII/TIDA strike classes. Encode strike thresholds, grace, and termination ladders as versioned policy (e.g. N qualifying strikes in window W → warn / restrict / terminate), with human review hooks counsel defines — not ARPU exceptions that silently skip the ladder. The full warn → restrict → terminate ladder, exportable strike ledger, and no-silent-VIP gates are worked in Chapter 18 (LE-16).
   
7. Export ledger: Notices, counternotices, actions, agent designation proof, content hashes for disabled objects — multi-year retention (counsel; often ≥ 3–7 years); WORM preferred. Operational fingerprint / perceptual-hash matching (LE-35 / Chapter 19) may assist discovery of copies but does not replace this statutory notice path or mint strikes unless counsel’s LE-16 rule says so.

Adult UGC follows the same process (Motherless themes — adult ≠ inherently infringing). Marketplace: disable SKU media and notify the seller. Hosted generative outputs still take DMCA notices.

Compliance checklist (green flags)#

• Directory parity test passes (scraped public contacts == stored registration)
  
• Form captures all six elements; confirmation ID issued
  
• Substantially compliant notice → hard disable + timestamps + subscriber email
  
• Counternotice window enforced 10–14 business days
  
• Suit notice suppresses restore
  
• Agent expiry alert live
  
• Separate menus/schemas for copyright vs intimate-image vs CSAM
  
• Strike events append to the LE-16 ledger
  
• Counsel can export a full notice/action pack without Slack archaeology

Template: Lawyer / Engineer card#

Lawyer column = legal meaning. Engineer column = what must be true in the stack.