Technical Report · Reference Implementation
What it takes to build a public-facing admissions and curriculum assistant, what it can and cannot do, and what equipment would be required to host one at the scale of a business school.
Scope
This report describes a working reference implementation of a public website assistant for a business school: a chat widget in the corner of the college's own site that answers questions about admissions, degree programs, curriculum, cost, and policies, using only the college's published pages as its source.
It is written as background for a team evaluating whether to build something similar. It documents an actual build — including a defect found during testing and how it was corrected — rather than describing an idealised system. It makes no recommendation about whether such a system should be built.
Every measurement reported here comes from the build described. Cost and sizing figures are order-of-magnitude estimates for planning discussion, stated with their assumptions exposed so an institution can substitute its own. They are not quotations, and they apply to this class of system only — a public assistant answering from published pages. Any system that reads student records is a different problem with a different cost structure.
Why this problem is smaller
Admission requirements, program pages, curriculum tables, tuition schedules, and academic policies are already published on the open web. An assistant that answers from them reads nothing private, stores nothing about the person asking, and has no connection to any system of record.
That single fact removes most of what makes institutional AI expensive and contentious. There is no FERPA exposure, because no education record is involved. There is no de-identification work, because there is nothing to de-identify. There is no argument that data must not leave the institution, because the data is already public — the college published it deliberately.
The practical consequence is that the usual driver for buying institution-owned inference hardware does not apply to this class of system. Hardware may still be preferred for cost predictability or institutional principle, but the privacy argument that normally carries that decision is absent here.
The build
The assistant appears as a launcher in the lower-right corner of any page on the college site. Opened, it answers questions in conversation, cites the page each claim came from, and links to it.
The constraints matter as much as the capabilities, and each is enforced in code rather than requested in a prompt:
The demonstration website and the assistant are generated from the same source files. An assistant maintained separately from the site it speaks for will drift out of step with it, and the drift stays invisible until someone follows a citation and finds the page says something else.
Mechanism
The technique is retrieval-augmented generation. The language model is never trained on the college's content and holds no knowledge of the institution. Instead, the relevant passages are found first and placed in front of the model, which is instructed to answer from those passages and nothing else.
Each published page is split along its own headings into passages of roughly 200 words. Each passage keeps its page title, URL, section heading, and last-updated date, and is converted into a numerical representation of its meaning. The result is stored in a small local database. For this corpus the step takes about thirty seconds.
Two details in that preparation do more for answer quality than any model choice. Splitting on headings rather than at a fixed character count keeps a complete policy statement in one passage instead of cutting it mid-table. And each passage is prefixed with its position in the document, so a fragment reading "there is no published minimum score" still carries the fact that it sits under Graduate Admissions → Test policy. Retrieval sees passages in isolation; without that prefix, isolated passages are ambiguous.
The question is checked, rewritten if it depends on earlier conversation, and matched against the index. Twenty candidate passages are retrieved and narrowed to eight, with a limit on how many may come from any single page. Those eight are placed in front of the model with instructions to answer from them alone and to cite each claim. Nothing else about the institution is available to it.
Updating a tuition figure means editing the page and re-running preparation — about thirty seconds, performed by whoever maintains the website. Fine-tuning would mean retraining, would require specialist staff, and would still be unable to cite a source, because the facts dissolve into the model's weights and cannot be traced back. No institution is going to retrain a model because a deadline moved.
Accuracy controls
Every factual sentence carries a numbered citation to a page, shown to the reader with its last-updated date and linked. This makes answers auditable: a prospective student, or an admissions officer reviewing a complaint, can check the claim against the source in one click.
Pages marked as superseded are excluded from retrieval by a filter applied at the database, before the model sees anything — not by asking the model to disregard them. The distinction is load-bearing, and the reason is worth stating precisely.
The corpus contains a 2019 page listing a minimum GMAT score of 600, superseded in June 2026 by a test-optional policy with no minimum. With the staleness filter disabled, that archived page takes the top three results for the query "GMAT minimum score required" — it wins precisely because it discusses minimum scores, while the current page says none exists.
Similarity matching has no concept of truth or recency. Asking a model to ignore a stale document that has already been placed in front of it is not a control. Filtering before retrieval is.
Adversarial testing found a defect more serious than fabrication. Asked "What GPA do I need to get into the Business Analytics major?", retrieval returned four of five passages from the graduate MS program and missed the undergraduate page holding the answer. The assistant then reported, correctly given what it had been handed, that no requirement was mentioned.
The answer was fluent, cited, confident, and wrong. There was no invented figure to catch, and nothing in the text signalled a problem. Two corrections followed: the number of retrieved passages was increased, and a limit was imposed on how many may come from a single page — the graduate program had crowded out everything else because its name closely matched the question. A regression test now asserts that the answer-bearing page is retrieved for each of a set of known questions.
This is the residual risk in any system of this kind, and it is worth stating plainly to anyone evaluating one: fabrication is largely solved by architecture; retrieval quality is not. A retrieval miss produces an answer that looks exactly like a good one.
During development the assistant was asked to write HTML, did so, and then explained how to replace it with a Python program — a college assistant quietly repurposed as a general-purpose coding tool. This is the most common real-world failure of institutional chatbots, and it is a reputational problem rather than a security breach.
Controls were built against the 2025 OWASP Top 10 for LLM Applications, in three layers: pattern checks on input, a relevance test that refuses anything unrelated to the college, and pattern checks on output. All are enforced in code. A rule that exists only in a prompt is a request to a model the user is also talking to.
The harder half is not blocking but not over-blocking. The curriculum genuinely teaches Python and SQL, so "Does the analytics program teach Python?" must be answered while "Write me a Python script" must not. An early revision refused "How do I write my statement of purpose?" — a routine admissions question — and the test suite caught it. A control that turns real applicants away has a victim, and unlike a bad answer, nobody reports it.
Setup
The reference build was completed in a single working session on a laptop. The sequence below reflects actual elapsed effort.
The engineering is a small fraction of the work, and this is the single most underestimated aspect of projects of this type. Content preparation and ongoing curation are the project. An institution whose pages are already well-structured in a content management system will find preparation largely mechanical; one whose policies live in PDFs, in tables of varying format, or only in staff knowledge will find it the dominant cost — and no amount of engineering substitutes for it.
Results
Every figure below is from the reference build. They describe a small corpus under controlled testing and should be read as a demonstration that the controls function, not as a prediction of production accuracy.
| Suite | What it checks | Result |
|---|---|---|
| Automated tests | Guardrail logic and golden retrieval assertions | 130 / 130 |
| Security probes | Injection, extraction, scope escape, plus six controls that must not be blocked | 23 / 23 |
| Grounding probes | False premises, non-existent entities, buried caveats, numeric precision | 8 / 8 |
| Threshold calibration | 27 questions; legitimate scored 0.62–0.84, unrelated 0.44–0.58 | clean separation |
| False refusals | Legitimate questions wrongly turned away at the chosen threshold | 0 / 15 |
The grounding probes are the more informative set. Asked for a minimum GMAT score that no longer exists, the assistant stated that none is published. Asked about a non-existent "Round 5" deadline, it replied that only four rounds exist. Told incorrectly by the user that a colleague had given a different deadline, it declined to agree and identified the likely source of the confusion. Asked about a real admissions test absent from the corpus, it declined rather than guessing either way.
Hosting
Sizing depends on how many people use it, so the model below is stated with its assumptions exposed. An institution should substitute its own website analytics; the conclusion turns out to be insensitive to them.
| Quantity | Assumed | Basis |
|---|---|---|
| Conversations per month | 20,000 | Substitute actual site analytics |
| Questions per conversation | 3 | Observed pattern in comparable widgets |
| Questions per month | 60,000 | Derived |
| Share of daily volume in the peak hour | 8% | Typical for a public site |
| Questions in the peak hour | ~160 | Derived |
| Sustained generation demand at peak | ~11 tok/s | At ~250 words of answer per question |
A single current-generation inference card serves on the order of 1,000 tokens per second under batching. The peak demand above is roughly eleven. One card covers the entire college with approximately two orders of magnitude of headroom.
A second card is therefore purchased for redundancy, not capacity. The practical consequence is that usage growth does not drive hardware spend — the hardware sits at a reliability floor, well below any capacity ceiling, and stays there as adoption rises.
| Option | Equipment | One-time | Annual |
|---|---|---|---|
| A · Commercial API No inference hardware. Questions and public page text are sent to a vendor. |
One small application server or existing VM capacity (4 vCPU, 16 GB RAM). No GPU. | $0 – 2,000 | $1,500 – 8,000 |
| B · One college-owned GPU Nothing leaves the institution. No per-question cost. |
One server with a single inference card — a 24 GB class accelerator is ample. 72 W, single slot, standard rack; no special power or cooling. | $9,000 – 13,000 | $1,000 – 2,500 |
| C · Redundant pair Option B with failover. Bought for availability, not throughput. |
Two of the above, ideally in separate racks or facilities. | $18,000 – 26,000 | $2,000 – 5,000 |
Ranges are wide because they depend on existing infrastructure. An institution with spare virtualisation capacity and a rack with power to spare sits at the bottom of each range; one buying and colocating new equipment sits at the top. Annual figures cover power, maintenance, and support contracts, and exclude staff.
All software in the reference build is open source with no licence cost: the orchestration framework, the vector database, the model server, and the web framework. The model weights are openly licensed. There is no per-seat or per-query software fee in Options B and C.
A consumer laptop with a 16 GB graphics card — hardware costing under $3,000 that also does everything else its owner needs. The complete system, including the demonstration website, runs on it with no network dependency. This is worth knowing chiefly as a scale anchor: the compute required is genuinely modest, and a pilot does not require procurement.
During testing the model ran roughly eight times slower than expected. The cause was neither the software nor the model: the machine was on battery in a power-saving profile, and the card never left its idle clock state. Diagnostic tools still reported the model as fully resident on the GPU, which is what made it hard to spot. Anyone standing up GPU inference should verify clock and power state under load before investigating anything else.
Operations
The recurring cost of a system like this is not compute. It is the work of keeping the content correct and checking that the assistant is finding it.
A reasonable planning figure is 0.1 to 0.25 FTE, weighted toward content and communications staff rather than engineering. It does not increase materially with usage — a busier assistant asks the same questions of the same corpus.
Limitations
Stated directly, because an evaluation that omits them is not usable:
In summary
A public website assistant is the smallest useful system in this category. It reads only what an institution has already published, requires no identity or authorisation, connects to no system of record, and can be piloted on hardware an institution almost certainly already owns. It commits nobody to anything larger.
The technical risk worth planning against is retrieval quality, not fabrication. Grounding, citation, and staleness filtering are architectural and largely settled; a retrieval miss is neither, and it produces an answer indistinguishable from a good one. Continuous evaluation against known-correct answers is what separates a system that can be trusted in front of applicants from one that merely demonstrates well.
The recurring cost is content, not compute — and that work produces something of independent value. The questions the assistant cannot answer are a continuously updating record of what prospective and current students are trying to find out and the website does not say. That list is useful to an admissions office whether or not the assistant is ever deployed.