US State Privacy Navigator

Cross-jurisdictional applicability, gap analysis, and deliverable generation for the US state consumer privacy patchwork. Authored for legal practitioners and privacy professionals who need defensible, citation-ready output rather than vendor-style checklists.

What this skill does

1. Applicability triage. Given a business profile, returns a per-state applicability verdict (Applies / Likely Applies / Does Not Apply / Insufficient Info) with the threshold reasoning shown.
2. Gap analysis. Compares current practice to each applicable law's controller obligations and consumer rights, produces a severity-scored issue log, and prioritizes remediation.
3. Deliverables. Generates a memo (Markdown) and a formal client-ready deliverable (.docx) including the applicability matrix, gap log, and remediation roadmap. Where requested, drafts state-compliant notice clauses keyed to the specific obligations triggered.
4. DSAR / consumer-rights orchestration. Routes a single consumer request to the correct response procedure based on the requester's residency, the right invoked, and the controller's status under each law.

When to consult what

This SKILL.md is the orchestrator. The depth lives in references/. Read references on demand — never preload all of them.

Core operating principles

These are not suggestions. They preserve the defensibility of any analysis this skill produces.

1. Statutes over recollection. State privacy law has changed faster than most training data. When the user names a state or cites a code section, treat the reference files as ground truth and flag any conflict between the user's recollection and the reference. If neither the references nor the user supplies a citation for a contested point, say so explicitly — never fabricate code sections, regulatory citations, or AG enforcement actions.
2. Applicability first. Never analyze obligations until you have run applicability through the threshold tests. A business that does not meet a state's threshold has no obligations under that statute; pretending otherwise wastes the user's time and makes the work product unusable.
3. Status before duties. US state privacy laws split obligations between controllers and processors (CA uses business / service provider / contractor / third party; the other 19 use controller / processor). Identify the entity's status under each applicable law before assigning duties.
4. Personal information ≠ consumer. Most state laws exclude employee, applicant, B2B contact, and certain HIPAA/GLBA/FCRA-covered data from "consumer" or from coverage entirely. California's CCPA/CPRA covers employees and B2B; the other states generally do not. Apply the entity-and-data-type filter before assuming a duty attaches.
5. Distinguish "sale" from "sharing" from "targeted advertising" from "profiling." These are statutorily distinct and each triggers different opt-outs and disclosures. Sloppy collapsing of these terms is the most common error in vendor compliance work; it must not appear in this skill's output.
6. Cite as you go. Every non-trivial obligation, threshold, or right asserted in the output must carry an inline citation to the relevant state code section, regulation, or AG/AGO guidance. Format: (Cal. Civ. Code § 1798.140(d)), (Va. Code § 59.1-575), etc. If the citation isn't in the references, mark the assertion [citation needed — verify before reliance].
7. No legal advice posture. Outputs are analysis and drafts for review by qualified counsel admitted in the relevant jurisdiction. Include this disclaimer in every formal deliverable. This is not a CYA reflex — it sets the user's expectation about how to use the output.
8. AD/BC dating where dates appear in formal deliverables. Use AD/BC, not CE/BCE.

Standard workflow

This is the logical sequence, not a rigid script. Skip steps when the user has already supplied the input. Slow down or speed up to match the user's sophistication.

Intake → Applicability triage → Status determination → Conflict-of-laws synthesis →
Gap analysis (with precedent matching + AG-priority weighting) →
Remediation prioritization → Deliverables (memo + DOCX) →
Citation audit → Optional: clauses, DSAR routing

Step 1 — Intake

If the user opens with a specific narrow question ("does Colorado apply if I make $20M and have 80,000 CO customers?"), answer it directly using the relevant references.

If the user opens with an open-ended request ("help me get compliant" / "I'm hiring a privacy counsel and need a baseline"), run a structured intake. Read references/workflows/intake-questionnaire.md and ask the questions in batches of no more than 5 at a time. Do not ask one question at a time — that wastes the user's clock.

