W3C ODRL clearance API
POST /public/rights/odrl/evaluate takes a policy and an intended use and returns a deterministic verdict with its reasoning. No key, no document lookup, nothing to integrate before you try it.
Rights management
Give every system the same rights answer before use.
Encypher evaluates a W3C ODRL policy against an intended use and returns the same advisory permit, permit-with-duties, or deny result for the same inputs. Your systems decide what action to take.
Repeatable
the same inputs return the same advisory result
odrl-engine/0.2.0
deterministic, fail-closed, dependency-free
W3C ODRL 2.2
machine-readable policy input
The engine
Ask a question, get a verdict
W3C ODRL is a language for writing rights policies, and a language does not answer questions. The Encypher engine takes a policy and a concrete intended use and returns a verdict, with the rules that matched and the reason it reached them.
A rights answer that changes between two identical questions is worth nothing to whoever relies on it. So the engine is built to be boring: same policy, same question, same verdict, and every path it cannot resolve with certainty resolves to no.
- Deterministic
- The same policy and the same intended use return the same verdict every time. Each response carries the engine version, odrl-engine/0.2.0, plus SHA-256 hashes of the policy and the request, so a decision taken months ago can be reproduced exactly.
- Fail-closed
- Ambiguous, malformed, unsupported, or over-limit input denies rather than grants. An incomparable constraint, an unknown operator, a non-scalar operand, a policy nested past the safety budget: each one resolves to no, never to yes.
- Prohibition wins
- When a permission and a prohibition both match the same action, the prohibition takes the decision. A policy that names an unrecognized conflict strategy also resolves to prohibit.
- Defaults to deny
- No matching rule means no signal, and no signal means no. A caller can ask for a permissive default explicitly, but a structurally malformed policy never grants even then.
- Dependency-free
- Pure evaluation. No network call, no document lookup, no third-party rules library. The same code path runs inside Encypher verification and inside your own stack.
Where it runs
POST/public/rights/odrl/evaluate
Public evaluation, no key required
Send any W3C ODRL policy plus an intended action and constraint context. Pure evaluation: no document lookup, no account, rate limited per IP. Point it at your own policies before you integrate anything.
GET/public/rights/{document_id}/odrl
A policy per document, bound at signing
Every signed document gets its own W3C ODRL policy, resolved when the document is signed from your profile plus any document-level override. The C2PA 2.4 manifest, the rights snapshot, and the policy all resolve under the same document id.
POST/verify/advanced?intended_use=
Clearance on verification
Authenticated verification can carry an intended use: ai_training, ai_inference, data_mining, scraping, or rag_retrieval. Encypher projects the publisher policy to ODRL, runs the same engine server-side, and returns the clearance next to the verification result.
The verdict
Five decisions, one usable answer
The engine is explicit about why it decided what it decided. Every response names the matched rules, the reason, and any duties attached to a permission.
- permittedUsable: Yes
A permission matched the action and every constraint on it held.
- permitted_with_dutiesUsable: Yes
A permission matched and carries obligations, such as attribution or payment. The duties come back named.
- prohibitedUsable: No
A prohibition matched the action, or a permission and a prohibition collided and the prohibition won.
- no_matching_ruleUsable: No, by default
Nothing in the policy speaks to this action. Absent an explicit permissive default, the engine denies.
- invalidUsable: No
The policy could not be evaluated safely, or the policy itself asked for a permission/prohibition collision to be reported as invalid.
Permit, prohibit, license-required. Verify a document with an intended use and the five decisions collapse to one clearance answer: permit or prohibit. License-required is not an ODRL decision. It is a pricing outcome layered on a permit: the policy allows the use and the publisher expects payment for it, so the response carries the pricing terms and the licensing contact alongside the permit.
The verdict is advisory. Encypher reports what a policy says about a use. It does not sit inside a retrieval or training path, and it never grants permission on behalf of a publisher. The answer is deterministic and machine-readable precisely so your own systems, and the systems on the other side of the deal, can act on it.
Verified clearance
A policy verdict becomes a durable answer
The authenticated clearance path keeps provenance, the ODRL decision, license acquisition, and the Encypher verification receipt separate. A single cleared label never hides which fact changed.
- 1
Inventory
Every successful production sign becomes one durable inventory generation before the API or background job reports success. Current and historical generations keep their provenance, status, and immutable rights evidence distinct.
- 2
Decision
A clearance check resolves one signed generation and one intended use through the same fail-closed ODRL engine. Provenance and the policy decision remain separate facts.
- 3
Acquisition
If the policy permits the use only with license duties, Encypher checks for an exact, effective agreement accepted by both parties. A merely compatible or pending deal does not clear.
- 4
Receipt
When verification is required, Encypher rechecks provenance, rights, agreement, status, and trust before issuing a signed, timestamped clearance receipt. Public verification accepts caller-supplied receipt bytes; receipt ids are not enumerable.
Production buyers call
POST /api/v1/rights-clearance/check with public signed evidence and one intended use. Publishers can preview their own inventory without issuing a receipt. A prohibited result never offers a license action, and a license-required result remains uncleared until the exact agreement is effective.The tiers
Three tiers, three use cases
Bronze, Silver, and Gold are what the ODRL policy encodes. Set them once and every signed document projects the same permissions, prohibitions, and duties, aligned to how AI companies actually use content.
Bronze
Crawling and scraping
Controls broad read-only access: search indexing, price comparisons, web archiving, and general AI data collection.
- Web crawlers (Googlebot, GPTBot)
- Training data collection
- RSS / feed aggregation
- robots.txt-aligned signals
Silver
RAG and retrieval
Controls AI-powered search and retrieval-augmented generation pipelines: the largest current use case.
- RAG grounding data
- Real-time AI search
- Perplexity, SearchGPT, Bing AI
- Enterprise AI assistants
Highest value
Gold
Training and fine-tuning
Controls use of your content for AI model training and fine-tuning, the highest-value licensing category.
- LLM pre-training datasets
- Fine-tuning and RLHF
- Model evaluation benchmarks
- Synthetic data generation
How it works
From first signed document to a policy machines can evaluate
Five steps from your first signed document to a W3C ODRL policy any AI company can resolve, evaluate, and cite.
- 1
Sign
Publish content with Encypher. Every document gets a C2PA 2.4-compliant signature with your rights_resolution_url embedded in the manifest.
- 2
Publish your profile
Set your Bronze / Silver / Gold terms once. They apply to all signed content automatically.
- 3
Encypher projects the policy
At signing time your terms become a W3C ODRL 2.2 policy for that specific document, published at a stable URL and reachable from the manifest. RSL 1.0 XML is available from the same registry for tools that expect it.
- 4
The engine returns a verdict
An AI company sends the policy and its intended use to the ODRL engine and gets back a deterministic, machine-readable verdict, with the matched rules, the reason, and any duties attached.
- 5
Record the supplied policy and result
A clearance receipt keeps the supplied terms, intended use, matched rules, and advisory answer distinct for later review.
Compatibility
RSL 1.0 compatible
RSL is a way to publish terms, and publishing terms is the easy half. Encypher speaks it so your terms land wherever RSL-aware tools look, and leaves the deciding to ODRL.
What Encypher supports
- RSL 1.0 XML at /public/rights/organization/{id}/rsl
- Import an existing RSL document as your rights profile
- robots.txt additions and rights-discovery meta tags
- Advisory OLP token handshake for crawlers that ask for one
Where the compatibility ends
- No RSL evaluation engine: every decision runs on W3C ODRL
- No RSL schema validation, on emit or on import
- An OLP token is an advisory handshake, never a permission grant
That is the honest ceiling, and it is deliberate. Two formats to publish in, one engine to decide with.
Evidence boundary
A durable record of the terms and the answer
A signed document can carry the publisher's supplied rights policy. A clearance receipt can record the intended use, the policy version, the matched rules, and the engine's advisory result.
That record shows what terms were supplied and what the engine returned. It does not establish ownership, authorization, infringement, willfulness, or damages. Counsel and the systems using the result make those decisions.
- Signed content record and supplied policy version
- Intended use submitted for evaluation
- Matched rules, duties, and advisory result
- Timestamped clearance receipt for review
Formal notice workflow
Coming soon
Planned tooling to assemble supplied terms and publication records for counsel review.
Evidence export
Coming soon
Planned export of the signed record, supplied policy, clearance input, and advisory result.
Pricing
Simple, transparent pricing
Free signing infrastructure. Enforcement tools are priced through a sales conversation.
| Feature | Price |
|---|---|
| Document signing (C2PA 2.4) | Free (unlimited, fair use) |
| Rights profile (Bronze / Silver / Gold) | Free |
| Public rights resolution URL | Free |
| Coalition enrollment (opt-in) & content indexing | Free |
| Attribution Analytics dashboard | Contact sales |
| Formal Notice Package | Coming soon |
| Evidence Package | Coming soon |
| Rights and Evidence Bundle (analytics, notices, evidence) | Coming soon |
Revenue model: You keep 100% of your licensing revenue; AI companies pay Encypher a separate verification fee. Coalition membership is opt-in via a separate agreement, and Encypher-brokered coalition deals share a portion with Encypher, with exact terms in your coalition agreement. Learn about the Coalition.
For AI companies
Build the rights path once
Resolve one policy format, call one evaluation endpoint, and get a verdict you can log. That covers every Encypher-signed publisher, so you build the provenance and rights path once.
A policy per document
GET /public/rights/{document_id}/odrl returns the W3C ODRL policy bound to that document at signing. Resolve it from the manifest, evaluate it, log the verdict.
Quote Integrity API
Verify AI attribution accuracy before publishing. Prove whether a cited quote is accurate, approximate, or hallucinated.
Coalition licensing
Single agreement covers all coalition publishers. Structured licensing at scale, not 1:1 negotiations.
FAQ
Frequently asked questions
Common questions from publishers evaluating rights management for their content.
Ready to take control?
Set up your rights profile in minutes. Free to start. Enforcement tools available when you need them.