Records

A record is the public entry created when you register: dated, numbered and sealed with a cryptographic hash that anyone can recompute. This page is the full reference — including the exact hash recipe.

What a record contains

These are the public fields of every record:

Field	Meaning
`registry_code`	The THB number, e.g. `THB-2026-00117`.
`slug`	The identifier in the record’s public URL: `https://platform.thehumanbehind.com/r/nova`.
`avatar_name`	The name of the registered avatar, clone, voice or agent.
`type`	`avatar` · `voice_clone` · `agent` · `image` · `other`.
`scope`	`general`, or a sensitive scope: `health`, `finance`, `legal`.
`operates_at`	Where it operates: the declared profile, site or channel.
`responsible_name`	The name of the person who answers for it.
`status`	`active`, or `unclaimed` (a record awaiting its owner — see Claims).
`verification_level`	`registered` (green seal) or `verified` (gold seal, with `verified_at`). See Verification.
`registered_at`	Date and time of registration, ISO-8601 in UTC.
`content_hash`	SHA-256 of the registration snapshot — the recipe below.

  
The responsible person’s email address is not a field of the
      record. It is never part of the hash, never shown on the public
      page and never returned by the API.
 
 The THB number
 
Every record gets an identifier in the format THB-<year>-<number>,
    e.g. THB-2026-00117: the year of registration
    plus a sequential number within that year, zero-padded to five digits. It is
    assigned atomically by the database at the moment of insertion, it is
gapless within each year and it is never
    reused — not even if the record is later de-registered.
 What can change — and what never can
   Editable by the owner: avatar_name,
type, scope, operates_at,
responsible_name.
  Immutable for everyone, including administrators: registry_code, registered_at,
content_hash and slug. Database triggers reject
      any attempt to change them, no matter who tries.
 
 
This means the hash certifies the record as it was declared on day
    one. If you later edit a field, the record keeps its original number,
    date and hash: the registry never rewrites history. De-registration is
    “soft” too — the record stops being listed, but its URL keeps answering
    with a dated notice (HTTP 410) so the trace remains.
 The content hash — exact public recipe
 
The content_hash is a SHA-256 digest computed
    by the database itself, in the same transaction that creates the record.
    Anyone can recompute it from public data. The recipe, byte by byte:
   Take the eight snapshot fields:
registry_code, slug, avatar_name,
type, scope, operates_at,
responsible_name and registered_at.
  Normalise the values: type and
scope are their lowercase identifiers (e.g.
voice_clone); if operates_at was not provided,
      use the empty string ""; registered_at is
      formatted as ISO-8601 in UTC with exactly six microsecond digits and a
      trailing Z — YYYY-MM-DDTHH:MM:SS.ssssssZ.
  Serialise as a single-line JSON object in canonical
      form: keys sorted by length first, then by byte order (this is the
      canonical text form of PostgreSQL’s jsonb). For these eight
      fields the order is therefore always: slug,
type, scope, avatar_name,
operates_at, registered_at,
registry_code, responsible_name. A colon-space
      (: ) follows each key and a comma-space (, )
      separates pairs. Encode the result as UTF-8.
  Hash it: content_hash is the lowercase
      hexadecimal SHA-256 of those bytes (64 characters).
 
 Worked example
 
For a record named Nova
(THB-2026-00117), the canonical snapshot is
    this exact single line:
 {"slug": "nova", "type": "avatar", "scope": "general", "avatar_name": "Nova", "operates_at": "https://instagram.com/nova.avatar", "registered_at": "2026-07-14T09:21:33.481205Z", "registry_code": "THB-2026-00117", "responsible_name": "Maria Lopez"}
 Verify it on any machine:
 printf '%s' '{"slug": "nova", "type": "avatar", "scope": "general", "avatar_name": "Nova", "operates_at": "https://instagram.com/nova.avatar", "registered_at": "2026-07-14T09:21:33.481205Z", "registry_code": "THB-2026-00117", "responsible_name": "Maria Lopez"}' | sha256sum
# 54a8995c2e0c1c4ab014c18d65243c6527e0f62ff456440ed74bf8473f2b10fc
 
The output matches the record’s published
content_hash. Change a single character anywhere in the
    snapshot and the hash becomes completely different — that is what makes the
    record tamper-evident.
 Verifying a record end to end
  
Fetch the record from the
public API (or read the fields off
      its public page).
 Rebuild the canonical snapshot with the recipe above.
 
Compare your SHA-256 with the published content_hash. If
      they match, the data you are looking at is exactly what was registered,
      on the date stated.
 
  Next: Directory →