Critical intake categories: entity & corporate structure; revenue and consumer-volume thresholds; data categories processed (and whether any are sensitive); whether the entity sells data, shares for cross-context behavioral advertising, profiles individuals, or processes minors' data; channels (website, mobile, offline, hardware); B2B vs B2C; existing notices and contracts; sectoral overlay (HIPAA/GLBA/FCRA/COPPA).

Step 2 — Applicability triage

For each state, run the state's threshold test. The thresholds are not all the same — California uses revenue or consumer count or data-sale share; Texas has no numerical threshold but excludes SBA-defined small businesses with sensitive-data carve-outs; Florida has a $1B narrow trigger. See references/applicability-matrix.md for the master matrix.

Output a table with columns: State | Statute | Applies? | Reasoning | Effective Date / Enforcement Status. Mark "Insufficient info" rather than guessing — and list the specific input you'd need.

Step 3 — Status determination

For each applicable state, determine whether the entity is a controller, processor, third party, service provider/contractor (CA-specific), or some combination by data flow. For anything more nuanced than a clearly-controller posture, read references/workflows/status-determination.md and run the decision tree per data flow. A SaaS vendor processing customer data is typically a processor for that data and a controller for its own business contacts and marketing data. Many entities are dual-status. State this explicitly per data flow, with a per-flow status table per the workflow file.

Step 3.5 — Conflict-of-laws synthesis (multi-state engagements)

Where two or more states are applicable, do not stop at parallel state analyses. Run scripts/conflict_resolver.py --states CA,VA,CO,... to synthesize the binding constraint across applicable states (the "compliance ceiling"). For each of ~13 compliance dimensions (notice content, sensitive-data treatment, sale of sensitive data, minor treatment, response time, appeal right, UOOM recognition, opt-out persistence, processor contract terms, DPA requirements, etc.), the script returns the strictest applicable rule, the controlling state, the citation, and other states' positions for context. Use the output to drive a unified-implementation recommendation rather than a state-by-state checklist that the controller cannot operationalize.

Step 4 — Gap analysis

For each applicable state, walk through references/controller-duties.md and the relevant states/<xx>.md, comparing each statutory duty against current practice. Score each gap using the methodology in references/workflows/gap-analysis-method.md:

• Severity (1–5): regulatory exposure if challenged, considering enforcement priors and cure availability.
• Likelihood (1–5): probability a regulator, plaintiff, or consumer surfaces the gap.
• Score = Severity × Likelihood. Levels: Low (1–6), Medium (7–12), High (13–19), Critical (20–25).

Adjust the score by AG posture. Read references/ag-priorities.md and apply the heuristic adjustments from the "Risk weighting in gap analysis" section: a gap implicating a stated Tier 1 AG priority (CA, TX, CO) gets +1 severity; a gap in an industry currently under sweep (connected vehicles, healthcare-pixel, child-directed apps, etc.) gets +1 likelihood; a gap subject to an active cure period gets -1 severity.

Match each material gap to analogous enforcement actions. Use scripts/precedent_match.py with violation-theory tags from the corpus (e.g., --tag gpc_not_honored --tag no_donotsell_link --state CA) to pull the 3-5 most analogous prior actions from references/enforcement_actions.json. Cite the most directly analogous matter with the operational lesson and headline figure in the gap-log entry. This shifts the work product from "here's the rule" to "here's what happened to companies in your shoes."

For the highest-severity gaps, also pull defense-side framing from references/defense-arguments.md so the deliverable shows both the exposure and the recovery posture.

Surface cross-cutting gaps — e.g., a single missing disclosure that creates exposure under 8 statutes is a higher-priority fix than a CA-only edge case.

Step 5 — Remediation prioritization

Sort gaps by Score, then bucket into 0–30 day, 31–90 day, and >90 day / strategic lanes. Note dependencies — e.g., updating the privacy notice often depends first on completing a data inventory; flag that.

Step 6 — Deliverables

Generate two artifacts:

