Compliance

Transitions fire in two places:

• Weekly cron — the compliance-tick Edge Function calls tick_compliance(), which advances every model based on its recent reports and payments.
• Event triggers — inserting a complaint row moves the target model to UNDER_REVIEW immediately (not waiting for the weekly cron).

Transitions are deterministic and idempotent: running the tick twice in a row produces the same result. You can see every historical transition in the audit_log table.

Reverse transitions happen too: a DELINQUENT model that pays up lands back in COMPLIANT on the next tick. UNDER_REVIEW rolls back to the previous state when the complaint resolves.

While a complaint is open:

• The disputed wallet's share of incoming royalties is held — not paid out and not lost.
• Flow-through to other recipients continues normally. A complaint about one creator doesn't punish the rest.
• The model's public registry page shows the UNDER_REVIEW badge so downstream users can see something is contested.

Outcomes:

• Resolved in holder's favour — accumulated balance pays out on the next quarterly cycle.
• Resolved against holder — wallet deactivated; balance either refunded to the commercial user, redistributed per board decision, or held pending legal process.

Every quarterly blacklist JSON is signed with OMLA's association-level Ed25519 key. The signature is a separate field inside the same document.

To verify, a consumer fetches /api/blacklist.json, removes the signature field, and verifies against the OMLA public key shipped in config.js as omlaSigningPublicKey.

Current state: the published JSON ships a literal UNSIGNED_PLACEHOLDER signature until the association signing key is generated and published. Do not enforce against it yet.