The two drift
A policy changes in a meeting and reaches the system a quarter later. In between, branches improvise and overrides pile up.
In development — design partners welcome
YT
Yantra
A lending process you can change on a Tuesday and defend in an inspection.
The problem it exists for
Every regulated lender runs on two versions of its own rules
One is written — the credit policy, the RBI obligations, the delegation of powers — and lives in documents. The other is enforced — and lives in software, configured months earlier from someone's reading of those documents.
Reconstruction becomes a project
"Which rule was this March file decided under?" stops being a question and becomes an archaeology exercise across documents, tickets and code.
That gap is where the cost lives
The distance between what the firm decided and what its systems do is where most inspection findings, operational risk and audit cost originate.
The idea
Remove the translation instead of speeding it up
The firm's rules become one governed rulebook: every rule is a named, versioned clause with an owner and a record of who adopted it. A process is neither code nor a document — it is a sheet of decisions that cites clauses in that rulebook. A compiler turns the sheet into a signed, executable artefact; the runtime executes only that artefact, writing a receipt for every act.
The written policy and the enforced policy become the same artefact. There is no window in which they diverge, because there is only one of them.
Rulebook
Named, versioned, ratified clauses
each with an owner and a date of adoption
Authoring
The process sheet
decisions citing clauses, by name
Compiler
Proof & seal
checks every citation, then signs
Runtime
Yantra
executes only the signed artefact
Record
The register
a receipt for every act, append-only
Conformance
Reads both ends
what the rulebook says, what actually happened — and the difference
Five things to hold onto
What makes this different from a rules engine
One rulebook — ratified, not just loaded
It ships with the RBI obligations pre-loaded and citations intact, but nothing has force until the firm adopts it in a dated, minuted act. Interpretation — and liability — stays with the firm, and a supervisor gets what they actually want: the firm's own act of adoption, not a vendor's assertion.
Rules keep their addresses
Every clause carries a name, a version, an owner and two dates — when decided, when effective. Lists such as negative districts or valuer panels are cited by name, never copied in: adding a district takes hours, yet every past decision still replays against the list as it stood that day.
Change is a governed act, not an IT project
A change arrives as a diff of the rule itself, classified by what moved — a label, a number, the flow, or a control — and the class sets the ceremony, up to two distinct human signatures. Before anyone signs, it is rehearsed against real decided files: "37 of the last 90 days' files would have gone the other way." And a process change can never quietly change the rulebook — touching a rule is always its own act, through its own gates.
Everything leaves a receipt
Every act — human, AI or third party — lands on one append-only register, with a receipt naming exactly which rule versions it saw. A nightly sample is re-executed to prove the record honest. Audit stops being assembly: an auditor asks a typed question and gets an answer with a verifiable hash — one register serving internal audit, statutory audit and an RBI inspection alike.
AI proposes; it never decides
Agents read the same rulebook, draft, spot drift and propose changes — into the same gates as anyone else's proposal. Autonomy is granted per action with permanent ceilings: sanction and disbursal remain human acts forever, whatever the technology upstream becomes.
Where a firm starts
Not with the runtime — with Conformance
The first engagement reads twelve months of what the firm already does, from systems it already runs, and holds it against the rulebook it has just ratified. Findings run both ways: obligations with no control operating, and consistent unwritten practices that belong in the rulebook or nowhere. The runtime, when it arrives, enforces a rulebook already proven against practice.
An inspection in 90 days
The risk officer wants to know what will be found, before it is found.
The firm ratifies a slice
Secured-lending obligations, adopted on a dated, minuted act. This is the engagement's precondition, not its output.
Evidence signatures
What would show each obligation has a control operating — and, honestly, how much of it is genuinely checkable.
Twelve months of history
Loan origination, core, document management and approval trails — normalised, with lineage kept back to every source row.
Named, with case IDs
Obligations with no control observed, cases in declared gaps, recurring deviations and drift — each naming its clause version, its evidence and its cases.
Remediation is authoring
Findings enter the inbox as proposed changes and take the gates their class demands. The phase ends when the first process sheet is authored.
A worked finding
The shape of what Conformance surfaces
The obligation is unglamorous and typical: valuations must be performed by a valuer on the firm's approved panel. Every firm has this rule. Almost no firm can prove it held.
| 4,120 | valuations in twelve months |
| 4,059 | valuer on the panel on the valuation date |
| 61 | valuer not on the panel on that date — though 47 of them are on it today |
| 3 | branches accounting for 52 of the 61 |
The 47 are the finding no other tool produces. A system comparing today's panel against a historical file sees nothing wrong — the valuer is on the list. Only a list that can be asked as of the valuation date shows that the approval came afterwards.
These figures are illustrative. They show the shape of a finding and the kind of question the engagement answers. They are not a client result, and we will not present them as one.
Four things Conformance must never do
- Audit against the regulator. Findings are stated against the firm's own ratified rulebook, never against RBI. "Your process violates the Digital Lending Directions" is a vendor interpreting a regulation on a regulated entity's behalf.
- Call a finding a receipt. Evidence read from other systems carries no derivation chain and no pinned rule version. Findings carry coverage and confidence; receipts carry proof. Conflating them is the audit-side version of overclaiming.
- Infer a control. What ships is a difference against signatures a person authored — not a grammar induced from the firm's own history.
- Start before the paperwork. Findings are discoverable. Scope, retention and privilege posture are agreed before the first run.
Why this is not something that already exists
Every piece of this exists somewhere. The combination does not.
There is no category to point at and say "like that, but better". Several adjacent categories each do one part of this well and structurally cannot do the rest. The honest version of the claim is not that the parts are novel — it is that they have never been made to hold each other up.
| Category | What it genuinely does well | What it cannot do here — and why that is structural, not a roadmap gap |
|---|---|---|
| Workflow & BPM | Orchestrates long-running, human-in-the-loop work reliably. Yantra uses durable orchestration underneath. | The rule lives in configuration or code beside the flow. There is no ratified law with owners, versions and two clocks — so a change cannot be rehearsed against last quarter's real files, and a refusal cannot cite a clause, because there are no clauses. |
| Rules engines & BRMS | Executes decision logic fast and deterministically. Yantra runs one inside it. | A rule repository is not a rulebook: no ratification act, no strata, no scope inheritance, no bitemporality, no build-time proof obligations. Crucially, no impact rehearsal — no rules engine tells you "this change would have altered 340 of last year's decisions, here they are, sorted by exposure." |
| GRC & controls monitoring | Tracks controls, tests, findings and attestations at enterprise scale. | The control record and the executing system are two different things, so drift between them is guaranteed by construction — it is the category's founding assumption. Here the control is the executing artefact; there is nothing to reconcile. |
| Process mining | Discovers what actually happens from event logs, at a scale no analyst matches. | It compares practice against a reference model somebody drew. Nobody ratified that diagram, no seat owns it, and no board minute stands behind it — so its findings are operational insight, not assurance. Ours compare practice against ratified law. |
| Origination & core platforms | Run the lending business end to end, with deep domain coverage. | The rules are inside the product. Changing one is a vendor release on a vendor's calendar — which is the original problem, not a solution to it. |
| Policy-as-code | Decidable guards, versioned in Git, tested in CI. The closest technical cousin. | Built for engineers, not for a Credit Committee: no ratification model, no seats, no change classes, no bitemporality, no rehearsal against historical outcomes, and no way for a Head of Credit to read — let alone sign — what is being enforced. |
| LLM copilots & agent frameworks | Read, draft and reason over messy material better than anything before them. | Intelligence without a harness. No addressable rulebook to cite, no receipt naming which rule version was seen, no ceiling that survives a confident quarter, and — most damaging in this domain — no way to abstain that is architecturally distinct from failing. |
The defensible part
Four properties that have to co-occur
Each of these exists in isolation elsewhere. The claim is about the joins between them, and each join is load-bearing.
1 · Law with addresses
Every rule is a named, versioned, owned clause with two clocks — so it can be diffed, signed, cited in a refusal, and traced back from an override.
The join: without this, none of the other three can exist, because there is nothing to prove, rehearse or receipt about.
2 · Proof at build time
Coverage, precedence, decidability and staleness are settled before anything runs, and an unresolved clause pair is a build failure rather than a runtime coin-toss.
The join: this is what lets the runtime be small and dumb — and what makes a signature meaningful, because the signer is signing something already proved internally sound.
3 · Rehearsal against history
Every consequential change is replayed against real decided files before anyone signs.
The join: it converts governance from an argument about intentions into an argument about outcomes — and it is only possible because 1 and 2 make old decisions reproducible.
4 · Receipts that replay
Every act names the artefact digest, clause versions, list snapshots and engine build it saw; a sample is re-executed nightly.
The join: this is what makes the first three checkable by an outsider, rather than a description of good intentions on a slide.
Where the design comes from
A grammar that has survived two thousand years of amendment
The architecture is lifted, deliberately and in detail, from Pāṇini's grammar of Sanskrit — a rule system of under four thousand sūtras that generates an entire language, has been transmitted for more than two millennia without corruption, and carries inside itself a symbol table, a metalanguage for reading its own rules, externalised word-lists, a published conflict-resolution algebra, and a provably final section.
Those are not decorative parallels. They are the same six mechanisms a regulated rulebook needs: defined terms, rules about how rules are read, lists held outside the rules that cite them, a stated order of precedence, and a way to know the corpus is complete.
The property being borrowed
Compression that preserves addressability
A modern language model compresses a corpus superbly and destroys every address inside it. There is nothing to diff when a Master Direction is amended, nothing for a committee to sign, nothing for a refusal to cite.
Pāṇini's compression does the opposite: it is dense and every unit stays named, quotable, amendable and individually ownable.
That is exactly what a regulated firm needs from its rulebook — and it is why the model in this system reads the rulebook constantly and never is the rulebook.
Deployment
Built for an Indian CIO's requirements list
- Runtime
- Durable orchestration underneath — Temporal today, behind a seam designed so other engines can be offered as a customer choice
- Tenancy
- Single-tenant, deployed into your own cloud account or private infrastructure
- Identity
- Entra / OIDC federation with policy-based authorisation
- Keys & monitoring
- Customer-managed keys; event forwarding to your own security stack
- Residency
- India data residency, with a controlled gateway for any model access
- Evidence
- Append-only register; nothing in it has an update path
Honest scope
What it is worth — and what it does not do
The distance between what the lender decided and what its systems enforce goes to zero — and that distance is where the risk lives.
The platform itself decides nothing. Every limit, carve-out and signature belongs to a named person. Its contribution is that those decisions are visible, rehearsed, receipted — and impossible to make by accident.
Build status. Yantra is in development. The architecture, domain model and first engagement are defined, and the governance core is the current focus. What is described here is a design commitment rather than a shipped capability — we would rather say so now than have you find out in month nine. We are working with a small number of NBFC, insurance and banking design partners who want to shape it against their own process.
Start where it costs nothing to be wrong
A Conformance engagement needs no runtime and no migration — twelve months of history you already hold, against a rulebook you ratify in week one. Bring one secured-lending process you cannot currently prove.