1. Markdown memo. Use assets/memo-template.md as the skeleton. Substantive content fills in. Save to the working directory.
2. DOCX deliverable. This is the formal client-ready version. Always read the docx skill (which is generally available alongside this one) before generating. Then run scripts/generate_docx_memo.js with a JSON payload built from the analysis. The script is idempotent and produces a US Letter document with covers, TOC, the applicability matrix, gap log table, and remediation roadmap.

Both artifacts must include the no-legal-advice disclaimer and a "Limitations and assumptions" section that lists what the analysis depends on (e.g., revenue figures provided by user, data flows as described, no anomalous facts not yet known).

Step 6.5 — Citation audit (mandatory pre-delivery QA)

Before finalizing the markdown memo, run scripts/citation_audit.py --input <memo>.md --strict. The auditor enforces the citation discipline mandated in the operating principles:

• Every substantive claim (assertion of obligation, right, threshold, or penalty) must carry an inline citation.
• Citations must match canonical formats for the relevant statute (e.g., Cal. Civ. Code § 1798.140(d), Va. Code § 59.1-575, 4 CCR § 904-3).
• Section numbers cited must be plausible (e.g., Cal. Civ. Code § 1798.X must fall in the CCPA codified range).
• "CCPA" / "CPRA" should not be reified as separate statutes outside parentheticals.
• No [citation needed] markers should remain in the final memo.

Do not deliver a memo with audit errors. Warnings are reviewable; surface them to the user when flagged.

Step 7 — Optional: notice clauses and DSAR routing

If the user asks for model clauses (notice-at-collection, opt-out disclosures, sensitive data notice, financial incentive notice), pull the matching template from assets/notice-clauses/ and adapt it to the entity's specific facts. Never paste a template verbatim — it must be tuned to the data categories, purposes, retention periods, and recipients actually in play.

If the user asks how to handle a specific consumer request, follow references/workflows/dsar-routing.md.

Output discipline

• Tables for comparisons. When showing multi-state output, always use a table. Prose comparisons of 5+ states are unreadable.
• Citations inline. Every obligation, right, threshold, or penalty figure must carry a code section. If you can't cite it, flag it.
• Quantify uncertainty. If applicability is borderline (e.g., consumer count near 100k threshold), say so and explain what would tip it.
• No marketing language. Do not write "industry-leading," "robust," "best-in-class," or "comprehensive privacy program." This is legal analysis, not a brochure.
• Active voice and concrete subjects. "The controller must provide" — not "It must be provided."
• AD/BC for any dates referenced narratively. Statute citations and effective dates use the form on the books.

Common errors to avoid

These are the failure modes that show up repeatedly in privacy work product. The skill exists in part to prevent them.

1. Conflating CCPA and CPRA. CCPA was the original 2018 act; CPRA (2020) amended it, created the CPPA agency, and added rights and obligations effective Jan 2023. Always cite the consolidated Cal. Civ. Code §§ 1798.100 et seq., not "CCPA" or "CPRA" as if they were distinct statutes.
2. Treating "sensitive data" as one concept. California uses "sensitive personal information" with an opt-out / right-to-limit-use structure. The other 19 states use "sensitive data" with an opt-in (consent) requirement before processing. The structural difference matters.
3. Missing the universal opt-out signal mandate. CO, CT, OR, MT, NJ, NH, MN, MD, DE, and others require recognition of universal opt-out mechanisms (e.g., GPC). California also recognizes GPC for opt-out of sale/share. Do not omit this.
4. Forgetting employee and B2B coverage. California is the outlier — employee/applicant data and B2B contact data ARE within CCPA/CPRA scope. The other states generally exclude these. Outputs that lump them together are wrong.
5. Stating cure periods as permanent. Many states had cure periods at enactment that have since sunset (e.g., California's general 30-day cure sunset under CPRA; Colorado's cure period sunset Jan 2025). Verify against references/enforcement.md rather than memory.
6. Stale threshold figures. Texas excludes SBA small businesses but with carve-outs for sensitive-data sales without consent. Florida's threshold is narrowly tied to $1B revenue plus enumerated activities. Don't paraphrase from memory; cite.
7. Skipping the kids' overlay. California's Age-Appropriate Design Code (partial preliminary injunction history; check references/kids-and-teens.md), CT/CO teen-specific provisions, and federal COPPA all overlay state laws when minors are present. State-only analysis without this overlay produces incorrect output.

