EnterFirstKBook a demo
Home/ Platform/ The Engine
The engine

A hundred and thirty specialists. Four thousand days. None of your data.

50+ AI and machine learning engineers over 1,000+ days, alongside 50+ chartered accountants, 20+ top-tier IP lawyers and 10+ former Income Tax Commissioners. Built on India's public tax and IP record — never on customer documents. The people who spent careers answering assessments taught it what an assessing officer is actually asking.

50+ AI & ML engineers
80+ CAs, IP lawyers & ex-Commissioners
1,000+ days building TaxEye
1,200+ days building Entermark
2000 the year RegEye’s record starts
Who built it

Engineers who build it. Practitioners who teach it.

Anyone can point a language model at a corpus of judgments. What separates a usable engine from a plausible one is two things held together — a machine learning team building the architecture, and qualified practitioners labelling it: this argument worked, that one did not, and here is why the officer asked.

50+ AI & ML engineers

1,000+ days building the architecture — the domain pretraining, the retrieval and grounding layer, the similarity engines and the deterministic reconciliation logic. Not a wrapper assembled in a quarter.

Powers every model in the ensemble
50+ CAs & tax practitioners

Over 1,000 days building TaxEye — annotating notices, mapping grounds to sections, marking which submissions were accepted and which drew a second query, and encoding the reconciliation logic behind every figure.

Powers TaxEye · notices, assessment, appeal
20+ IP lawyers, top-tier firms

1,200 days building Entermark — grading similarity the way a registrar grades it, labelling which Section 9 and 11 arguments carried, and codifying when opposition beats rectification.

Powers Entermark · search, prosecution, opposition
10+ Former Tax Commissioners

They sat on the other side of the desk. Their contribution is the part no corpus contains: what an income tax question actually means during assessment and appeal — the concern behind the wording, and what answer closes it.

Powers intent classification across every tax workflow
Reading the question behind the question

A 142(1) asking for "details of sundry creditors" is rarely about the list. It is a bogus-purchase enquiry, or a Section 68 credit-worthiness test, or a year-end cut-off check — and the reply that closes it differs completely in each case. Former Commissioners labelled that distinction across thousands of real questions, which is why the engine drafts to the concern rather than to the sentence.

Why public data

The best training corpus in Indian tax and IP is already public.

Every ITAT order, High Court judgment, examination report and gazette notification is published by the State — hundreds of thousands of documents in which a professional argued a position and an authority accepted or rejected it. That is what the engine learned from, not your client’s bank statement.

A model trained on that learns what actually persuades an assessing officer or a registrar. It does not need to read your client's bank statement to learn it — and so we never had to ask.

Income tax judgments — ITAT, High Courts, Supreme Court 500,000+
Assessment and appellate orders in the public record Continuous
Trademark records and journal publications 75,00,000+
Registry examination reports and objection patterns Continuous
Circulars, notifications and gazette publications 100+ regulators
Client documents used for training None
The regulatory corpus

Complete from the year 2000. Current to this morning.

RegEye's corpus starts in 2000 — the point at which the Indian government began publishing and amending law at its current pace — and has not had a gap since. Every circular, notification, master direction, press release and authority order, from every regulator we cover.

Completeness is the point. A partial archive tells you what changed; a complete one tells you what a provision looked like in the assessment year under dispute, and which amendment moved it.

Corpus start year 2000
Regulators and authorities 100+
Circulars ingested monthly 10,000+
Gap in the archive since 2000 None
Time from publication to verified 60 min
Nothing is sampled Every publication from a covered authority enters the corpus. There is no relevance filter at ingestion — filtering happens at applicability, after the document is already held.
Point-in-time law Because the archive is unbroken, the engine can reconstruct what a provision said in any year since 2000 — which is what an assessment for an earlier year actually turns on.
Amendment chains Each notification is linked to what it amends and what amends it, so a circular is read in the state it was in, not only in its latest form.
Authority orders included Not just circulars and notifications — orders, press releases, FAQs, clarifications and master directions, because binding guidance rarely arrives in one format.

Most legal AI asks you to hand over your files so the model can get better. Ours got better because a hundred and thirty engineers and practitioners spent four thousand days building and teaching it on documents the government already published — which is why "we never train on your data" costs us nothing to promise.

Architecture

Decentralised by design

Learning happens in separate, isolated layers. The base engine improves on public corpora. Your workspace adapts to your practice without any of it flowing back. Nothing crosses between customers, ever.

