Registry Integrity
Every model in the OMLA registry carries one of three statuses — ACTIVE, REVOKED, or DELISTED — published in its manifest and in every signed snapshot. Status describes the integrity of the registry record: whether the identity, lineage, and split you resolve against can be trusted. It says nothing about anyone's payments, because OMLA no longer tracks payment compliance — enforcing the royalty is the creators' license right, and OMLA never sees who paid whom.
/api/blacklist.json says exactly that. A model's current status lives in its signed manifest, where every payer's resolver can see it.
The status machine
How are transitions triggered?
Status changes are deliberate administrative actions through an admin-gated function — never automated triggers. The database enforces the graph below, rejects every other transition, and writes each change with its reason to the tamper-evident audit log, so the full status history of any model is reconstructible.
Status never breaks settlement. A REVOKED or DELISTED model's manifest remains resolvable — its status travels with it so payers can see it, and downstream models that name it as a parent keep paying the right people. DELISTED models are simply excluded from snapshot listings and search.
Reinstatement is a first-class transition — a wrongly revoked or delisted model returns to ACTIVE, and that change is audit-logged like any other.
What delisting means — and what it can't be used for
- Only three grounds: fraud in the registration itself (fabricated identity, lineage, or split), a binding legal order, or a DMCA takedown.
- Effect: the model disappears from snapshot listings and search. Its manifest stays resolvable, so downstream models that name it as a parent keep paying its creators correctly.
- Never for payments: missed or disputed payments cannot delist a model — OMLA has no knowledge of payments and no role in them. Underpayment is a license violation the affected creators enforce directly, and upstream creators are express third-party beneficiaries of every downstream license.
- Never silent: every transition carries a recorded reason in the tamper-evident audit log.
Complaints & appeals
What happens after I file?
A reviewer assesses the complaint against the registry record and any documentation the parties provide. Filing alone changes nothing — no status moves until a reviewer records a deliberate, audited transition.
If action is warranted, the reviewer records the transition with its reason; if not, the complaint is closed and the registry is untouched. Affected creators are contacted when possible before an adverse transition.
- Who may file: anyone. No account required.
- What to file: fraud in a registration, a legal order, or a DMCA notice — with evidence. Payment disputes are out of scope; those belong with the creator and the license's own enforcement path.
- Appeals: the affected creator can appeal any REVOKED or DELISTED status. Reinstatement to ACTIVE is a supported transition, appeals are never time-barred, and no fixed decision time is currently promised.
OMLA no longer tracks payment compliance
Earlier versions of OMLA graded each model's payment standing from periodic reporting. OMLA Direct removed the whole apparatus: there is no reporting, so there is nothing for OMLA to grade. Enforcement moved to where the knowledge is — creators, who watch their own wallets and hold the license rights.
The old feed location /api/blacklist.json now serves a permanent "n/a" marker so old integrations fail safe. Consumers must not use it — or registry status — as a payment-reputation signal.
Data & privacy
Complaint records are handled as described in our Privacy Policy (processing in the United States with appropriate transfer safeguards) and released only under lawful process. OMLA does not host model files or mediate IP ownership disputes — those go through normal legal channels. See Legal · Privacy · Terms for details.