Limitations of this skill

• The reference files reflect law as of the version date in this skill's frontmatter. Laws change; new states pass laws (NM, IL biometrics, etc.) and existing laws are amended (CPPA rulemaking on automated decision-making, profiling, risk assessments). When a question turns on a development that may post-date the reference, say so and recommend the user verify with a current source.
• The skill produces analysis and drafts. It does not file registrations (e.g., California or Texas data broker registration), submit risk assessments to regulators, or constitute the practice of law. A licensed attorney must review.

What this skill is not for — explicit scope and referrals

This skill is a state privacy patchwork navigator. It is deliberately narrow, and that narrowness is what makes it useful. Several adjacent regimes intentionally fall outside the scope. If the user's question is purely within one of the regimes below — without a state privacy overlay — this skill is the wrong tool, and continuing to answer with it produces low-quality work product. Recommend a sectoral resource and stop.

Federal sectoral regimes (out of scope standalone; in scope as overlay).

• HIPAA (Privacy Rule, Security Rule, Breach Notification Rule) — use a HIPAA-specific resource for standalone analysis.
• GLBA (Privacy Rule / Reg P, Safeguards Rule) — use a GLBA-specific resource for standalone analysis.
• COPPA Rule compliance (notice, VPC mechanics, internal-use exception, 2025 amendments) — use a COPPA-specific resource for standalone analysis.
• FERPA disclosure analysis, school-official exception, directory information — use a FERPA-specific resource for standalone analysis.
• FCRA furnisher obligations, dispute mechanics, permissible-purpose, adverse-action notices — use an FCRA-specific resource for standalone analysis.
• NYDFS Part 500, FTC Safeguards Rule expansion, HHS Reproductive Health Privacy amendments standalone.

When any of the above intersect with state privacy law (e.g., a HIPAA covered entity asking about CCPA obligations for non-PHI marketing data; a GLBA-regulated bank asking about CPA's coverage of B2B data; a COPPA-subject service asking how MD's flat ban on minor targeted advertising layers on top), references/federal-overlays.md is the right place to start. The overlays file is a bridge, not a standalone navigator.

Other adjacent regimes (out of scope entirely; recommend dedicated skills).

• GDPR / UK GDPR / non-US privacy regimes (Canadian PIPEDA / Quebec Law 25, Brazilian LGPD, etc.) — entirely different paradigm.
• State biometric laws standalone (Illinois BIPA, Texas CUBI, Washington biometric) — though enforcement actions appear in the corpus where they intersect with state privacy work.
• State consumer-health-data laws standalone (Washington MHMDA, Connecticut amendments, Nevada SB 370) — though private-right-of-action filings appear in the corpus.
• State AI-specific laws (Colorado AI Act, NYC Local Law 144, Utah AI Disclosure Act).
• State social-media / minor-platform laws (CA SB 976, NY SAFE for Kids, FL HB 3, TX SCOPE Act) — distinct from state comprehensive privacy law's minor provisions.

Quickstart prompts

The skill is most useful when the user provides structured inputs. If they don't, drive the intake. Examples of well-formed prompts:

• "I run a Series-B SaaS, $40M ARR, US-only, 200k US consumer-end-user accounts (40k California, 30k Colorado, 8k Connecticut, scattered elsewhere). We don't sell data but we run Meta and Google Ads with their pixels for retargeting on logged-out marketing pages. Which state laws apply, and what's our top-5 priority remediation list?"
• "Consumer in Oregon emailed asking us to delete their data. We're a healthcare-adjacent vendor (not a covered entity). Walk me through the response."
• "Draft a notice-at-collection that satisfies California, Colorado, and Connecticut for an e-commerce company that uses third-party analytics, runs targeted ads via cross-context behavioral advertising, and offers a loyalty program with a discount for email signup."

If a user prompt is vague, run intake. If a user prompt is sharp, answer sharply.