Mimir · the Modules intelligence engine · internal review
Domain-agnostic by design. Industry knowledge is injected as a pack, never built in — so a new product is a configuration, not a platform.
To: Engineers & Architects — review meeting tomorrow.
The problem shape
Collect evidence → understand it → check it against truth → cost it → decide (auto or human).
Photos + RC + estimate → damage, verify plate, cost repair, approve or investigate.
ID docs → read fields, match registries, flag forgery, pass or review.
Asset photos → grade condition, check loan-on-asset, value it, lend or decline.
Build each one bespoke, and you rebuild the shape every time. That is the waste.
The thesis
Pack (product layer) — per category · assembled by PMs · no engine change
Platform (engine) — built once · domain-agnostic (design intent)
Same engine · drop a pack · a product appears
The marginal cost of the next product is a pack, not a platform.
Component architecture
Edge / Delivery
Case — system of record
Intelligence engine — capability services
Orchestration + shared engine
Cross-cutting — wraps every plane
The capability services
A stable domain-neutral contract. The pack supplies the schema, model, rules and reference data it runs with.
| Service | Does | In → out | Sold as |
|---|---|---|---|
| Capture | Collect evidence, no install; gate quality | request → validated artifacts + consent | per session |
| Extract | Documents → structured fields | docs → typed field signals + confidence | per document |
| Vision | Images/video → features; or diff two sessions | media → feature signals | per inspection |
| Verify | Prove authenticity vs sources of truth | entities → match / mismatch signals | per lookup |
| Detect | Risk score over the whole signal set, with reasons | any signals → checks + score | per case |
| Estimate | Features → itemised cost / repair-vs-replace | features + ref data → line items | per estimate |
| Decide | Thresholds: auto-clear vs route to human | signals + thresholds → decision | per decision |
Every service outputs the same three things: structured JSON + branded PDF + an immutable audit entry. The report is the union of whatever stages ran.
One case, end to end · pack = Motor
The middle (component) never changes between products. Only the pack does.
The leverage
Steps 1–8 and the whole component column stay identical. Point it at a new domain by changing only the pack.
pack = Motor
pack = Lending
pack = KYC
pack = Health
The engine rail above never moves. Only the pack below it changes — and the product changes with it.
How we pressure-tested it · the back-test
Method: take a product we want to build, push it through the architecture on paper, find what it lacks — then add that component. The architecture is the result of this exercise. The thesis held for every product.
Illustrative — a design exercise; nothing shipped yet.
Notable additions the back-test surfaced
The agentic product needed an LLM to pick steps — not just a fixed DAG.
Estimate-from-images needed priced catalogs and a calc capability.
Fraud rings and duplicate financing aren't single-case problems.
"Best capture" is itself a product — and a shared enhancer.
Every model-using service needs provider-agnostic, compliance-aware routing.
Per-domain regimes must not fork the engine — declared by pack, enforced by platform.
Buy vs build · for the CTO
Next three slides go role by role: CTO → architect → ML. Then we're back together.
We are not writing a vision model or a workflow engine from scratch. The IP is how the pieces compose, and the packs that run on them.
Integrate — commodities
Build / own — the moat
Damage detection is commoditising. We don't win on one model's accuracy — we win by reading the whole case and deciding with compliance.
Execution model · for VP Eng + Architect
Every capability is reachable both ways R17
Low-latency, single-shot, bounded: "verify this PAN", "is this image tampered". Returns inline.
Long-running, multi-stage, human-in-the-loop. 202 + case id → webhook on completion. Default for full products.
Priority classes + per-capability queues + per-tenant fairness. A Vision backlog never blocks Verify.
Two orchestration modes — same services underneath
Pack-defined DAG over the case. Stages optional, partial-input tolerant, durable; pauses for human review for days; emits an event per transition. Default for structured products.
An LLM reasons over the case and calls capability services as tools. Guardrailed (incl. compliance), case-scoped memory, and a full reasoning trace that is itself an audit artifact. Powers agentic products.
Models & learning · for ML
We integrate and route models — own and third-party. We are not a model lab.
Provider-agnostic access to LLM + vision models. Routing, fallback, versioning, cost/latency control.
Compliance-aware: never routes restricted PII to a non-compliant model or region; redacts before egress.
Used by Extract · Vision · Detect · Estimate · Agent Runtime.
The Review Console captures human decisions; corrections become labels. Designed so every correction improves the engine — the training loop is built in, not bolted on.
Versioned models + eval sets per pack. Designed to let us publish accuracy per capability, per pack (Phase 2+) — a differentiator in a market of vendor-claimed numbers. Not measured in prod today.
Compliance · a product USP
A pack declares its regime (health/DPDP, insurance/IRDAI, lending/RBI, residency everywhere). The platform enforces it at runtime. Compliance is never re-implemented per product — so it's a selling point, not a per-product cost.
| Control | Enforced as |
|---|---|
| Data residency | Where evidence + PII are stored and processed, incl. model routing |
| Consent lifecycle | Versioned, checked before processing; withdrawal honoured |
| Retention & erasure | Per data class; right-to-erasure; auto-expiry |
| PII handling | Field-level encryption, tokenisation, redaction, minimisation |
| Control | Enforced as |
|---|---|
| Purpose-limited access | Who/what may read which signals, for what declared purpose |
| Regulator-grade audit | Immutable, exportable case history — the event log |
| Decision guardrails | Never auto-clear above a legal cap; AI-decision provenance recorded |
| Posture | SOC 2 / ISO 27001 / DPDP + model & eval provenance |
Built once, inherited by every pack. Every product on Modules is compliant for its domain the day it ships.
Caveat: residency, consent, retention and audit are platform mechanisms; model-region routing and novel regulatory obligations are real build work, not a config flag.
Build phases
Phase 1
Exit: one product live; every decision explainable + auditable.
Phase 2
Exit: two products, two domains, one engine, no forks.
Phase 3
Exit: generalised only once the shape is proven.
Deliberately deferred (YAGNI): pack-authoring SDK / marketplace, Agent Runtime, cross-tenant link graph, audio modality — none until a second real product forces them. One example can't design a good extension API.
The one existential risk · and the discipline
If "bumper", "fracture" or "room" ever appears in engine code, the thesis is dead — the engine has quietly become a vertical product. This is a discipline problem, and we guard it with two mechanisms.
Every stage writes typed signals to the case; downstream stages read the whole set, not each other's APIs. Detect's fused checks ("parts billed with no visible damage") are rules over a generic signal set — not code that knows about vehicles. Load-bearing: it's what makes a fused check domain-neutral.
Feature vocabulary, sources of truth, price basis, risk rules and thresholds live only in a pack. If a new domain needs something the six pack slots can't express, that's a signal to extend the engine contract deliberately — never to special-case a domain in engine code.
The guardrail is architectural, not just a code-review rule: the engine speaks signals, the pack speaks domain.
The ask
One decision: greenlight Phase 1 — build one motor product end-to-end (inspect + fraud), with a design partner, on bought infra. Success = evidence in → an explainable, auditable decision out, live.
Approve the buy-vs-build split and the Phase 1 scope. Confirm the pack contract + Signal model are the two interfaces we design most carefully.
Staff Phase 1 as a normal product build on bought infra. If we can't staff it, that's the gate — nothing downstream matters.
Own the pack feature schemas, fused-signal rules, and the eval/feedback loop. Confirm the Model Gateway + VLM integration path.
Greenlight a design partner and the "one product first, platform story after pack #2" framing. Pick the first vertical: motor.
Define the motor product's surface and entitlements; line up the design partner. Hand-author the first pack with engineering.
A platform commitment, a second vertical date, agentic, or cross-tenant anything. Those gate on Phase 1 shipping and the pack contract holding.
What this unlocks
Platform — engineering
One engine: Capture → Extract → Vision → Verify → Estimate → Detect → Decide. Built once, deepened over three phases, compliant by construction.
Packs — product
Six bindings per domain + entitlements + surface. A PM chases a new market by writing configuration — engineering keeps building depth in the common engine.
The marginal cost of the next product is a pack, not a platform.