What's next

OMLA Implementation Roadmap

Every gap we know about, rebuilt around OMLA Direct — the 2026-07 redesign that made OMLA a pure information registry with recursive direct settlement. Each item has a status, a priority, a design sketch, and a rough complexity estimate. Things already built are at the top for context; open work is below. The full behavioural spec this roadmap is closing against lives on the Technical Details page.

Legend: Built code complete, verified, staged · In Progress partially built · Planned designed, not built · Proposed open design question.
Priorities (as of July 2026): P0 blocks the end of public beta · P1 within 30 days · P2 within 90 days · P3 nice to have.

Built · the OMLA Direct stack

Code complete and verified end-to-end on the local stack; goes live with the next site deploy. Details in the technical docs.

Built Registry v2 — signed manifests

Every model publishes a creator-signed manifest: identity, lineage, a royalty split with retention caps (fine-tune ≤ 5%, quantize ≤ 2%, distill/merge ≤ 10%), payee wallets, and public payment pointers. The v5 registration message signs the manifest hash; split invariants are enforced in the wizard, the Edge Function, and deferred database triggers. /registry.html

Built Signed snapshot tree

The whole registry as static, ed25519-signed JSON under /registry/v2/: a signed index with a strictly increasing seq and a root hash over every manifest, per-model manifests and pre-flattened payee vectors, a bulk snapshot.jsonl.gz, and an append-only changelog. Mirror-friendly by design.

Built The resolver — omla-resolve/2.0

The open, deterministic algorithm that turns a payer's own usage ledger into a percentage (and cents) per wallet. Fixed-point integer math, largest-remainder rounding, dust floor, depth cap, cycle defense. Python package + CLI and a browser/node JS build, driven by the same test vectors with byte-identical output.

Built Registration wizard v5 + signed manifest updates

Six-step browser flow: identity, keypair, lineage, payees & pointers with live rail validation, a split editor with live cap clamping and a flattened "$100 through this model" preview, and v5 signing. Post-registration changes go through the update-manifest function — every economic mutation requires a fresh signature from the model's registered key. /register.html

Built Public manifest pages + in-browser resolve demo

Every model page shows the full public manifest — lineage links, split table, payees with copyable pointers, manifest version and hash — plus a live "Resolve $100" demo running the real resolver in the browser. /registry.html

Built License v2.0 (Direct Settlement) + registry integrity

The rewritten Model License: 30% greater-of self-assessed, recursive split with retention caps, safe harbor for ≤90-day-old snapshots, $0.10 dust floor, keep-your-own-records, creator enforcement with upstream creators as third-party beneficiaries. Registry-integrity states (ACTIVE / REVOKED / DELISTED) replace the old payment-tracking machinery entirely. /license.html

P0 — Blocking the end of public beta

Items the site cannot responsibly leave public beta without.

Planned Outside counsel review

Priority P0 · Complexity M · Owner: board

License v2.0, the Terms, and the Privacy Policy are operative but have not been reviewed by outside counsel. This is the single gate the beta banner is honest about, and it stays a P0 until a lawyer has signed off on the direct-settlement framing, the retention caps, the safe harbor, and the third-party-beneficiary enforcement clause.

Design: engage Washington counsel with AI/IP licensing experience; review package = license.html v2.0, terms.html, privacy.html, and the resolver SPEC the license incorporates by reference. Any wording change re-pins the license digest, so review lands as one atomic site update.

Planned Opening public signups

Priority P0 · Complexity S · Owner: board + operator

Creator registration is gated during beta. Opening it is a launch decision that follows counsel review and the sybil protections below — the machinery itself is already built.

Design: flip Supabase signups on, enable Turnstile + rate limits (see sybil item), announce, and watch the first cohort's manifests closely with the existing audit tooling.

Built G2 — Signed mutations (closed by OMLA Direct)

Priority — · was P0

The long-standing "a compromised email = full control" gap is closed: every economic mutation — split, payees, pointers — now requires a signed manifest-update message verified against the model's registered key(s), not just an authenticated session. Kept here because older audits reference G2.

P1 — Within 30 days

High-impact items that make the system usable at scale.

Planned Snapshot mirrors

Priority P1 · Complexity S

The snapshot tree is served from one origin today. Browser verification checks a client-pinned key, immutable sequence links, domain-separated Merkle proofs, and creator evidence, but the browser pin ships from that same origin. Whole-site-compromise resistance still needs independent mirrors or witnesses plus an offline or threshold key-rotation process.

