CCPA "do not sell," cryptographically proven

The CCPA — as amended by the California Privacy Rights Act — gives California residents a small bundle of rights you have to honor on a forty-five-day clock. Most companies focus on the easy ones: right to know (§1798.110), right to delete (§1798.105). The hard ones are the two CPRA added in 2023 and the one that's existed since 2018 but nobody can actually prove.

The three hard ones

§1798.115 — twelve-month sharing lookback. Every sale or share of personal information over the prior year, with whom, and for what purpose. Your data warehouse, your ad networks, your service providers. Most companies can't produce this for one customer in less than a week.

§1798.121 — limit use of sensitive personal information. If a customer invokes this, you must prove that their location data, financial information, race/ethnic origin, sexual orientation, and so on, have only been used for the explicit purposes you disclosed. Not "we hope so" — proof.

§1798.135 — do not sell or share. This has been live since 2018. It's the right where most stacks silently break. The customer opts out, and your ad-network integration keeps firing because nobody wired the opt-out signal to the integration. You don't find out until the CPPA shows up.

What evidencing them requires

If you think about what these three rights actually demand of your engineering stack, it's:

1. Every share is recorded with a recipient, a purpose, and a timestamp. Not a summary — every single share.
2. Every read of sensitive PI carries its purpose tag. Enforced at the planner level, not by hope.
3. Every share post-opt-out is blocked at the planner, with the denial chained. So you can later prove zero leaks.

That's three different invariants, and almost no production stack has them all. In InvariantDB they're three properties of the same engine.

The §1798.135 proof

This is the one that surprises auditors. When a customer hits "Do Not Sell My Information," the click is recorded as a node with a timestamp. From that moment forward, every read of that customer's data passes through a planner check against the global opt-out gate. Reads that would have produced a share to an ad network or other downstream processor get denied before they reach the data, and the denial itself is chained.

The proof is one procedure call:

CALL db.aclEvents('customer:c44219', after='opt-out-ts')
YIELD attempted, denied, leaked
RETURN attempted, denied, leaked

For one customer in the live demo, the chain shows 168 attempted shares after the opt-out — every one of them blocked at the planner, none of them reaching the customer's data, none of them firing to an ad network. Zero leaks.

The chain is cryptographic. If any of those 168 attempts had silently succeeded — if a single ad-network integration had managed to share the customer's data after opt-out — the chain would show it. It doesn't.

The §1798.121 sensitive-PI lineage

For each sensitive-PI field, the engine records every read with its declared purpose. db.derivedFrom on the sensitive-PI node returns every use — fraud detection reads of location data, transaction verification reads of financial data — with the purpose tag. If a marketing system tried to read race or sexual orientation, the planner denied it, and the denial appears in the chain.

"We never used your race for ad targeting" stops being a sentence in a lawyer letter. It's a one-query proof.

The numbers

CPPA fines start at $2,500 per unintentional violation and reach $7,500 per intentional violation. The catch is the "per resident" multiplier — if your integration leaked data on ten thousand customers, that's seventy-five million dollars. Once you add class-action liability on top, this becomes the single largest privacy-compliance risk a California consumer brand carries.

InvariantDB customers handle full CCPA/CPRA multi-right requests in under two minutes. Live walkthrough on the California tab — pick it up there.