Aletheia

Self-deployable risk management infrastructure for payment companies, marketplaces and fintechs. Aletheia automates decisions about merchants, sellers and users across the customer lifecycle: account opening (KYC/KYB), underwriting and transaction monitoring. It is a workflow engine, a rule engine, installable apps for vendors, an admin console for manual review and policy authoring, and configurable collection flows, run as one platform with one audit trail.

What it is, and what it is not

Aletheia is infrastructure. It gives a team the machinery to express a risk policy (rules, rule sets, workflows, collection flows), run it against subjects, pause for a person when the policy says so, and record everything that happened. It ships no jurisdiction-specific compliance content and holds no opinion about which checks a business must run: the seeded rules and workflows are examples of how to express a policy, not a policy.

Vendors are apps. Sanctions screening, document verification and similar capabilities arrive as WebAssembly modules built with @aletheia-dev/app-sdk, which a tenant installs with its own configuration and secrets and the platform runs in a sandbox, one call at a time. Each release ships a catalogue with a deterministic mock for each capability (mock-sanctions, doc-verify-mock) and one reference integration for each (OpenSanctions, Sumsub) to prove the SDK; it is not a vendor catalogue, and company-registry or other data integrations are apps a customer builds and uploads, not product features.

The five subsystems

• API (apps/api): Fastify with OpenAPI at /docs. It verifies Zitadel tokens, validates every request with the schemas in @aletheia-dev/core, starts workflow runs, serves the UIs, receives vendor webhooks and writes the audit trail.
• Worker (apps/worker): a Temporal worker that interprets published workflow definitions step by step, waits for collection submissions and manual decisions, calls apps, and sends tenants' outbound webhooks and notifications.
• Rule engine (packages/rule-engine): comparison, list lookup, score threshold, expression (CEL), velocity and app rules, aggregated by a rule set's policy into an outcome.
• Apps (packages/app-sdk, packages/app-host, apps/app-runner, catalog/*): vendor integrations as WebAssembly modules a tenant installs, with its own configuration and secrets, run by the app runner in a sandbox bound to one tenant's call, with timeouts, retries and webhooks.
• UIs: the admin console (apps/admin-console: cases, subjects, runs, definitions, versions and approvals, apps, the audit trail and tenant settings) and the collection terminal (apps/collection-terminal: the applicant's form, hosted or embedded). Both reach the API through their own origin. The landing page (apps/landing) shows the product with interactive examples and a page per industry with worked examples, and lets a company sign up for a workspace of its own.

Underneath: Postgres holds the state with row-level security per tenant, Temporal gives runs durable execution, Zitadel provides identity (one organisation is one tenant) and S3-compatible object storage holds documents.

Who it is for

• Platform and risk engineering teams who want to own their decisioning pipeline, keep their policy in versioned definitions and plug in the vendors they choose.
• Developers integrating a vendor: write an app once against the published SDK, and any tenant can upload and install it.
• Analysts and reviewers who work the cases the policy routes to them, with the rule results and the applicant's submission in front of them.

Where to go

You want to	Start with
Run it locally and see a decision happen	Get started, then Tutorial: a first decision
Build on it	Concepts, then Rules, Admin console: Define and Apps
Operate it	Run a pilot, then Deployment and Operations
See a policy expressed end to end	Example policies: a pack for each industry, imported into a tenant in one click or one command
Know where the project is going	Roadmap, then Changelog and Support