Design: publish registry/v2/ to at least one independent host per snapshot run; document the mirror list on the docs page; consumers already verify signatures, so mirrors need zero trust. Content-addressed distribution is a possible later step, deliberately not committed to yet.

Planned G3 — Key rotation / recovery

Priority P1 · Complexity L

Lost secret key = loss of the ability to sign a manifest update. Today: contact the board for a reviewed, off-system recovery or re-registration process.

Design: a second "recovery" Ed25519 pubkey registered optionally at creation. Either key signs manifest updates. A timelocked rotation record allows a 7-day challenge window; at end of window, rotation completes unless challenged. Lost-both recovery stays an off-system legal process.

Proposed G9 — Integration SDKs

Priority P1 · Complexity S

The resolver is already a library and a CLI. What's missing is the ten-line convenience wrapper: fetch snapshot, verify signature, resolve ledger, emit payment list.

Design: omla-sdk-js and omla-sdk-python, thin wrappers over the published resolver plus snapshot verification. Amount-bearing calls require an exact quarter: await omla.settle({ledger, total, period: "2026-Q3"}). Published to npm + PyPI.

Proposed G10 — Hugging Face / Civitai sidecar

Priority P1 · Complexity S

A JSON sidecar that model hubs can host alongside weights. When someone views your model on a hub, an OMLA badge shows identity, registry status, and a link to the manifest.

Design: standard omla.json file format with model_id + key fingerprint + manifest URL. Client-side JS snippet that hub UIs can include; it fetches the manifest, checks the registry status, and renders a badge with the split summary.

P2 — Within 90 days

Operational polish and trust features.

Proposed Proof of pointer control

Priority P2 · Complexity M

OMLA validates that a payment pointer is well-formed, not that the registrant controls it. The signed manifest limits the damage — only the keyholder can publish pointers — but a stolen key or a typo could still misdirect royalties.

Design: per-rail challenge-response at verification time: sign a nonce (crypto rails), serve a token at the URL (stripe-link / paypal-me / invoice-url), reply to a probe invoice (lightning). Recorded as a verification flag on the pointer, never as custody. Explicitly documented as future work in License v2.0.

Proposed G8 — Sybil / bot prevention

Priority P2 · Complexity S

Anyone with a free email can register unlimited models and pollute the registry once signups open.

Design: Cloudflare Turnstile challenge on /register.html + per-IP rate limit (3 registrations / day) at the edge. Legitimate creators stay well under the cap.

Proposed G12 — Public transparency dashboard

Priority P2 · Complexity S

Trust grows with transparency. Publish aggregate registry numbers — and only registry numbers, because OMLA has nothing else to publish.

Design: /stats.html reads a materialized view refreshed hourly: total models by registry status, lineage depth distribution, pointer-rail mix, snapshot cadence, integrity actions with reasons. No payment or usage figures exist to show — that's the design working, and the page should say so.

Planned Automated complaint intake and notification

Priority P2 · Complexity S

Today the complaint form downloads a record for manual email review. There is no automated intake queue or fixed response-time promise.

Design: an authenticated complaint table and review queue first, then an idempotent notification worker with documented service levels, audit events, and delivery monitoring.

P3 — Nice to have

Proposed Waiver mechanics

Priority P3 · Complexity M

An upstream creator might want to waive their share for a specific derivative — a teaching model, a charity project. License v2.0 reserves the mechanism; nothing implements it yet, deliberately.

Design: a creator-signed waiver record referencing a specific lineage edge, surfaced in the manifest so the resolver can honor it. Needs license text first; a future License version, applied prospectively.

Proposed G15 — Asset kinds beyond models

Priority P3 · Complexity L

Datasets, likenesses, art styles — the same manifest, split, and settlement machinery would carry them.

Design: migration adds asset_kind ENUM('model','dataset','likeness','artwork') defaulting to 'model'. Per-kind retention-cap tables. Registry page grows a type filter. License text gets kind-specific §3 addenda.

Proposed Community forum

Priority P3 · Complexity S

Creator + commercial-user feedback loop.

Design: GitHub Discussions (free, already paid for), linked from the site footer. No forum software to run.
Want to help? Pick any item above, send a note to hello@omla-ai.org, and we'll talk. No gatekeeping, no "first, tell us why you'd be a good fit" — if you want to build the snapshot mirrors, they're yours. We'll happily name the whole item after you in the commit log.