California SB 942: the four duties, and the evidence each one leaves behind
SB 942 is operative 2 August 2026. It tells covered providers what to embed, what to
offer, what to run, and how fast to revoke. It does not tell them how to prove any of it afterwards.
That gap is what this page is about.
$5,000Per violation. Each day of a continuing violation is a separate violation.
Threshold
1,000,000Monthly visitors or users. Measured at the provider, not the deployer.
Enforced by
AGAttorney General, city attorneys, county counsel. A prevailing plaintiff recovers fees.
01The clock
SB 942 passed in 2024 with a 1 January 2026 start. AB 853 moved it, and the new date was not
arbitrary: California landed on the same day the EU AI Act's transparency article begins to apply.
A provider serving both markets gets one deadline, not two.
The California AI Transparency Act is signed
Adds a new chapter to division 8 of the Business and Professions Code, with an original
operative date of 1 January 2026.
Amended, delayed, and widened
AB 853 pushes the operative date to 2 August 2026 and extends the regime beyond the original
covered providers to further classes of duty holder on later dates.
The four duties attach
Latent disclosure, the manifest disclosure option, the public detection tool, and the
96-hour revocation duty are all live. Penalties accrue per day.
EU AI Act Article 50 begins to apply
The marking and disclosure obligations of Regulation (EU) 2024/1689 start on the same date.
The EU duties are different in shape — one
evidence trail can answer both, but only if it was designed to.
02Are you covered?
This is the first question every reader has, and most summaries bury it. The test is narrow, and
it lands on the builder of the system rather than the business that merely uses one.
Do you create, code, or otherwise produce a generative AI system — as opposed to buying
access to somebody else's?
Is that system publicly accessible in California?
Does it have more than one million monthly visitors or users?
Three yeses makes you a covered provider, and all four duties attach on
2 August 2026. A company that only calls a third-party model through an API is generally not the
covered provider for that model — but read duty four, because licensing somebody else's covered
system carries its own obligation, and it runs on a 96-hour clock.
Two things about that third question are widely misread, and both come from the drafting
history rather than from any commentary.
There is no measurement window. As introduced, SB 942 counted users "on average
over the preceding 12 months." An Assembly committee amendment in June 2024 struck the averaging
clause, and no committee discussed the deletion. What survives is a bare threshold with no lookback
at all — so a system that crosses one million in a single month has, on the face of the text,
crossed it. AB 853 later wrote further thresholds with windows and did not restore one
here.
The count is not California-only. The enacted text counts visitors and users;
it does not limit them to the state. An Assembly analysis of AB 853 glosses the law as reaching
developers with a million monthly California users, but a committee gloss that contradicts
the enacted text is weak authority — and that phrasing appears to have been carried over from a
different bill that never passed. Plan against the worldwide count.
03The four duties
Each duty below is stated as the statute frames it, then as an engineer has to build it, then as
an enforcement inquiry will test it. The third framing is the one nobody writes down, and it is the
only one that decides whether you can answer.
1 · Latent disclosure
Embedded provenance, carried in the content itself
Covered content must carry a disclosure embedded in the content itself, conveying — where
technically feasible and reasonable — the provider's name, the name and version of the system
that produced it, the time and date it was created or altered, and a unique identifier. It must
be detectable by the provider's own detection tool, consistent with relevant industry standards,
and permanent or extremely difficult to remove.
Cal. Bus. & Prof. Code § 22757.3 · latent disclosure
In practice this is a watermark or a signed metadata assertion — C2PA Content Credentials is the
standard most providers are reaching for. The statute does not name a technology. It names four
data elements, a detectability requirement, and a durability requirement.
Two drafting points that matter more than they look. "Technically feasible" is part of
the duty, not a defence to it — the phrase was contributed by an industry association
during the 2024 amendments and it bounds what the duty demands, which means the burden of getting
around it sits with the enforcer rather than with you. And whether text is covered was
never settled: a committee noted that embedding disclosures in text was not feasible at
scale, warned that the phrase "other digital content" could be read to include it, and invited the
authors to clarify. They did not.
What an inquiry asks
Not "do you embed disclosures?" — everyone says yes. It asks: for this specific
artefact, on this specific date, what did you embed, and what were the four values?
Why your logs do not answer it
Application logs are mutable, rotate on a retention schedule, and are written by the same
system whose behaviour is in question. They are an assertion by the accused, produced after
the fact, with no way for a third party to detect edits.
2 · The manifest disclosure option
A visible disclosure the user can choose
A covered provider must offer the user the option of a manifest disclosure — one a person can
actually see — applied in a clear and conspicuous manner, appropriate to the medium, and
permanent or extremely difficult to remove.
Cal. Bus. & Prof. Code § 22757.3 · manifest disclosure
Note the verb. The duty is to offer, not to apply. The user decides. That makes
the compliance artefact a record of the offer being available on a channel at a time — not a record
of a visible mark existing on any particular file.
What an inquiry asks
Was the option actually presented on this surface during the period under review, or did it
silently regress in a release three months ago?
Why your logs do not answer it
A deployment record shows what shipped. It does not show what a user was offered, per
channel, per day — which is the shape of the duty.
3 · The public detection tool
Free, public, and answering
A covered provider must make available a free, publicly accessible AI detection tool that
accepts content from a user and assesses whether it was created by the provider's system. It must
accept upload or a URL, expose an API, output any available system provenance data — and it must
not output personal provenance data about the person who created the content.
Cal. Bus. & Prof. Code § 22757.2 · AI detection tool
This one is unusual: it is a duty to operate a service, continuously. Uptime is the compliance
posture. A tool that was down for six days in March is six separate days of violation, and the
penalty is calculated per day.
One relief worth knowing, because it is often read too broadly: the tool only has to identify
your own system's output. The legislative record is explicit on this — you are not
being asked to build a general-purpose detector for everyone's AI.
What an inquiry asks
On which days was the tool reachable and answering? Prove it for the whole period, not for
the day you were asked.
Why your logs do not answer it
Your uptime monitor is a vendor dashboard you can edit, with a retention window measured in
weeks. It was built to page an engineer, not to survive an adversarial reading.
4 · Revoke a licensee within 96 hours
The only duty in the Act with a clock on it
Where a covered provider licenses its system to a third party, and later discovers that the
licensee has modified the system so that it no longer applies the required disclosures, the
provider must revoke the licence within 96 hours of discovery. The licensee must
then stop using the system.
Cal. Bus. & Prof. Code § 22757.4 · licensee revocation
Correct one widespread error first: the trigger is actual knowledge. Several
secondary summaries add "or reasonably should know" — the statute does not. There is no
constructive-knowledge trigger.
Ninety-six hours from discovery. That makes the moment of discovery a legally
load-bearing fact — and it is a fact about your own knowledge, which is exactly the kind of thing
that is impossible to establish later from ordinary systems. If discovery is not timestamped when
it happens, the clock has no provable start.
What an inquiry asks
When did you find out, and when did you revoke? The gap between those two timestamps is the
entire question, and both must be independently credible.
Why your logs do not answer it
A ticket in an issue tracker has an editable creation date and an editable history. It
proves a ticket exists, not when you knew.
04Proving the negative
Here is the problem nobody's compliance page addresses. Suppose you produce four million images a
month and you seal a record for every disclosure you embed. An investigator asks the question that
actually matters: how do I know you didn't skip some?
A pile of receipts proves the acts you chose to record. It says nothing about the ones you didn't.
Evidence that only ever confirms is not evidence — it is a testimonial with extra steps.
The fix is arithmetic. Before any duty records are written, a covered provider declares the system
once: what it is in scope to produce, which marking techniques are in use, and — critically — where
in its own code a per-system counter increments. From then on, each record carries that counter's
value. Gaps in the sequence are visible to anyone reading the series. Omission stops being invisible
and becomes a number.
This does not make the counter honest. Nothing can. What it does is make the audit question
answerable in one sentence instead of an engagement: the sequence runs 1 to 4,102,887 with no
gaps, and the declaration that bound the counter was sealed before the first record. Narrowing
scope later is possible, but it is an affirmative, dated act that supersedes the prior declaration
and leaves the old one standing in the record — not a quiet retroactive edit.
05The answer the legislature wrote down
There is a paragraph in this bill's committee history that nobody cites, and it describes the
compliance architecture the statute was expected to produce.
Considering how a provider could answer the detection-tool duty at scale, the committee
observed that by keeping a record of all content their systems produce — perhaps in a
privacy-protective form, like a cryptographic hash — providers can quickly and easily
determine whether user-uploaded content was generated by their systems.
That is a hash-record compliance path, endorsed in the legislative record, and it is not in any
client alert we can find. It matters for a reason beyond flattery of our own design: an
output-side corpus of hashes is not caught by the retention limits the statute puts on the
detection tool itself. The tool is forbidden from emitting personal provenance data. A hash ledger
of what you produced is a different object, held on your side, and answers a different question.
The rest of this page is what that record looks like when it is built to survive a hostile
reading rather than merely to exist.
06Duty → receipt
This is where Planisphere enters, and not before. The California pack registers one event type per
statutory act. The field names below are not illustrative — they are the fields the API accepts,
and they were chosen to match the statute's own vocabulary.
Two properties matter more than the field list. Content never leaves your systems
— source_payload takes hash commitments, never bytes, so a record can
commit to an image without the image ever being transmitted. And each record is sealed on
write: hash-chained into a per-tenant series, signed, and periodically anchored, so a later
edit to any earlier record breaks the chain in a way a third party can detect without trusting either
of us.
07The integration
One HTTPS call per act, from wherever the act happens. This is the whole surface — there is no
agent to install, no proxy in your generation path, and nothing that can fail closed and take your
pipeline down with it.
Declare the system once, before anything else:
# One-time: what this system is in scope to produce.
curl -X POST https://api.planisphere.ooo/v1/record \
-H "Authorization: Bearer $PLANISPHERE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"pack": "ca-sb942",
"event_type": "system_declared",
"occurred_at": "2026-08-02T00:00:00Z",
"system_id": "image-gen-prod",
"sequence_binding": true,
"metadata": {
"role": "covered_provider",
"output_classes": "image,video",
"marking_techniques": "c2pa,invisible_watermark",
"counter_binding": "render_pipeline.emit_seq",
"effective_from": "2026-08-02"
}
}'
Then one call per act. Here is the disclosure record — note that only hashes cross the wire:
# Per artefact: the four statutory elements, plus the counter.
curl -X POST https://api.planisphere.ooo/v1/record \
-H "Authorization: Bearer $PLANISPHERE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"pack": "ca-sb942",
"event_type": "latent_disclosure_embedded",
"occurred_at": "2026-08-02T14:22:07Z",
"system_id": "image-gen-prod",
"system_seq": 4102887,
"source_payload": {
"content_sha256": "9f2c…", // the image. Never sent."manifest_sha256": "41ab…"
},
"metadata": {
"provider_name": "Northlight Studios, Inc.",
"system_name": "Northlight Render",
"system_version": "4.2.1",
"created_or_altered_at": "2026-08-02T14:22:06Z",
"unique_identifier": "nl-img-8830a1f4"
}
}'
At volume you do not want one HTTPS round trip per image in the render path. Batch transport
exists for exactly this, and batching changes nothing about the evidence: each item is still its own
record with its own key and its own place in the chain. The 96-hour revocation duty uses the same
call with license_revoked, where
starts_from_action_key ties the revocation to the moment of
discovery, so the elapsed time is computed from sealed records rather than asserted.
The full API reference covers authentication, idempotency and rate
limits; pricing is per record with a monthly free allowance.
08Anyone can check it, without an account
Evidence that only you can read is not evidence. Every sealed record has a public standing
endpoint — no key, no login, no relationship with us. A regulator, an opposing counsel, or a customer
can confirm that a record exists, that it has not been withdrawn, and which anchored epoch pins it:
# Public. No authentication. Try it with any action key.
curl https://api.planisphere.ooo/trust/records/<action_key>
{
"object": "trust_record",
"action_key": "…",
"exists": true,
"seal_standing": "sealed",
"anchor": { "epoch_sha256": "…" },
"disclosure": "pin_only"
}
The endpoint answers existence, standing and the anchor pin — deliberately not the contents. Your
metadata stays yours; what a third party gets is the ability to confirm that the record you are
showing them is the record that was sealed, unchanged, at the time you say it was.
09Who enforces it — and what has actually happened
Almost nothing, so far. That is worth stating plainly rather than implying a wave of
enforcement that has not arrived.
There is no agency guidance, and there cannot be regulations. Chapter 25
delegates rulemaking authority to no one. Enforcement runs through the Attorney General, city
attorneys and county counsel by civil action only — there is no agency with the power to write
implementing rules, publish an FAQ with legal weight, or run a registry. An earlier draft of SB 942
did create a registry at a state department; committee amendments struck it in May 2024. The
California Privacy Protection Agency has no role here either: its automated-decision rules govern
decisions made about people, while this chapter governs content provenance. The two do not
overlap.
There is no litigation on this statute. A docket search for the code sections
returns nothing. Expect to see one case cited as though there were: a suit filed against the
Attorney General in late 2025 by an AI developer is about California's training-data
transparency law, not this one — its complaint does not mention these sections at all. The
distinction matters for how much comfort you take from it, because compelled disclosure of
proprietary training data is a much stronger First Amendment target than a requirement to label
content with factual provenance.
Enforcement capacity was an open question during passage. The Department of
Justice told an appropriations committee it could not absorb the work without additional staff, and
noted that implementation would depend on funding. A committee analysis observed that if the
department chose not to pursue enforcement, it would likely incur no costs. Draw your own conclusion
about near-term risk — but note that the per-day penalty structure means exposure accrues
quietly during exactly the period when nobody is knocking.
One live item: a further bill amending the large-online-platform section on system provenance data
passed the Assembly unanimously in May 2026 and was moving through the Senate at the time of
writing. It does not touch the operative date.
10What Planisphere does not do
Stated plainly, because a vendor who is vague here is a vendor who will be vague in front of a
regulator. Planisphere is an evidence layer. It sits beside your systems, never inside the act.
It does not embed latent disclosures, apply watermarks, or write C2PA
manifests. Your pipeline does that.
It does not operate, host, or observe your detection tool. It records the
result of a probe you ran, as you reported it.
It does not present the manifest disclosure option to your users.
It does not revoke licences, and it cannot make a revocation happen inside 96
hours.
It does not certify compliance, issue an opinion, or make a legal
determination. No vendor can. A record is evidence a third party can check; it is not a finding
that you complied.
It does seal the acts you performed, at the moment you performed
them, in a form that a hostile reader can verify and you cannot quietly revise.
11Questions
We use a third-party model. Are we the covered provider?
Generally not — the duties fall on whoever creates, codes or produces the system, which is the
model developer rather than a business calling its API. But check your licence terms: if you have
licensed a covered system and modified it in a way that strips the disclosures, duty four makes you
the subject of a 96-hour revocation by your licensor.
Does the penalty really run per day?
Yes, and it changes what "being compliant" means operationally. The defensible question is not
are you compliant — it is on which days can you show you performed the duty. A
continuous per-day record answers a per-day penalty. A screenshot does not.
We are already doing C2PA. Isn't that enough?
C2PA addresses the latent disclosure duty well, and it is the obvious way to meet the
"consistent with industry standards" language. It does not address the detection tool, the manifest
disclosure option, or the 96-hour revocation — and a manifest travelling with a file proves what the
file claims today, not what you did on a date two years ago when the file is no longer in your
hands.
What happens to our content and our metadata?
Content is never transmitted — only hash commitments. Declared metadata values are retained
only when the pack marks the key as retainable and your organisation has enabled retention;
otherwise only the key names and a canonical hash are kept. Person-identifying keys are never
retainable.
What if we start recording after 2 August?
Then your evidence begins on the day you start, and it says so. A record cannot be
back-dated — occurred_at is your own claim, but it is committed
into the sealed payload and pinned by the anchor, so a record written in October cannot be made to
look like one written in August. Starting late is recoverable. Starting late and pretending
otherwise is not.
Does this cover the EU obligations too?
The same evidence discipline, different duties. Article 50 binds providers and deployers
differently and turns on marking and disclosure rather than detection tools and licensing, so it
has its own pack and its own event types.
The EU page walks through it.
12Sources
Every date, threshold and figure on this page traces to one of these. Where the statute is
summarised rather than quoted, the summary is ours and the citation points at the text so you can
check it.
PrimaryAssembly Privacy & Consumer Protection committee analysis, SB 942The hash-record compliance path, the own-outputs-only reading of the detection tool, the unresolved question of whether text is covered, and the amendment that struck the 12-month averaging window.
C2PA technical specificationThe provenance standard most covered providers are adopting to satisfy the latent disclosure duty.
Start the evidence trail
The console opens on the California pack with every duty listed, each one showing the exact call
that seals it. Sealing one record takes about a minute, and the first thousand each month are free.
If you would rather read first, the integration guide covers authentication, batching and the
retention controls.