EduNavigator AI: a teardown of our own build

EduNavigator AI is our own build, demonstrated against a fictional study-abroad consultancy in Ludhiana — not a client deployment. As with any teardown, the decisions only mean something if you know they're ours to defend, not a client's result to report.

The premise: students ask questions that need both narrative and data at once — "what fits my ₹20 lakh budget for a January intake?" — and generic chatbots fail in one of two directions. Either fluent prose with an invented deadline, or an accurate spreadsheet nobody reads. Both fail exactly where the cost is highest: admissions decisions, not casual browsing.

The hybrid answer is the product

The core decision: one response streams a grounded explanation with numbered citations, then a table captioned to say plainly what it is — matched records, queried live against the current catalogue, not generated by the model. The explanation and the numbers arrive together, and the table cannot drift from the underlying data because it is derived at request time rather than written into the answer as text.

The obvious approach would have been to let the model describe the matching programs in prose, the way a general-purpose assistant does by default. We rejected that because prose is exactly where invented deadlines and invented tuition figures sneak in — a model asked to describe a table in words is a model asked to paraphrase numbers, and paraphrased numbers are where the hallucination risk concentrates. Deriving the table at runtime removes that step entirely rather than trying to catch it after the fact.

One dataset, two apps

The student-facing explorer, its chat answers, and the consultancy's admin catalogue manager all read the same shared data module. Editing a record in admin is editing what the assistant says to a student five minutes later.

The obvious approach would have been a separate content pipeline — counsellors update a spreadsheet, someone periodically re-ingests it into the assistant's index. We rejected that because a consultancy's credibility depends on freshness: a tuition figure verified last month may already be wrong, and a re-ingestion step is a delay between a correction and it actually taking effect. One dataset means the delay is zero, and maintenance becomes a workflow counsellors already do rather than a second job layered on top.

Market-specific authenticity, not just translation

Tuition is always shown in the ₹-lakh figure students actually budget in. IELTS bands, blocked-account terminology, SDS-specific vocabulary — the language students and counsellors already use, not a generic international-education glossary. The admin console runs on IST.

The obvious approach would have been to build a generic version and treat the Punjab market as a configuration flag — swap a currency symbol, translate a few labels. We rejected that because the authenticity is not decorative here: a consultancy's clients can tell within one exchange whether the system understands their situation, and getting the vocabulary generically "correct" but locally wrong reads as exactly the kind of tool that doesn't understand the market it's deployed into.

What this is, and isn't

EduNavigator AI is fictional demo data end to end — a consultancy that does not exist, a dataset built to demonstrate the pattern. Nothing in this article or the live build is a client outcome or a real student record.

How to tell if this is your workflow

If your business gives advice that needs both an explanation and current data in the same breath — pricing, availability, eligibility — and today those two things live in different places that can drift apart, this is the pattern to evaluate: one dataset behind both the explanation and the numbers, so a correction in one place is a correction everywhere at once.

← Back to the same admin work, every day