Bind what your AIpromised. Provewhat it did.
Ileri records what an AI system was promised to do, gathers the evidence that it held, and writes the proof back into your own catalog. When the system cannot prove something, it refuses to guess.
- 45governance modulesevery name printed below
- 49governance API domainsof 60 route groups
- 5frameworks mapped in codemapping, not certification
- 3lakehouse write pathstags, Delta, inference tables
Governance fails at the evidence, not at the intent.
Nobody sets out to run an ungoverned model. The failure happens later, when someone asks for proof and the only thing anyone can produce is a recollection.
Access control is not trust.
Knowing who may touch a model says nothing about whether that model is accurate, fair, safe, or lawful in the use it was approved for. Permission and trustworthiness are different questions, and only one of them is usually answered.
A questionnaire is not evidence.
An assessment that starts from a blank form is a memory exercise. By the time it is filled in, the model has been retrained, the prompt has moved, and the answers describe a system that no longer exists.
A screenshot is not proof.
Evidence that lives in a slide cannot be verified, cannot be re-run, and does not survive the person who assembled it. Proof has to be a record, held somewhere the auditor already trusts.
README.mdUnity Catalog governs whether you can access an AI asset; Ileri governs whether that AI is trustworthy, fair, safe, and compliant, and writes the proof back into your own catalog.
Lakehouse-native, not a bolt-on.
The governance record is written into the catalog you already run, in the formats you already query. There is no second system of record to reconcile.
Fail closed.
When the system is uncertain it denies rather than guesses, and it shows an empty state rather than a plausible one. Nothing on this page is generated, and nothing in the product is either.
Eight groupings. Forty five surfaces.
The product is not one screen. Grouped by the question each surface answers, here is what governance covers, with the real module names attached to each group.
- I
Promise ledger and trust
The record itself: what was promised, what attests to it, and the score that summarises whether it still holds.
- promise-ledger
- trust-score
- model-cards
- governance
- audit
- II
Model risk and evaluation
The surfaces that test a model against its stated behaviour rather than against its documentation.
- llm-evaluation
- benchmarks
- model-comparison
- explainability
- hallucination
- III
Security and adversarial
The surfaces concerned with what an AI system does under pressure, and with the AI you did not approve.
- redteam
- security
- content-safety
- gateway
- shadow-ai
- IV
Supply chain and provenance
What the system is made of, where each part came from, and who is accountable for it.
- ai-bom
- supply-chain
- vendor-risk
- data-provenance
- data-quality
- assets
- V
Compliance and evidence
The artifacts an assessment consumes, produced as a by-product of operating rather than assembled before a deadline.
- compliance
- policies
- impact-assessments
- auto-evidence
- reports
- consent
- VI
Operations
The running concerns: what is happening now, what broke, what it costs, and who gets told.
- monitoring
- incidents
- cost
- workflows
- notifications
- webhooks
- integrations
- VII
Multi-modal and RAG
Governance for systems that are not a single model: retrieval, prompts, agents, and content that crosses modalities.
- multimodal
- cross-modal-risk
- rag-governance
- prompt-management
- agents
- VIII
Platform and roles
The surfaces that make the rest usable by more than one person: audiences, workspaces, and the developer path in.
- executive
- custom-dashboards
- developer
- teams
- academy
- settings
45 modules. Every name printed.
A module count is a breadth claim, not a quality claim and not an adoption claim. So here is the whole list, grouped, with nothing hidden behind an ellipsis. Filter by pillar to see how the surface divides.
All 45 modules, alphabetical
- academy
- agents
- ai-bom
- assets
- audit
- auto-evidence
- benchmarks
- compliance
- consent
- content-safety
- cost
- cross-modal-risk
- custom-dashboards
- data-provenance
- data-quality
- developer
- executive
- explainability
- gateway
- governance
- hallucination
- impact-assessments
- incidents
- integrations
- llm-evaluation
- model-cards
- model-comparison
- monitoring
- multimodal
- notifications
- policies
- promise-ledger
- prompt-management
- rag-governance
- redteam
- reports
- security
- settings
- shadow-ai
- supply-chain
- teams
- trust-score
- vendor-risk
- webhooks
- workflows
The proof lands in your catalog, not ours.
Three real code paths carry governance output into Databricks. This is what lakehouse-native means in practice, and it is the difference between a connector and a native surface.
Unity Catalog tag write-back
Governance outcomes are written as catalog tags on the asset itself, so the trust posture travels with the asset for anyone already querying the catalog.
Tags written- ileri_trust_score
- ileri_risk_band
- ileri_eu_ai_act
Delta export
Evidence is exported through the SQL Statement Execution API using an idempotent MERGE, so a re-run reconciles rather than duplicates.
Mechanism- SQL Statement Execution API
- idempotent MERGE
Model Serving inference tables
Ileri reads Model Serving inference tables directly, so evaluation runs against the traffic the endpoint actually served.
Source- inference table reads
Promise, evidence, proof.
A promise on its own is a sentence. What makes it governance is that the sentence is bound to an artifact, and that the binding can be checked later by someone who was not there.
- 01
Promise
A stated commitment about an AI system: what it is for, how it should behave, which policy and framework controls apply to it, and who owns the answer when it does not.
Fields- subject
- commitment
- owner
- policy
- framework control
- 02
Evidence
The artifacts that speak to the promise: evaluation output, red team results, monitoring signal, provenance and supply chain records, approvals. Produced by operating the system, not by preparing for an audit.
Fields- artifact
- source module
- observed at
- result
- 03
Proof
The evidence is appended to a tamper-evident ledger, and the ledger can be verified independently. Governance output is then written into your own catalog, where the auditor already looks.
Fields- ledger entry
- verification
- catalog write-back
- export
The binding. Six promises cross the weave and knot as they are recorded. One frays and snaps.
- KeptEvidence supports the promise.
- At riskSignal is moving against the promise.
- BrokenEvidence contradicts the promise.
- PendingNo evidence yet. Never a guess.
These four are real product statuses, defined in the design tokens and carried through the product surfaces.
The Python SDK surface exposes verify_ledger(), so the record can be checked from outside the application that wrote it. A ledger you can only verify with the tool that produced it is not evidence.
verify_ledger()This is the structure of a record, not a record. No sample data is shown anywhere on this page, because the product does not show sample data either.
What is actually in the code.
Security sections usually list aspirations. This one lists dependencies, algorithms, and file paths, and then lists what is missing.
Identity
WorkOS AuthKit is a real dependency of the web application. Supabase and Auth0 provider paths exist in the environment configuration. SSO is offered on the Enterprise tier.
- @workos-inc/authkit-nextjs
- Supabase provider path
- Auth0 provider path
Secrets
Integration secrets are encrypted at rest with AES-256-GCM, so a credential handed to Ileri to reach your systems is not stored in a readable form.
- AES-256-GCM at rest
Audit
The Promise Ledger is tamper-evident, and verification is exposed on the SDK surface rather than kept inside the application that writes the record.
- tamper-evident ledger
- verify_ledger()
Observability
Prometheus and monitoring configuration ships in the repository under infrastructure/monitoring, alongside the backup, logging, security, and Kubernetes material.
- infrastructure/monitoring
Two layers, and an honest line around the second.
Every query is organization-scoped in application code. On the core governance path that scoping is backed by Postgres row-level security, so a service that forgot its organization filter still could not read another tenant’s rows.
- Layer 1Every service
Application scoping
Every query is organization-scoped. The canonical org_id is carried as a string across services, so every record belongs to an organization.
- org-scoped data model
- canonical org_id
- Layer 2Core governance path
Database row-level security
Postgres row-level security with FORCE ROW LEVEL SECURITY across nine governance tables. A dedicated connection is pinned per request and the app.current_org_id session GUC is set on it, so the policy is evaluated by the database instead of trusted from the caller.
- FORCE ROW LEVEL SECURITY
- 9 governance tables
- app.current_org_id GUC
- pinned per request
- Promise Ledger
- Trust Score
- audit
- compliance evidence
- cross-modal risk
- migrations 009 and 020
- api/internal/api/middleware/rls.go
- api/internal/api/handlers/routes.go
- api/tests/integration/rls_test.go
Row-level security applies to services that query through the RLS-pinned connection seam, which today is the governance core named above and not every service. The middleware is also fail-safe rather than fail-hard: with no database, no organization context, or a failed connection checkout, the request continues on application-level scoping alone. That makes the database layer a backstop, and calling it anything more would be the kind of claim this page exists to avoid.
A certification is an audit outcome, not a code path. Ileri has controls in code and does not have attestations, so this is the honest list. If a vendor page cannot tell you this much, ask why.
- Not SOC 2 certified, not ISO 27001 certified, not FedRAMP authorized.
- No published penetration test results.
- No uptime, availability, or SLA figure.
- No customer names, logos, testimonials, or adoption counts.
- No latency or throughput number, because none has been measured for publication.
Five frameworks, mapped in code.
Control mapping means Ileri connects its own controls and evidence artifacts to the clauses of a framework, so an assessment starts from populated evidence instead of a blank questionnaire.
| Framework | References in code | Status |
|---|---|---|
| EU AI Act | 84 | Mapped |
| GDPR | 46 | Mapped |
| ISO 42001 | 40 | Mapped |
| HIPAA | 27 | Mapped |
| NIST AI RMF | 24 | Mapped |
CCPA and SOC 2 also appear in the codebase, more thinly. They are listed here rather than promoted, because the mapping is not at the same depth.
What mapping does
- Connects Ileri controls and evidence artifacts to named framework clauses.
- Starts an assessment from evidence that already exists rather than an empty form.
- Keeps the trail attached to the asset, so the answer can be re-derived later.
What mapping does not do
- It does not certify you. Certification is an audit outcome and Ileri is not an auditor.
- It does not guarantee a framework outcome, and it is not a legal opinion.
- It does not remove the obligation to have counsel review how a framework applies to your deployment.
Run it where your data already lives.
Every target below has manifests in the repository. Governance software that cannot run inside the customer boundary is a data export problem wearing a compliance costume.
- 01
Docker Compose
Local and single-host deploymentFour compose files cover local development through single-host production, including the Dokploy prebuilt path.
- docker-compose.yml
- docker-compose.local.yml
- docker-compose.dokploy.yml
- docker-compose.dokploy-prebuilt.yml
- 02
Kubernetes and Helm
Charts for both servicesThe API and web services each ship a Helm chart, with supporting Kubernetes material in the infrastructure tree.
- api/helm/ileri-api/Chart.yaml
- web/helm/ileri-web/Chart.yaml
- infrastructure/kubernetes
- 03
Databricks App
Runs inside the customer's own workspaceIleri is packaged as a Databricks App, so it can run in the workspace where the governed assets already are.
- databricks-app/databricks.yml
- databricks-app/build.sh
- 04
Databricks Lakebase
Transactional state on Databricks managed PostgresSelecting the Lakebase provider puts transactional state on Databricks managed Postgres, authenticated with rotating OAuth machine-to-machine tokens.
- DB_PROVIDER=lakebase
- rotating OAuth M2M tokens
- 05
Self-host
Source-visible manifestsBackup, monitoring, logging, security, and Kubernetes material all live in the open under the infrastructure tree, so a platform team can read the operational shape before committing.
- infrastructure/backup
- infrastructure/monitoring
- infrastructure/logging
- infrastructure/security
The surface you build against.
Governance that only exists inside a console becomes a second job. The API is the product as much as the interface is.
REST API
AvailableSixty route groups under /api/v1, of which 49 are governance domains and the remainder are platform concerns such as authentication, users, and health. Documented in-repo.
- 60 route groups
- 49 governance domains
- /api/v1
Webhooks
AvailableWebhooks exist as both a product module and an API group, so governance events can drive systems that are not Ileri.
- webhooks module
- webhooks API group
Python SDK
Source install onlyThe SDK lives in the repository at sdk/python and exposes trust_score() and verify_ledger(). It is not published to a package index today, so it installs from source. A release workflow exists and has not been run to publication.
- sdk/python
- trust_score()
- verify_ledger()
- installs from source today
Catalog export
AvailableGovernance artifacts leave the system in formats you keep: catalog tags on the asset, Delta tables in your workspace, and generated reports.
- Unity Catalog tags
- Delta export
- reports
Python is the only SDK in the repository. There is no JavaScript, Go, or Java client, and claiming otherwise would be the first broken promise.
Honest about what you can buy today.
Starter is in the product now and you can reach it by signing up. Paid plans are not self-checkout, and pretending otherwise would waste a procurement cycle.
Starter
Included for self-serve evaluation
For a single organization proving the governance workflow against real assets.
- Private organization on signup
- Model registry and trust score
- Promise ledger
- Databricks connection path
Growth
Quoted after fit review
For teams operationalizing governance across products, policies, and evidence workflows.
- Multiple teams and workflows
- Governance exports
- Advanced monitoring surfaces
- Implementation support
Enterprise
Contracted annually
For regulated deployments needing security review, custom rollout, and procurement support.
- SSO and workspace controls
- Deployment and rollback planning
- Databricks co-sell support
- Security and compliance review
Ileri has a starter tier in the product today. Paid plans are not self-checkout yet; the next step is a short fit review so pricing matches deployment scope, data residency, and support needs.
Full pricing detailThe ones security and procurement ask first.
Answered the way they would be answered on a call, which is the only way worth answering them.
Are you SOC 2 or ISO 27001 certified?
No. Ileri has controls in code, including AES-256-GCM encryption at rest for integration secrets, organization-scoped records, a tamper-evident ledger, and monitoring configuration in the repository. It does not have an attestation, and a control is not an attestation. If certification is a hard gate for your procurement, say so early and we will tell you where that stands rather than manage the question.
Does this replace Unity Catalog?
No, and it is not trying to. Unity Catalog governs whether you can access an AI asset. Ileri governs whether that AI is trustworthy, fair, safe, and compliant, and writes the proof back into your own catalog. The two answer different questions and the second one needs the first.
Can we run it inside our own environment?
Yes. Docker Compose for local and single-host, Helm charts for both the API and the web service, a Databricks App that runs in your own workspace, and Lakebase for transactional state on Databricks managed Postgres. The infrastructure manifests are source-visible, so your platform team can read the operational shape before committing to anything.
Where does the evidence live, and can we keep it?
In your catalog. Governance outcomes are written back as Unity Catalog tags on the asset, evidence is exported to Delta through the SQL Statement Execution API with an idempotent MERGE, and reports are generated artifacts. If you stopped using Ileri tomorrow the evidence would still be in your workspace.
Is there an SDK, and can I install it from PyPI?
There is a Python SDK in the repository at sdk/python, exposing trust_score() and verify_ledger(). It is not published to a package index today, so it installs from source. Python is the only SDK; there is no JavaScript, Go, or Java client.
How is one organization isolated from another?
In two layers. Every query is organization-scoped in application code, with a canonical org_id carried as a string across services. On the core governance path (Promise Ledger, Trust Score, audit, compliance evidence, cross-modal risk) that scoping is backed by Postgres row-level security with FORCE ROW LEVEL SECURITY across nine governance tables, activated by pinning a dedicated connection per request and setting the app.current_org_id session GUC on it. A service on that path that forgot its organization filter still could not read another tenant’s rows. Two limits worth stating plainly: the database layer covers the governance core rather than every service, and the middleware is fail-safe, so without a database or an organization context the request continues on application-level scoping alone. Your reviewer can check all of it in the open: migrations 009 and 020, the middleware, the route wiring, and an integration test.
What does the system do when it is not sure?
It fails closed. When the system is uncertain it denies rather than guesses, and it shows an empty state rather than a plausible one. This is a stated product principle and it is why you will not find a seeded demo dashboard here presented as real usage.
Can we buy it today without talking to anyone?
Starter, yes: sign up and you get a private organization. Growth and Enterprise, no. Paid plans are quoted after a short fit review so pricing matches deployment scope, data residency, and support needs. That is slower than a checkout button and it is the truth.
What proof can we look at before we commit anything?
A live demo environment at demo.ileri.ai, a live API, deployment manifests in the open, and evidence export in formats you keep. There is no customer logo wall on this page because there are no customer logos to show, and inventing them would break the promise the product is named after.
Start with the demo. Decide from evidence.
The demo is live, the API is live, and the deployment manifests are in the open. Look at all three before you talk to anyone, including us.
Ìlérí is Yoruba for promise. The product is named after the thing it is expected to keep.