Every licensed use of a real person's voice or face carries a receipt. You can check it yourself, offline, without trusting us. That is the point of publishing this page.
One command. It fetches public data, then does every signature check, hash and date comparison on your machine against a public key pinned inside the tool.
deno run --allow-net https://socialgravity.ai/docs/verify.js --license LDNAEEDY5UB
Holding a file and want to know whether it is the registered original?
deno run --allow-net --allow-read https://socialgravity.ai/docs/verify.js \
--output <output id> --file ./the-file.mp4
Needs Deno. The tool has no dependencies, sends no telemetry and needs no account or key. Source: below.
That licence is real. Both parties are real: a document-verified person who agreed to license his voice, and SocialGravity, which is licensing it for its own advertising. So it is a first-party deal rather than an arm's length one, and it was issued by an operator rather than negotiated through the request flow, which the receipt itself states. The register behind it is young, and we would rather say so here than have you find out later.
Most verification tools answer yes or no. This one has a third answer, and it is the reason to believe the other two.
| PASS | Checked, and it held. Arithmetic, not our word. |
| FAIL | Checked, and it did not hold. |
| NOT CHECKABLE | Cannot be checked from public data at all. |
"Consent exists" is an assertion by the party you are checking. The artifact behind it, a signed agreement or a recording, is not published, so no amount of arithmetic on this page can confirm it. What you can check is that a specific artifact was committed to by hash before the licence was signed, and therefore cannot have been swapped afterwards. Reporting that as a green tick would put our word inside a result that is supposed to contain only mathematics. So it comes back as NOT CHECKABLE, and a run with no failures but any unchecked line returns INCOMPLETE rather than PASS.
The same honesty applies elsewhere. Our per-licence hash chains are tamper-evident, but their inputs include fields we do not publish, so a public checker gets continuity of the published hashes rather than a full recomputation. The tool says so instead of implying more.
Five records, each hash-linked to the last. Links 1 to 3 answer "was this allowed". Links 4 and 5 answer "is this the thing that was made".
| # | Link | What it establishes |
|---|---|---|
| 1 | Person | A real, identified person authorised licensing, by signature or on camera, and we hold that artifact |
| 2 | Asset version | Exactly which voice model or face pack, at which version |
| 3 | Licence | Who licensed what, for how long, in which territory and channel |
| 4 | Generation event | A specific use happened, of that asset, under that licence |
| 5 | Content credential | This exact file, tied to that use |
Money never appears in a signed public payload, so verification never requires disclosing commercial terms. Per-output channel, territory and placement are committed to by hash and disclosed to the parties only: publishing which channel one specific ad ran in would hand competitors a media plan.
Full field-by-field definitions, including which parts are independently verifiable and which are trusted assertions, are in the receipt spec and its JSON Schema.
You do not need our tool. Two public endpoints, no auth:
curl "https://id.socialgravity.ai/functions/v1/idl-verify?id=LDNAEEDY5UB"
curl "https://id.socialgravity.ai/functions/v1/idl-verify?output=<output id>"
Each signed record carries the exact payload that was signed, the canonical bytes, the key id and
a plain-language recipe for reproducing those bytes. Ignore the self_check_passed
field: it is our own re-verification, and we are the party you are checking.
null. A record signed before a field existed
must keep verifying against the exact bytes it was signed with, so treat absent as "no claim
made" rather than as a default.Z suffix.Ed25519, key id idl-signing-v1. Resolve by the company_key_id on the
record, never by "the current key": rotations append and old records keep verifying against the key
they were signed with.
MCowBQYDK2VwAyEAXzTD6OwOCWzDk9K4zLoOeHSpGTO+b25SNUvkmqmqRE4=
A signature block also carries this key inline, as a convenience. Do not trust that copy for anything that matters: whoever can alter the response can alter the key beside it. Pin the key from this page, or from any copy of it you obtained through a different channel, and compare.
Every record is also entered into an append-only ledger, published as a Merkle tree in the Certificate Transparency style. You can fetch a signed tree head, an inclusion proof for a record you hold the id of, or every entry hash so you can recompute the root yourself.
curl "https://id.socialgravity.ai/functions/v1/idl-log-sth"
curl "https://id.socialgravity.ai/functions/v1/idl-log-sth?include=<licence id>"
curl "https://id.socialgravity.ai/functions/v1/idl-log-sth?leaves=1"
Recomputing the root from that last one is the audit that does not require us to be honest about anything. No blockchain is involved and none is needed.
What the log does not prove, stated plainly because a log is easy to over-read: a signature on a tree head proves the head came from us, not that it existed on the date it carries (only an external timestamp does that). An absent entry is not evidence against a record, since anything created before the log began is legitimately missing. Inclusion is not validity: a licence can be in the log and revoked. Full procedure in the audit document.
Published two ways, on purpose. A verifier you cannot read is a verifier you are trusting.
Its canonical-JSON implementation is deliberately a second one, independent of the code that signs our records. Sharing it would make the verifier agree with us by construction, including when both are wrong, which is the one outcome a verifier exists to rule out. The same is true of its Merkle implementation, and a test cross-checks the two for every leaf of every tree size.
Exit codes: 0 everything passed, 1 something failed, 2
nothing failed but something could not be checked, 3 the tool could not run.
The two endpoints above are the whole public surface, and they are written out on this page rather than behind a schema file. The full machine-readable specification also covers the authenticated endpoints a licensee uses, so it is shared on request rather than posted here. Ask for it if you are integrating.
Every JSON response is one envelope:
{ "ok": true, "contract_version": 1, "data": { ... } }
{ "ok": false, "contract_version": 1, "error": { "code": "...", "message": "..." } }
Said plainly, because a page like this is usually where a company starts rounding up. The
mechanism described here is built and running: the signatures, the hashes and the transparency log
are all real and all checkable by you. The register behind it is young. One licence on it covers a
real person who agreed to it, and the brand on that licence is us. The rest are internal test
records, and each one now carries a permanent mark saying so, which you will see as
demo: true if you fetch it. Those marks are append-only: marking real data as demo is
a harmless mistake, unmarking demo data as real is fraud, so only one direction exists. The test
records are left in place rather than deleted, because an append-only log you can quietly tidy is
not one worth checking. One person is publicly listed on the platform. We would rather you learn
all of that on this page than discover it.