Lumi and decision-as-a-service — the API design
The decision layer should look like Stripe. One endpoint. Plain JSON in. Signed verdict out. Six engines firing in parallel underneath.
Jaswant Singh
Founder, Kauzio
When we designed Lumi, we kept one principle. The decision layer should feel like Stripe. You send a payload. You get a signed response. Everything else is hidden.
```bash curl -X POST https://lumi.kauzio.com/v1/decide \ -H "Authorization: Bearer lk_..." \ -d '{"q":"hire candidate as Q3 ops lead", "context":{...}}' ```
The response is the same JSON shape every time. Verdict, advocate, skeptic, reversibility, six engine outputs, a signed receipt URL, a reminder timestamp.
What is happening behind the API
When the call hits Lumi, six engines fire in parallel. Consequence models the downstream effects. Opposition runs the contrary case. Causal separates correlation from cause. Time Reversal compares to historical decisions. Behavioural checks for bias drift. The Decision Brain synthesises.
The synthesis is signed cryptographically. The signature is anchored to your covenant if you have one. The receipt URL can be shared publicly. Anyone can verify the verdict was real, was unmodified, and was issued at the timestamp claimed.
Why developers care
Three reasons we hear often:
- Compliance. Any decision in a regulated industry needs a record. Lumi makes the record by default.
- Trust. Customers no longer take "the AI said so" at face value. Lumi shows the argument, not just the answer.
- Speed. The six engines run in under 800 milliseconds. The signed receipt arrives in the same response.
Lumi is the decision layer for products that need their AI to be defended, not just deployed. The first integrations are live this week.
Read next
