Handwritten-style study notes that notice when their source data is outdated, and say so.
2re-checks per run
Each re-check fetches the source page, and with an AI key also makes one AI request. A smaller budget saves requests but leaves more notes flagged for you to verify.
Without a key, notes are the first sentences of the page and re-checks use a plain text match. The key is only sent to Google and is never stored in this file.
Live mode uses Wikipedia page revisions as a stand-in for textbook or knowledge-graph version changes.
Try:
0
Topics checked
0
Notes updated
0
Need verification
0
AI verification requests
Your notes, with freshness check
Each topic shows how fresh it is and why. Open "Why this status?" for the details.
The old way
Trusts the graph as it is. No checks, no warnings.
Cost versus freshness
Same topics, different verification budgets. The numbers are computed by running the real check at each budget.
Budget
Re-checks used
Updated
Re-checked, no change
Flagged for manual check
Result
updatedre-checked, no changeflagged for manual check
About this prototype: how it works, trade-offs and limits
The problem
Notes come from a knowledge graph that can lag behind the real source. If a page or textbook changes and the graph does not, students get wrong notes without knowing it.
What it does
Age score (free). Each topic has a speed of change. The older the notes, the higher the risk, and fast topics age quicker.
Version check (one cheap request for all topics). The revision the notes were made from is compared with the current revision of the source. A different one means the notes are outdated for sure.
Limited re-check. Only the riskiest topics are re-checked, riskiest first, up to the verification budget. The page text is compared with the notes (by Gemini if you add a key, otherwise by a plain text match) and notes that no longer match are rewritten.
Honest warnings. If a risky topic cannot be checked (budget used up, source unreachable, page missing), the old notes are shown with a warning and the reason. Nothing is silently trusted.
Low-risk topics skip all of this, so normal topics behave exactly as before and cost nothing extra.
Stand-in for textbook versions
This prototype uses Wikipedia page revisions as a stand-in for textbook or knowledge-graph version changes. In a real StudyMate the "latest version" would come from the textbook publisher or the graph's own change feed. Only the source lookup would change, not the risk logic.
Real versus simulated
Sample demo: short made-up texts, simulated source and simulated checks. No network and no AI.
My topics (live): real Wikipedia lookups. Re-checks use Gemini if you add a key, otherwise a plain text match. The "AI verification requests" card counts only real Gemini requests.
Simulate stale (demo) button: replaces a topic's saved notes with an outdated placeholder and an older revision, so you can watch the check work. The staleness is simulated and labelled as such. The correction itself comes from the real, current page.
Trade-offs
More re-checks mean better accuracy but more cost (a page fetch plus an AI call, which matters on free limits). Fewer re-checks are cheaper but leave more notes flagged for manual verification. The thresholds (25% and 60%) and the half-lives are my own guesses and would need tuning on real data.
Limits
A new revision does not always mean the facts changed (it may be a typo fix), so some updates are unnecessary.
The AI can make mistakes. Notes are only as good as the source page, and only the intro of a Wikipedia page is used.
A silent edit with no new revision is only caught by the age score.
The check does not write refreshed notes back to the saved graph. They are re-derived on each run (results are cached for ten minutes to save requests).
If the source lookup fails, version checks are skipped and every topic is judged by age only. The page says so.
Hackathon prototype. Your topics and key stay in your browser.