When a California resident asks how an automated system decided something about them, the business does not always have to produce a row-by-row account. Section 7222(j) of the California Consumer Privacy Act (CCPA) regulations lets a business that has used the technology on that person more than four times in 12 months answer with a summary instead. Most guidance on the access right skips that sentence, and it decides what your system has to be able to do on 1 January 2027.
The short version: a scheduling tool that touches the same worker every week can answer with an aggregate, and a one-time credit decision cannot. So you may need two response modes, and a counter that picks between them.
What does section 7222(j) allow?
An ADMT access request is a consumer's request, under section 7222 of the regulations adopted by the California Privacy Protection Agency (CPPA), for information about a business's use of automated decisionmaking technology (ADMT) to make a significant decision about them. The regulations carry an effective date of 1 January 2026, and section 7200(b) sets 1 January 2027 as the date a business already using ADMT for a significant decision has to comply.
Section 7222(j) says that a business that used an ADMT with respect to a consumer more than four times within a 12-month period may provide an aggregate-level response. The text is specific about what that means for the logic explanation required by section 7222(b)(2). The business may provide a summary of the outputs with respect to the consumer over the preceding 12 months, the parameters that, on average over those 12 months, affected the outputs, and a summary of how those parameters applied to the consumer.
Note the word "may." The relief is optional, and it is written for one item only.
How do you count "more than four times"?
Four is not enough. The threshold is more than four, so five uses in 12 months qualifies and four does not. A model that re-scores someone quarterly sits exactly on the line and stays on the row-level path. One that re-scores monthly is well past it.
What counts as one "use" is the part the regulation does not define in this subsection. My reading is that each time the ADMT is run to produce an output about that person for a significant decision is one use, because that is the unit the rest of section 7222 talks about. That is a reading, and the subsection does not settle it. Have counsel confirm how your product counts before you build a counter around the answer.
The window is "within a 12-month period," and the aggregate covers "the preceding 12 months." Build it as a rolling window anchored on the date the request arrives, not a calendar year.
What does the aggregate answer have to contain, and what still has to be individual?
The three parts of the summary, taken from section 7222(j) of the regulation:
- 1.A summary of the outputs with respect to the consumer over the preceding 12 months.
- 2.The parameters that, on average over the preceding 12 months, affected those outputs.
- 3.A summary of how those parameters applied to the consumer.
Read what is not in that list. Section 7222(j) refers to the information required by subsection (b)(2), the logic. It does not mention the other items in section 7222(b): the specific purpose in (b)(1), the outcome of the decisionmaking process in (b)(3), or the non-retaliation statement and instructions in (b)(4). I would plan on those staying as they are. The shortcut is narrower than "send a summary instead of an answer."
It is also an average. The parameters have to be those that affected outputs "on average" across the year, which means your system needs to be able to compute an average feature contribution per person per window, not just store a final score. If your model cannot say which inputs moved an output, an aggregate that names parameters is as hard to write as a row-level one.
Section 7222(l) separately says a business may give more than the minimum, and offers an example: the range of possible outputs, or the five most common outputs and the percentage of consumers who received each in the preceding calendar year. That example gives you a cheap way to make an aggregate answer more useful to the person reading it.
A worked example
Picture a 30-person workforce-scheduling SaaS company. Its optimiser assigns shifts for retail customers with California employees, and it publishes a new schedule every week. For a worker on that system, the tool has produced an output about them roughly 52 times a year. Allocation of work is one of the significant-decision categories in section 7001(ddd)(4)(B), so the tool is in scope, and the hiring and work-allocation exception analysis is about whether the worker can opt out. Whether the worker can ask how it decided is a separate question, and section 7222 answers it.
A worker asks for access in March. Pulling 52 schedule decisions with per-decision logic would be a long document nobody learns from. Under section 7222(j) the company can instead send the shift types and hours the worker was assigned over the preceding 12 months, the inputs that on average affected those assignments (availability windows, certifications, tenure, say), and how those inputs applied to this worker.
Now compare a lending platform that scores an applicant once. There is no aggregate to give, because the 12-month count is one. The company has to explain that decision, and the record of it has to exist, which is what the ADMT access response post is about. Same regulation, same section, different build.
What should you build?
- A per-person decision counter over a rolling 12-month window, keyed to the person and the decision type. It is a query on your decision log, not a new datastore, if the log records the person, the tool and the timestamp.
- Both response modes. The aggregate is permitted, not required. A business whose customers or counsel prefer row-level answers still needs to produce them, and eligibility for a summary does not stop you from answering in detail where a customer or counsel prefers it.
- A stored per-decision feature contribution, if you want to use the aggregate at all. Without it, the "on average, which parameters mattered" sentence cannot be computed after the fact.
- A switch you can explain. When the counter says "more than four" and you choose the aggregate, log that it was chosen and why. If the count is later disputed, that row is your evidence.
When is the aggregate the wrong thing to build?
Three cases. If each person is decided about once or twice a year, as with a mortgage or an admissions decision, you will almost never reach five and the work is wasted. If your model cannot attribute outputs to inputs, build the logging first, because the aggregate does not escape that requirement. And if your customers are the businesses that receive the request, they may insist on row-level answers in their contracts, in which case the aggregate path is dead weight for those accounts.
For an HR or scheduling vendor, the reverse is true: high-frequency decisions about the same person are the product, and the aggregate path is probably the one that will carry most requests. That is where I would spend the engineering, and counsel's time should go on the counting rule rather than the template.
What this means for your team
- Count, per significant decision your product makes, how often the same person is decided about in 12 months. That one number tells you which response mode you will use most.
- Get a written position from counsel on what counts as one use.
- Store enough per decision to compute an average parameter effect later.
- Keep the row-level path. It is the default, and the aggregate is the exception you earn by volume.
If you would like a second pair of eyes on which of your decisions are in scope, the ADMT checker is a free first pass. When you want help building the counter, the decision log and both response modes, our ADMT compliance engineering work covers exactly that, and you can tell us what you are building. This article is not legal advice.
Sources
- California Privacy Protection Agency: CCPA statute and regulations, effective 1 January 2026 (sections 7001(e), 7001(ddd), 7200(b) and 7222, read directly from the PDF on 27 October 2026)
