Governance
Governed decision automation: an audit trail you can verify, approvals and access you control
Miji is an enterprise decision automation platform built for decisions that have to be explained later. Governance is part of how it runs, not a report added afterwards: every event lands on a hash-chained audit trail you can verify on demand, each decision records the rule version that made it, people approve what the policy says they must, and access, environments and hosting are yours to control.
The questions it is built to answer are the ones an examiner, an auditor or an investor asks: which policy decided this case, on what facts, who approved it, and can you prove the record has not been changed.
In short
- A hash-chained audit trail: each event carries the fingerprint of the one before, verifiable on demand.
- Every decision records the rule version that answered, by content fingerprint, with its inputs and branch.
- Human approval gates resolved by any one, all, or a majority of approvers.
- Role-based access, OIDC single sign-on, and separate test and production environments.
- Managed, or self-hosted on PostgreSQL in your own GCP, AWS or Azure account, with your own AI models and keys.
Logged is not the same as provable
Most systems keep logs, and logs can be edited. Miji's audit trail is hash-chained: every event carries the fingerprint of the one before it, so an edit anywhere breaks the chain. Verification runs when someone asks for it, from the audit view or the API.
- The policy that decided, exactly. A decision records the rule version that answered, by content fingerprint, with the inputs it saw and the branch that fired.
- Who approved, and when. Human approvals are recorded against the run they decided, next to everything the workflow did before and after.
- AI steps on the same record. An AI step's output is stored on the run like every other step, so anyone checking the case sees what the model produced and what the policy did with it.
- Data access. Credit pulls and document access are recorded on the trail as part of the work, not in a separate system.
Control over what changes, and who changes it
| Control | What it does |
|---|---|
| Versioned rules | Every saved rule and decision table version is fingerprinted by its content; a rule impact check shows which workflows use it and which are pinned to a version. |
| Environments | Separate test and production environments, with production deployments pinned to versions. |
| Human approval gates | A person or group signs off wherever the policy requires, resolved by any one, all, or a majority. |
| Testing before release | Replay, batch replay, shadow runs and scenario sets show what a change would do before it decides anything; A/B winners need a second approver. |
| Gate exceptions | Granted only by the roles you name, always with a reason, optionally with a second approver. |
| Role-based access | Decide who may author policy, who may approve decisions and who may only read. |
| Single sign-on | OIDC sign-in with Okta, Entra ID or Keycloak. |
AI under governance
In Miji the policy decision runs on rules, decision tables and exact calculations. AI drafts workflows for a person to review, and runs bounded judgment steps inside them — summarising, classifying, drafting a message for approval. It does not make the policy decision, and nothing it drafts runs until someone deploys it.
AI steps use the model and API key configured for your tenant, so there is no lock-in to one AI vendor and model procurement stays your decision.
Where it runs
- Managed or self-hosted. Run managed, or inside your own perimeter. Storage, secrets, sign-in and email each sit behind a provider interface, so the same build runs on GCP, AWS or Azure.
- A repeatable appliance. The self-hosted deployment on PostgreSQL is scripted and checked in CI on every pull request.
- Tenant isolation. Tenant isolation is enforced in the database.
What an examiner can ask, and where the answer is
| Question | Where Miji keeps the answer |
|---|---|
| Which policy decided this case? | The decision record names the rule version by content fingerprint. |
| On what facts? | The inputs the rule saw, and their sources, are on the run. |
| Who approved it? | The approval is recorded against the run, with who and when. |
| Were identical cases treated the same? | The engine applies the policy rather than each person interpreting it; the rule version and branch are recorded per case. |
| Has the record been changed? | Verify the hash chain on demand; an edit anywhere breaks it. |
| What did AI do in this case? | Each AI step's output is on the run, next to the steps around it. |
On the roadmap
Not available today. Listed so you can see where this is going — the capabilities above are the ones you can use now.
Draft, approve, publishBuilding
Require a second person to approve a policy change before it takes effect.
Compliance packBuilding
An AI usage register, an examiner export and officer attestation, built on the audit trail.
Decision noticesBuilding
Approval, decline and counteroffer documents generated from the decision record.
SQL Server for self-hostingBuilding
Running the self-hosted appliance on SQL Server as well as PostgreSQL; in conformance testing today.
Fair-lending exportsNext
Decision outcomes, reasons and overrides exported by period for fair-lending analysis.
See a decision's full record, from inputs to approval, and verify the chain on the call.
Book a demoFrequently asked questions
What is a tamper-evident audit trail?
A record where each event carries a cryptographic fingerprint of the one before it, so changing any event breaks the chain and the change can be detected. Miji's audit trail is hash-chained this way, and the chain can be verified on demand from the audit view or the API.
How do you prove which policy made an automated decision?
Record the policy version with the decision. In Miji each decision names the rule version that answered by its content fingerprint, with the inputs it saw and the branch that fired, so months later the exact policy can be identified.
How does Miji govern AI in decisions?
AI does not make the policy decision. Rules, decision tables and exact calculations decide; AI drafts workflows for review and runs bounded steps such as summarising, and each AI step's output is recorded on the run. AI steps use the model and key you configure.
Can Miji be self-hosted?
Yes. Miji runs managed, or self-hosted on PostgreSQL in your own GCP, AWS or Azure account, with OIDC single sign-on and role-based access. SQL Server support is in conformance testing.
Which single sign-on providers does Miji support?
OIDC providers, including Okta, Entra ID and Keycloak.