As AI takes over more of the routine work, junior associates are losing something they used to pick up almost by accident: the learning that came from marking up a term sheet themselves. They still sit in on the calls and the negotiations, but without having done the groundwork first. That earlier stretch of time with the document was where most of the real learning happened. Without it, they end up watching instead of understanding.
This is a RAG-based legal research tool for Indian PE/VC term sheet negotiations, grounded in the Companies Act 2013 and FEMA. Junior associates can look up key clauses like liquidation preference, anti-dilution and drag-along, or ask a specific question about a negotiating position and get a structured, India-specific answer covering both the founder counsel and investor counsel view, along with market practice and red flags.
Built in two weeks, no budget, no engineering background
I built this on Claude, working in sessions timed around the usage limits. The work ran on two threads at once: one for the knowledge base, researching and encoding how Indian term sheet clauses actually get negotiated, and one for the front end, building an interface where the information is easy to find. Debugging mostly meant taking a screenshot of whatever was broken and dropping it into the Claude chat.
The knowledge base is 33 clause chunks, each structured as a TypeScript object. Every chunk carries a title, keywords, a legal flag with the relevant statutory reference, a risk level, and separate founder and investor positions. The model only answers from the chunks it is handed. No independent research, and nothing invented on questions the database does not cover.
Why keyword search alone was not enough
My first instinct was to keep this simple and score clauses purely on keyword matches. A lawyer asking whether something is market standard wants a clear answer, not a fuzzy score, and keyword hits are easy to explain. The problem showed up fast. Junior associates do not always ask a question in the same words the clause is written in. Someone asking "what happens if I get fired before my shares vest" is really asking about Good Leaver and Bad Leaver provisions, but that question shares almost no vocabulary with how the clause itself is phrased. Keyword search alone would have missed it, even though the database had a clear answer sitting right there.
So retrieval now works two ways. Every clause chunk is converted into a vector embedding ahead of time using OpenAI's embedding model, and those vectors are stored so a live query only ever compares against precomputed data instead of re-processing the whole knowledge base on the fly. When a lawyer asks something, that question gets embedded and compared for meaning against every chunk, while keyword matches still carry extra weight when a query uses precise legal terms like "drag-along" or "1x non-participating." The lp-002 legal flag, for example, points to Section 55 of the Companies Act 2013 read with Rule 9 of the Companies (Share Capital and Debentures) Rules 2014, which governs the issue of preference shares including participation rights, and that reference surfaces because it is tagged directly on the chunk, not guessed at. Generation runs on OpenAI's gpt-4o-mini, which only writes up what retrieval has already found. The app itself deploys on Vercel with a cold start under 100 milliseconds; the only real waiting at query time is embedding the question and generating the answer.
Where generic AI gets Indian law wrong
Ask ChatGPT whether a put option is enforceable in an Indian term sheet and it answers from UK case law, US contract law, and generic fintech guidance. It sounds credible. It is wrong. Indian law on this point runs through the pricing guidelines under Rule 21(2)(c) of the NDI Rules 2019: a put option with an absolute guaranteed exit price higher than fair market value at the time of exercise falls foul of those guidelines. A capped-IRR structure is fine as long as the payout at exercise does not exceed fair market value at that point, and that valuation has to be certified by a SEBI-registered Merchant Banker or a Chartered Accountant, not by an IBBI-registered Valuer, whose mandate sits under the Companies Act and the IBC rather than FEMA. No generic tool gets that right without India-specific grounding.
Generic tools guess. RAG systems retrieve and admit when they do not know.
When a query falls outside the knowledge base, the system says so instead of generating a plausible but unsupported answer. That boundary is the most important design decision in the whole system. A tool that is honest about its limits is more useful to a practitioner than one that answers everything confidently, including the things it should not.
What this architecture trades off
The knowledge base is hand-curated, which means what it covers is solid and what it does not cover is a real gap, not a soft edge. Because the embeddings are precomputed rather than generated live, any change to the knowledge base has to be followed by regenerating them, or the new or edited clause simply will not surface in search, with nothing to flag that it happened. The tool stays deliberately narrow: term sheet clauses only, not SHA mechanics, not M&A precedent, not regulatory compliance checklists. Narrowness is what keeps it from hallucinating. Breadth without depth is where most RAG tools fall apart.
A version built on a firm's own institutional knowledge would look different: more clauses, deeper coverage of multi-investor rounds, integration with SHA templates and precedent, and proper safeguards around keeping the embeddings in sync as the knowledge base grows. But this version makes the underlying point well enough. Junior associates do not need AI to replace the work. They need it to handle the retrieval, the structure, and the India-specific grounding, so they can spend their time on judgment, negotiation, and the relationships that actually matter.
Personal observations from practice. Nothing here constitutes legal advice.