How this site is built
This site is built to show an approach to AI delivery: decide by measurement, keep the model on a short lead, publish the failures. It was built with an AI coding agent under Karthick's direction. Every figure below was measured on this system on 13 November 2026 unless it says otherwise.
What happens when you paste a job description
- Clean. Control characters are removed and length is capped. Your text is treated as data, never as instructions.
- Extract. A small, fast model lists the requirements and the hard constraints. Each must quote your text exactly; anything that does not is dropped.
- Read the whole profile. The assessor is given all67 approved evidence records, plus a capability map that groups them by what Karthick can do. No search step decides what it sees. Those records are the only source of claims about him.
- Map. A stronger model works out what each requirement asks for, reads the records that bear on it together, labels it demonstrated, partial, not demonstrated or unknown, and cites the records. Requirements are mapped in parallel batches to cut waiting time.
- Check. Code, not a model, removes citations that are not in the approved catalogue, downgrades any supported claim left without a citation, and replaces any explanation containing a figure that is not in its sources.
- Score. The percentage is plain arithmetic in server code: essential requirements weigh 3, unspecified 2, desirable 1; demonstrated counts 1, partial 0.5. The result is capped at 95%: no profile is shown as a perfect match. The model never sees or sets the total.
- Sign. The result travels in a signed envelope, so the Q&A explains the same score you see and a tampered score is rejected.
Decisions made by measurement
Which model maps requirements to evidence
Thirty requirement rows with an unambiguous right answer were labelled, and four models were run on the same six cases. The labels were drafted with AI assistance and are pending owner review.
| Model | Rows correct | Median time | Cost per assessment |
|---|---|---|---|
| anthropic/claude-haiku-5.5 | 21 / 30 | 9.7 s | US$0.004 |
| openai/gpt-6.1-terra | 26 / 30 | 11.0 s | US$0.018 |
| anthropic/claude-sonnet-5.5 | 29 / 30 | 10.8 s | US$0.052 |
| google/gemini-4-hydrogen | 30 / 30 | 17.2 s | US$0.053 |
The cheapest model hedged: it called clear matches and clear misses "partial" alike. Claude Sonnet 5.5 was chosen for mapping. Gemini 4 Hydrogen scored one row higher but took about six seconds longer, and one row in thirty is within noise. The cheap model still does extraction and Q&A, where it is good enough.
Whether this site needs a vector database
With only 30 evidence records at the time of the test, everything fit in one prompt. So the vector search was tested against simply sending all records.
| Retrieval | Rows correct | Cases in expected band | Cost per assessment |
|---|---|---|---|
| Pinecone top 4 | 29 / 30 | 4 / 6 | US$0.052 |
| Pinecone top 8 | 29 / 30 | 6 / 6 | US$0.061 |
| No vector search (all 30 records) | 30 / 30 | 6 / 6 | US$0.083 |
Honest answer: at that size, no. Sending everything was at least as accurate. Retrieving only four records per requirement was worse, because relevant evidence was left out and strong matches were under-scored. Eight records per requirement matched the no-search accuracy at about a quarter less cost, so the fit check first shipped with search.
That decision was reversed after real use. The owner reported requirements scored "partial" although several records, read together, plainly covered them: a search per requirement returns the closest records, not the full picture, and results varied from run to run. The fit check now reads the whole approved profile (67 records) with a capability map, and its instructions were rewritten to judge each requirement at the level it asks for. Across benchmark runs since, between 18 of 21 and 20 of 22 cases fell in the expected band (16 of 20 before) and all but one or two labelled rows were right (29 of 30 before), with unrelated roles still scoring near zero. Results vary a little from run to run; the evaluation page shows the latest. It costs about twice as much per assessment. The vector index still serves the Q&A and the video guide, where a single question needs a few records quickly.
Single runs on six benchmark cases (01, 02, 03, 09, 14, 15). Small sample: differences of one or two rows are within noise. Extraction model was anthropic/claude-haiku-5.5 in every run.
What it costs and how fast it is
- Mean model cost per fit assessment: US$0.147 (full benchmark, 22 cases).
- Median time per assessment: 10.7 s; 95th percentile 13.1 s. The target was 8 seconds median. It is not met yet; extraction and mapping each take about five seconds.
- A Q&A answer took about 2 seconds and cost about US$0.0003 in a five-question spot check.
- Building and tuning this, including every comparison above, used under US$5 of model spend.
Guardrails
- Only owner-approved evidence records reach the models. Drafts are excluded at build time.
- The AI knows more than the page shows: 28 of the 67 records are answer-only detail, such as location, availability and the story behind a project. They are approved for visitors in the same way; they are just not laid out on the page.
- Model output must match a strict schema. One retry, then a safe failure. Never a guessed score.
- Location, visa, availability and certification are listed separately and never scored. Only a dedicated approved fact settles one; without such a fact it stays "unknown".
- The Q&A and the video guide talk about Karthick and his field only. The model first classifies each question; anything off topic gets a refusal written in code, so the model's own words are never spoken for it. Contact questions and "not in the profile" answers are also fixed wording that points to the resume and the contact links. The guide works in English only for now: a question in another language gets a fixed notice, checked in code.
- Requests go only to model providers that do not retain or train on prompts, as enforced by the routing setting.
- The AI features are limited by IP country to visitors in GCC countries, India and the United States. That is visitor filtering, not data residency: text you submit is processed by vendors outside the region. A VPN bypasses it.
- Server logs hold a request ID, endpoint, outcome and duration. Not your text.
- Each AI feature has a daily limit per visitor and for the whole site, counted against a one-day hash of the visitor's address. The address itself is never stored.
Options rejected
- An orchestration framework. Three direct, typed model calls are easier to test and audit.
- A third-party tracing service. The trace shown under each result is produced by the site's own code.
- Letting the model write the score, generate page layout, or draft plans in Karthick's name.
- Skill bars and percentages for individual skills. They cannot be evidenced.
Known limits
- Speed is above target, as stated above.
- The benchmark is small and synthetic, and its expected answers are pending owner review. See theevaluation results for the cases that miss.
- The figure check catches invented numbers and citations. It does not judge every sentence.
- The video guide is a pilot with a stock presenter, not Karthick's own face or voice, and each session is short.
- Daily limits per visitor and for the whole site are approximate counters, not exact ones. The spending limits set with each vendor are the hard stop.
- The visual design is provisional.
Stack
Astro with a Svelte island and Tailwind CSS; TypeScript throughout; Zod for every contract; serverless functions on Netlify; models through OpenRouter; Pinecone for Q&A retrieval with hosted embeddings; no application database. Unit and browser tests, type checks, a secret scan and a production build run on every push.