audit · evidence · verifiability
Every classification DutyRadar makes for your account is recorded, retrievable, and cryptographically signed. The signed export is independently verifiable: anyone with the published public key can confirm the bytes haven't been tampered with, without making a single API call to DutyRadar.
GET /v1/audit/export?since=&until= returns a signed JSON payload covering up to a 90-day window. The body includes every classification event for the calling key in that window: timestamp, request ID, hashed UA, hashed source IP, the verdict, and the verification method that produced it.
The payload is signed with an Ed25519 private key DutyRadar holds. The corresponding public key is published at /.well-known/audit-pubkey.json in JWKS format (RFC 7517). The export carries a public_key_jwk with a matching kid so a third party can fetch the canonical key over TLS, verify the fingerprint matches the inline key, and then verify the signature against the canonical JSON of the events.
How to actually run the verification, with code samples in openssl, Python, and Node: /docs/audit/verify.
Audit-export signing key (Ed25519, EdDSA, kid: dr-audit-1):
SHA-256: fa:5e:14:c9:f4:b6:20:ff:9b:cd:9a:c8:f4:73:e9:4c… JWKS: https://dutyradar.com/.well-known/audit-pubkey.json Curve: Ed25519 x (b64u): 594zoEHWFhuiuJVIDFpSJO7m…
Cross-check this fingerprint against the value at /.well-known/audit-pubkey.json over TLS. If both match, you have an authenticated public key.
The canonical key lives at
/.well-known/audit-pubkey.json.
Verify the fingerprint above matches the
x field of the JWK served there before trusting any
export.
The audit-export signing key is held only by the deployed DutyRadar Worker (Cloudflare-encrypted Wrangler secret). Rotation policy:
· Routine rotation: at most every 12 months. The new key (kid: dr-audit-N+1) is published in /.well-known/audit-pubkey.json at least 30 days before it begins signing exports; the previous key (kid: dr-audit-N) stays in the JWKS for 180 days after the last export it signed, so any historical export remains verifiable.
· Emergency rotation: if the signing key is suspected compromised, a new key is generated and deployed within hours. The compromised key is removed from the JWKS immediately, with a public notice on this page indicating the suspected compromise window. Exports signed during the suspect window are republished with the new key on customer request.
· Historical verification: the JWKS endpoint always serves all keys that signed any export the customer's data-retention window covers. A customer with an export from 2 years ago should still find its kid in the published JWKS.
No rotations have occurred yet. Current key: dr-audit-1.
Providers of general-purpose AI models shall implement a policy to identify and comply with reservations of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790, including through state-of-the-art technologies. (Article 53(1)(c), Regulation (EU) 2024/1689 — applicable to GPAI providers from 2 August 2025.)
The Article 4(3) reservation referenced above is the EU's training-data opt-out mechanism. It places the obligation on AI providers, but it creates a downstream evidentiary question for publishers: can you prove a particular AI vendor accessed your content despite your opt-out, on a particular date?
DutyRadar's signed export records the vendor, the verification method, and the timestamp of every classification. Whether the export satisfies your specific evidentiary needs is a question for your counsel.
A developer of a generative artificial intelligence model that is made publicly available to Californians shall post on its internet website documentation regarding the data used by the developer to train the generative artificial intelligence model. (California Civil Code § 3110(a), operative 1 January 2026.)
The disclosure obligation is on the model developer, not the publisher. But disputes about whether a developer correctly disclosed crawled content tend to come back to the question of which crawler accessed which page when. That's a question DutyRadar answers per request, with a signed record.
The exception or limitation provided for in paragraph 1 shall apply on condition that the use of works and other subject matter referred to in that paragraph has not been expressly reserved by their rightholders in an appropriate manner, such as machine-readable means in the case of content made publicly available online. (Directive (EU) 2019/790, Article 4(3).)
"Machine-readable means" is the regulatory anchor for the entire opt-out ecosystem (robots.txt tokens, ai.txt, header signals, etc.). When a dispute over a TDM opt-out reaches a court, the question becomes who accessed the content, when, and through which verification path. The OLG Hamburg LAION ruling (Case No. 5 U 28/23, decided September 2024) brought that evidentiary question into sharp focus for European publishers.
DutyRadar records the access. Your robots.txt and your TDM opt-out signals are still your responsibility. The signed export gives your counsel a tamper-resistant record to point at.
DutyRadar is a verification and evidence-preservation tool. It is not legal advice and does not establish that any particular regulatory regime is satisfied by its use. Whether the artifact described above meets the evidentiary standard your regulator or counterparty would accept is a determination for your counsel, made in light of the specific facts of your operation and the law of the jurisdiction in question.