01 Base engine — public corpora only Trained and continuously retrained on public judgments, orders, journals, registry data and gazette publications. This is the layer that understands Indian tax and IP reasoning, and it is the only layer that learns from a shared corpus.
02 Tenant layer — isolated, private Your firm templates, drafting preferences, precedent library and house style shape output inside your workspace alone. This adaptation is stored per tenant, never pooled, and is deleted with your data on exit.
03 Expert feedback — verified, not scraped When a chartered accountant, company secretary or lawyer on our bench corrects a classification, the correction improves the base engine as a labelled professional judgment — never as a copy of the underlying client document.
04 No cross-tenant learning There is no shared index, no pooled embedding store and no configuration in which one customer’s matter can influence another’s output. This is enforced architecturally, not by policy.
05 Continuous retraining cadence New judgments, journals and circulars enter the corpus as they publish. The engine has not had a training cut-off since inception, which is why it recognises reasoning from last month’s ITAT order.
Technical specification

How the model was actually built

Written for the engineer or CTO on the evaluation call. If a term here is doing work in our stack, it is named; if it is not, it is absent.

Request the architecture note →
Corpus and pretraining What the base engine learned from, and how.
Domain-adaptive pretraining Continued pretraining of open-weight transformer backbones on an Indian legal corpus — ITAT and High Court judgments, assessment and appellate orders, registry examination reports, journals and gazette notifications — rather than training a foundation model from scratch.
Corpus curation Deduplication by near-neighbour hashing, citation-graph normalisation across reporters, OCR quality gating, and temporal stratification so older reasoning does not swamp current statute.
Domain tokenizer Extended vocabulary covering Indian statutory citation forms, section references, Devanagari script and registry shorthand, cutting token count on legal text substantially against a general tokenizer.
Continual learning Rehearsal-based incremental training with replay buffers to absorb new judgments and circulars weekly without catastrophic forgetting of settled doctrine.
Alignment and adaptation Turning a domain model into a professional one.
Supervised fine-tuning Instruction tuning on paired examples — notice to accepted submission, examination report to successful reply — drawn from the public record of what authorities in fact accepted.
RLHF from qualified reviewers Reinforcement learning from human feedback where the annotators are practising chartered accountants, company secretaries and advocates, not crowd workers. Preference pairs come from the verification bench.
Parameter-efficient tuning LoRA and adapter layers for per-tenant and per-task specialisation, so a firm’s house style is a few million trained parameters rather than a forked model.
Constitutional constraints A written policy layer the drafting model is trained and evaluated against: cite or abstain, never assert quantum, never state a filing position without an authority.
Retrieval and grounding Why the output can point at its source.
Retrieval-augmented generation Every draft is grounded in retrieved passages from the judgment and circular corpus. Nothing is generated from parametric memory alone.
Hybrid retrieval Dense bi-encoder embeddings combined with BM25 sparse retrieval and a cross-encoder reranker, so both statutory phrasing and factual similarity are matched.
Legal knowledge graph Entities, sections, forums, parties and citations modelled as a graph, enabling traversal by precedential authority and treatment rather than text overlap alone.
Citation verification Generated citations are resolved against the corpus before display. An unresolvable authority is dropped and the passage flagged, which is how hallucinated case law is prevented structurally.
Context assembly Long-context windows with hierarchical chunking and map-reduce summarisation for multi-hundred-page paper books and assessment records.
Document understanding From a scanned PDF to structured facts.
Layout-aware parsing Vision-language document models over OCR output, reading tables, stamps, annexure structure and multi-column orders as layout rather than as a flat character stream.
Named entity recognition Domain NER for assessment years, PAN and GSTIN, section references, quantum, forum, limitation dates and party roles, trained on annotated Indian tax documents.
Multilingual pipeline 12+ Indian languages with script detection and transliteration handling for regional registry and state gazette material.
Deterministic reconciliation Bank credits and debits matched to books by a rule engine with fuzzy party matching — arithmetic, not generation. Anything untied is flagged rather than inferred.
Similarity engines The trademark side of the stack.
Phonetic matching Indic-adapted phonetic algorithms beyond Soundex and Metaphone, handling transliteration variance across Devanagari and Roman script filings.
Visual similarity Convolutional and vision-transformer embeddings over device marks, with perceptual hashing for near-identical logo detection.
Conceptual similarity Semantic embeddings that catch marks meaning the same thing without looking or sounding alike — the class of conflict string search structurally cannot find.
Class-wise risk scoring A gradient-boosted model over similarity signals, class overlap, goods and services proximity and registry outcome history, calibrated against decided opposition results.
Evaluation and safety How we know it works, and what stops it when it does not.
Held-out benchmark A professionally annotated evaluation set of Indian notices, examination reports and circulars, kept out of training and refreshed each quarter.
Ground-truth labelling Applicability classification is scored against the verifying professional’s decision, giving a real label on every circular rather than a sampled audit.
Hallucination controls Abstention thresholds, citation resolution, span-level attribution back to source text, and confidence gating that routes low-certainty output to the bench rather than the client.
Regression and drift Automated regression suites on every model release, with drift monitoring on classification distributions as statute and registry practice change.
Red teaming Adversarial testing for prompt injection through uploaded documents, data exfiltration attempts and jurisdictional confusion between Indian and foreign law.
Infrastructure and isolation Where it runs and how tenants stay apart.
In-region inference Indian customer workloads run in AWS Mumbai, with encrypted backups in AWS Hyderabad. Documents are processed in-region and are not sent outside India.
Per-tenant vector stores Namespaced embedding stores with hard tenant boundaries. No shared index, and no configuration in which one customer’s matter can surface in another’s retrieval.
Federated adaptation Tenant-side learning stays tenant-side. Only aggregated, de-identified professional judgments from the verification bench feed the base engine — never document content.
MLOps Versioned model registry, reproducible training runs, staged rollout with shadow evaluation, and one-command rollback. Every inference records the model version against the matter.
Inference optimisation Quantised serving, KV-cache reuse and batched inference to hold sub-3-minute document processing and sub-30-second drafting through statutory deadline peaks.
The stack

An ensemble, not a wrapper

Different problems want different models. A phonetic similarity judgment and a limitation calculation should not run through the same architecture, and in our stack they do not.

Document understanding Layout-aware parsing of scanned notices, orders and examination reports into structure — grounds, sections, dates, parties and quantum — rather than into prose.
Legal reasoning models Trained on 500,000+ judgments to match a matter by its facts and issues, not its keywords, and to surface the precedent that actually governs it.
Similarity engines Phonetic, visual and conceptual comparison across 75 lakh trademark records, graded class-wise into a filing or opposition recommendation.
Applicability classifier Decides which of 100+ regulators’ publications bind a specific entity by licence, sector and activity — 99.7% accuracy against expert review.
Reconciliation engine Deterministic, not generative. Rupee-exact matching of credits and debits against books, ledgers and prior filings, flagging anything it cannot tie.
Drafting layer Generative, but constrained — assembles into global standard formats and your firm templates, citing the source behind every proposition.
Multilingual processing 12+ Indian languages for regional registry, state gazette and vernacular correspondence.
Verification interface Where the professional bench confirms or corrects. Every correction is a labelled datum for the base engine and a record in your audit trail.
Guardrails

What the engine is not allowed to do

01 File anything Every submission passes a maker-checker gate where a qualified professional reviews and approves. There is no configuration in which the engine files unsupervised.
02 Assert without a source Drafting output cites the judgment, section or circular behind each proposition. Anything the engine cannot ground, it flags rather than fills.
03 Compute what should be calculated Reconciliation is deterministic arithmetic, not generation. Figures are matched and tied, or flagged for a human — never estimated.
04 Learn from your matters Client documents are processed for your matter and are not retained as training data, in any layer, under any plan.
Questions

What technical reviewers ask

+Who actually trained the model?

50+ AI and ML engineers over 1,000+ days built the architecture. 50+ chartered accountants and tax practitioners spent 1,000+ days on TaxEye, 20+ IP lawyers from top-tier firms 1,200 days on Entermark, and 10+ former Income Tax Commissioners taught it what an assessment or appellate question is really asking. The engine has also been in continuous training since inception, so there is no knowledge cut-off between the public record and what it recognises.

+How far back does the regulatory corpus go?

To the year 2000, without a gap — the point at which the Indian government began amending law at its current pace. That completeness is deliberate: an assessment for an earlier year turns on what the provision said then, so the engine reconstructs point-in-time law and follows the amendment chain forward.

+What does decentralised learning mean here?

Learning is split into isolated layers. The base engine learns only from public corpora. Your workspace adapts to your firm privately and never contributes to the shared model. Expert corrections improve the base engine as labelled professional judgments, not as copies of client documents. There is no pooling across customers.

+So you genuinely never train on our data?

Correct — and it costs us nothing to promise, because the training corpus is the public record. The engine learned Indian tax and IP reasoning from half a million published judgments and 75 lakh trademark records. It does not need your client files to do that, and it does not get them.

+Is this a wrapper around a general-purpose model?

No. It is an ensemble: layout-aware document understanding, legal reasoning models trained on Indian judgments, phonetic and visual similarity engines, a deterministic reconciliation engine, and a constrained drafting layer. General-purpose models are used where they are genuinely the right tool, inside that structure and never as the whole of it.

+How do you measure 99.7% accuracy?

Applicability classification is measured against the decision of the professional who verified it. Every circular is reviewed by a lawyer, chartered accountant or company secretary, so each classification carries a ground-truth label. The figure is the agreement rate over that review set.

+Where does the engine run?

Indian customer workloads run in India — AWS Mumbai for production, AWS Hyderabad for encrypted backups. Documents are processed in-region and are not sent outside it. Sub-processors, including model providers, all operate within India and are listed in the register available on request.

+Can we audit the output?

Yes. Every classification, draft and figure links to its source, and every action, version and approval is timestamped in an immutable audit log exportable in full for regulatory review.

Put the engine on one of your own matters.

Thirty minutes, your file, our bench — and a security questionnaire answered in writing if your reviewers need it.

Book a demo Read the security policy