Blog |

A Course Map Where the Arrows Have to Explain Themselves

Thu, 15 Oct 2026 00:00:00 +0000

Putting two ideas next to each other on a map says they are related. It does not explain what connects them. My asks more of an arrow: what claim is it making, which assumption does it need, and where in the course material can I check it?

The package’s sample graph gives a compact example. A partial order can leave some pairs of items unranked relative to one another. Requiring every pair to be comparable gives a total order. Writing that condition on the connection makes the change visible. It is the kind of detail that can disappear when a map is just a collection of terms joined by lines.

By the October 15 checkpoint, the contained 104 concepts and 159 connections across eight sections of graduate microeconomics. Selecting a concept opens its explanation and mathematical statement; selecting a connection exposes the claim and its conditions. Section filters and alternative layouts help narrow the view when the whole map becomes crowded. The counts describe its scale, not how much of the course I have mastered.

The map grows out of the same foundation as the : converted textbooks, lecture notes, assignments, and passages found through the . A guide develops an explanation in sequence. The graph gives me another way to explore the material by following what an idea depends on and what it helps establish. They are separate uses of the collection; generating one does not automatically create the other.

There is also a useful division of labor behind the graph. Code prepares task cards containing source passages. Gemini in Antigravity drafts the explanations and connections, and a submission step checks their structure and references before adding them. The new material stays marked as proposed until a person reviews it. This separates a model’s fluent suggestion from an accepted part of the map.

Those checks have limits. A reference can point to a real passage while the explanation misreads it. The drafting model also critiques its own connections, which makes its generous verdicts worth questioning. Section summaries remain drafts, and the GitHub route for submitting reviewer proposals had not yet been exercised from start to finish at this checkpoint.

What makes the graph promising is the opportunity to ask a precise question at a confusing junction. If I cannot follow an arrow, I can examine the claim, the assumption, and the passage behind it. That gives me a concrete starting point for studying—or for correcting the map itself.

Retrospective account prepared October 16, 2026, covering the October 15 checkpoint. The records the counts and open checks. The live graph and project pages may have changed since.

A Long Study Guide Still Needs to Answer the Right Questions

Fri, 09 Oct 2026 00:00:00 +0000

The first microeconomics run of my study-guide pipeline produced eleven topics of explanations, but missed material needed for one of the assignment questions. It also imported language about statistical tests from an earlier econometrics prompt. A guide can be substantial, well organized, and still leave the reader unprepared for the problem in front of them.

There was a useful advance here as well. The could now assemble a guide from an explicit source plan, expand a chosen topic, and propose revisions for review. I could inspect what it planned to read and decide which edits to keep, instead of asking for a complete rewrite and trying to spot everything that had changed.

That source plan connects the visible study aid to the less visible infrastructure. The prepare textbooks and course notes; the locates passages within them. For a guide, I can name particular sources and sections as well as request a bounded search. Newly discovered passages normally wait for review before drafting.

Revision works on specific changes. It can suggest removing an irrelevant passage, consolidating repeated explanations, correcting a claim, or reorganizing a section. Applying accepted edits creates a revised copy and checks that untouched blocks remain unchanged. It also refuses a review if the guide has changed since the review was prepared. Those checks make edits traceable; mathematical judgment still has to come from examining the content.

The microeconomics run made that distinction concrete. Its audit identified several real issues, but some were recorded as notes rather than supplied with corrections. Accepting a warning did not repair the underlying argument. A later comparison with the assignment found additional errors, including a worked example whose construction could not demonstrate what it claimed. Missing coverage had to be written by hand and checked numerically.

The finished guide became usable through that combination of generated material, reviewed changes, and hand repairs. It also exposed a generalization problem: a prompt built around one statistical topic had carried assumptions into another subject. A more neutral prompt and course-specific relevance settings were follow-up work at this point.

The practical payoff is a guide I can investigate. If a topic is thin, I can examine the source plan. If a paragraph changes, I can inspect the proposed edit. If the guide is meant to prepare me for an assignment, that assignment supplies a final coverage check. Each makes the next revision more focused than simply asking the model for a better guide.

Retrospective account prepared October 16, 2026, covering the October 9 milestone. The and distinguish implemented steps from proposed improvements. Project links include later developments.

Giving the Questions in My Lecture Notes Somewhere to Go

Sun, 04 Oct 2026 00:00:00 +0000

A question in the margin of a lecture note can be the most useful thing on the page—and one of the easiest things to forget. The new question resolver gives those questions a follow-up: it finds the marked questions in transcribed handwriting, searches the course collection, and saves an explanation beside the note. Its first recorded run answered seven questions, with a useful distinction: four had supporting course passages and three did not.

This builds on the handwritten workflow I described in my . Excalidraw automatically saves an SVG image when I save a drawing. The makes the handwriting searchable and marks questions it finds. The resolver is a separate command at this milestone; saving a drawing does not automatically answer everything written on it.

Searching for an answer raises an awkward possibility: the system might find the question itself and treat that as evidence. The resolver excludes the note’s own files when looking for supporting passages. If nothing suitable remains, it can still offer a general explanation, but labels it as not sourced from the course. That label describes the evidence available to the tool; it does not certify the other answers as correct.

Keeping the explanation beside the note matters too. The expanded transcript can be regenerated as the transcription tools improve. Pasting an answer into that generated text would put it at risk of disappearing on the next run. Instead, each question gets an identity, its answer lives in a companion file, and the note carries a link back to it. The original question remains available for comparison.

The first live run covered four microeconomics notes. All seven answers were saved, and file-level search could find the companion files afterward. One spot-checked explanation correctly distinguished a necessary condition from a sufficient one and pointed to the relevant course material. The three answers without course backing stayed visibly labelled. Passage-level search still needed a separate chunking step, so this was not yet a fully connected search workflow.

That last gap is a useful reminder of how the pieces fit together. Transcription makes the question readable; the makes related material findable; the answering tool connects them. Keeping the source trail visible lets me decide which explanation to pursue, which to check, and where the collection itself is missing something.

Retrospective account prepared October 16, 2026, covering the milestone recorded October 4. Implementation began October 3; the records the live run. The transcription and indexer project pages describe later work too.

Tidying Up Academic Hub's Plumbing

Sat, 03 Oct 2026 00:00:00 +0000

Two recent changes to Academic Hub were about making the everyday work easier: keeping notes in sync and finding my way around the software.

I separated large reference files from the handwritten notes that need to sync between devices. Before that, PDFs had slipped into the notes’ saved history, so downloading the notes also brought along old copies of large files. Removing them from that history shrank the notes repository from about 217 MB to 35 MB in the September cleanup. The source documents moved to a separate archive, leaving the tablet to sync the working notes and drawings.

Moving the files also meant preserving their connection to searchable transcripts. The search catalog uses a fingerprint of each source file’s contents, so a renamed or moved PDF can retain its identity. Its recorded location still needs updating, but it does not have to become a new document just because its folder changed.

I also grouped the software tools by what they do: converting documents, finding papers, helping with study, or providing functions the other tools share. That gives me a clearer place to look when I need to change something.

The reorganization was intended to preserve how the tools work. The full automated test suite passed after the move. The describes the sync setup, and the shows how the tools fit together.

Turning Dense Math Notes into Commute Podcasts

Thu, 01 Oct 2026 00:00:00 +0000

I built the to make course notes available away from a screen. Reading a mathematical document aloud requires more than sending its text to a speech engine: formula commands need to become spoken language first. As an illustrative example, E[X] should become “the expected value of X,” not a recital of brackets and formatting commands.

The first complete recording exposed a different problem: it was three hours and 22 minutes long. Generating a valid MP3 had solved file production, but left navigation through a long set of notes unresolved. I changed the output to separate episodes grouped around headings, with an index showing which sections went into each file.

This October 1, 2026 post describes the September development run. The dated update below separates later changes from that result.

Translate the notation before speaking

Simple replacements left too much raw formula syntax behind. A local model could rewrite the notation, but the recorded test on a roughly 122,000-character note took about six hours. The next version sent mathematical passages to cloud models while leaving plain prose alone. Cleanup and speech synthesis stayed local.

The amount of notation determined which model handled each passage. Shorter requests could run concurrently, and a later change let sections share one dispatch queue rather than waiting for each section in turn. That brought preparation of the narration text to 3.8 minutes in the September 9 run.

Separate preparation from production

Speech synthesis took another 19.4 minutes with three local Piper workers. The complete run therefore took 23.2 minutes and produced nine files. Those numbers describe one difficult input, not how long every course’s notes will take.

The episodes targeted 10-20 minutes, but one section with no internal headings became an episode of about 62 minutes. The result was not nine uniformly short recordings. It also did not establish whether listening would help me understand or retain the material; that needs listening and content review, beyond generating files.

Regeneration works at the source-file level: the saved state uses a fingerprint of the whole note. Editing any part regenerates all its episodes, while unchanged source files can be skipped.

Update, October 16, 2026: the current code can divide oversized sections at paragraph boundaries, following an October 10 fix. One indivisible paragraph can still exceed the target, and a new listening check is needed to assess the changed output. The saved narration text provides a way to inspect formula rewrites before relying on the audio. The covers output locations, textbook behavior, and the remaining limits.

An AI Tutor That Gives Hints and Checks Your Reasoning

Tue, 29 Sep 2026 00:00:00 +0000

An AI assistant can produce a complete solution quickly. That is not always what a student needs. When I am stuck, a useful hint can help me make progress while leaving the reasoning in my hands.

I built the to support that kind of study. It uses course materials to suggest a direction and can compare a student’s reasoning with a reference explanation. For a second check, a separate solver gets the question without the tutor’s earlier answer or the source passages used to build it.

The hint feature aims to point toward a useful idea without giving away the conclusion. For a claim that is meant to hold in every case, an illustrative hint could be: “Try the simplest case you can think of. Which assumption does your argument use?” That gives me something to test while leaving the reasoning to me.

That fresh view gives the second solver a chance to spot a missing assumption instead of following the same argument. In one recorded coursework trial, it identified a condition about the regression model that the first response had omitted.

When I share an attempt, the draft check gives separate scores for whether the conclusion is right, whether each step is justified, and whether it uses the course’s definitions and methods. A correct result with a gap in the proof needs different feedback from an otherwise sound argument that uses unfamiliar notation. If the source material does not cover a point, the tutor should make that gap clear.

I still have to examine the arguments; agreement between two answers does not settle whether they are right. The describes the recorded tests, limits, and ongoing development.

Why I Use Obsidian and Excalidraw for Academic Notes

Thu, 24 Sep 2026 00:00:00 +0000

I take many of my academic notes by hand. Diagrams, equations, and quick annotations are often easier to draw than type, but handwritten pages are hard to search and connect to related material later.

I use Obsidian, a notes app, with Excalidraw, a drawing tool that lets me write and sketch inside it. Saving a note automatically creates an SVG image of the drawing. My Notes Transcription Pipeline reads those images and turns the handwriting into text that can be searched alongside my other course materials.

OneNote and GoodNotes made writing feel natural, but their file-type limits got in the way of my processing workflow. This setup keeps my handwritten work alongside lecture slides, textbooks, and other course materials, with links between related notes.

Customization was another major reason to choose this setup. I can edit the source code for Obsidian plugins, which let me add an eraser button and translate a pen-tool menu. When the tablet’s gesture bar covered the zoom and undo controls, I changed the interface styles to move them within reach. Being able to fix those details myself was an advantage over my experience with OneNote.

I keep large reference files out of the notes sync so the tablet only needs to download the working notes and drawings. Some plugin settings and customizations still need to be copied or enabled by hand.

A lecture can leave me with two versions of a drawing: the notes I wrote in class, and a later copy with the lecture slides pasted beside them. Once transcribed, the search tools can recognize some of those pairs and avoid showing both copies when the more complete version is available. Both originals remain editable.

Matching whole notes by subject matter proved too broad: separate lectures on similar topics could look like duplicate versions. Comparing short sequences of words in the handwritten portions gave a cleaner distinction in the tested microeconomics notes. The useful signal was whether the same writing appeared in both versions.

That connection is what makes the setup useful to me. I can keep writing by hand while making the notes easier to find and revisit later. The transcription tools make the saved drawings searchable, and the sync setup occasionally needs attention.

Updated October 15, 2026, to include the related-note matching added after this post was first written.

For the sync setup, transcription steps, and current matching limits, see the , , and project pages.

Making Textbook Conversion Easier to Run in Batches

Tue, 22 Sep 2026 00:00:00 +0000

Converting a set of textbooks used to require someone nearby to answer repeated prompts and step in when a book exceeded the available machine memory. Recent changes to aim to make batch runs easier to supervise.

The same textbook PDF might appear in the reading folders for two courses. If it has already been converted for one, the tool can reuse that output for the other. A fingerprint of the file’s contents recognizes an exact duplicate even if someone has renamed it.

Very close title-and-author matches can also be reused and logged for later confirmation; less certain matches need a decision first. This policy reflects a cost tradeoff: mistaken reuse can be reversed, while rented GPU time spent converting a duplicate is already gone. Review remains important, but every likely duplicate need not interrupt the batch.

The recovery procedure first checks whether a failed conversion ran out of memory. If that is the cause, the next steps are to reset and retry on the current machine, then try a larger one if the failure repeats. If that also fails, it calls for help. The run record preserves what has already been tried.

The person or coding agent running the conversion follows that procedure. Automated tests cover the supporting code, while reliability across large batches still needs observation. The describes what has been tested, the cost checks, and the remaining work.

Finding Academic Papers for a Research Library

Sat, 12 Sep 2026 00:00:00 +0000

Starting a literature review often means finding candidate papers, deciding which ones matter, and tracking down the full text. I built the to help organize those steps and add selected papers to a searchable research library.

The tool starts with a researcher or a topic, then finds candidate papers through OpenAlex, a catalog of academic publications. A model on my computer turns my research description and candidate abstracts into text embeddings: numerical representations used to compare meaning. Comparing those representations gives each candidate a relevance score before any download begins. This scoring stage makes no paid AI calls.

The library can also become a starting point for discovery. The tool follows citations forward to find newer papers that cite work I’ve already collected, scores those candidates, and proposes a reading list. I review that list before anything is downloaded.

For full text, the tool tries several services for freely available copies in turn, so one service missing a paper does not end the search. It can also try my university’s library access where that is available. If those routes fail, the paper goes on a list for me to open through my usual library login. In an early trial, the automatic route obtained 3 of 19 papers; the rest needed a person to retrieve them.

After the papers are available, separate conversion and search tools add their text to the research library. I can then search the papers alongside course materials, with access to more than their abstracts.

Update, October 15, 2026: A later trial searched for papers about disaster resilience, response, and recovery. Fifteen candidates passed the relevance filter, and a review found all fifteen on topic. Seven downloaded automatically; the other eight were left for manual access. That is a useful distinction in practice: finding a relevant paper and obtaining its full text are separate steps.

The describes the search sources, results, and remaining work.

The Resume Step That Became Faster When I Removed the AI

Wed, 09 Sep 2026 00:00:00 +0000

The first structured import of my resume took over 90 minutes and still mixed up parts of the record. Replacing the model that organized the extracted text with ordinary parsing code brought that step down to about 1.5 seconds in the recorded run. The larger improvement was having explicit rules for where each fact belonged.

The is meant to help tailor applications without losing track of the experience behind them. It keeps a master record, uses a job description to guide the emphasis of a draft, and renders the result as a PDF. Before any of that can work, the master has to represent the source resume faithfully.

An early version let the model write the master as free-form text. My source resume groups several roles under one employer, with a date range attached to the employer rather than every individual role. The model filled some missing date positions with locations. The result looked organized, but the meaning of a field had quietly changed.

Giving every fact a named field helped. Employer, role, location, and dates no longer had to compete for the same space in a heading. Yet asking the local model to populate that structure introduced another set of problems: malformed output, joined lines that failed literal checks, and content that still landed in the wrong place. Fixing the formatting was not enough to establish that the record was right.

The source had more regularity than the model-based approach was using. Section headings, date patterns, and the arrangement of roles supplied practical rules for a parser. The revised importer uses those rules to turn extracted PDF text into a structured master without a model call. That is the step behind the 1.5-second result; it is not the time to tailor and render a complete application, nor a benchmark across arbitrary resume layouts.

Language generation still has a useful job later. A model can suggest which experience to emphasize and how to phrase a bullet for a particular opportunity. The surrounding code copies fixed fields from the master instead of asking the model to reproduce them. Bullet wording still needs review: preserving a date or a number does not establish that every implication of a rewritten sentence is faithful.

This small project shares a concern with the academic tools: preserve a dependable source record, then make the interpretation easy to inspect. Here, the most effective change was recognizing which part of the job already had enough structure for code to do it directly.

Retrospective account prepared October 16, 2026, covering the September 9 milestone. The and document the sequence. The project page includes later developments.

A Practice Problem Can Have the Right Answer and Still Miss the Point

Sun, 06 Sep 2026 00:00:00 +0000

One early test of my practice-problem generator produced a flawed proof, then marked its own work valid. Another ignored the requested proof method. For a study tool, both matter: an exercise can reach the expected conclusion without helping me practice what I need to learn.

The idea behind the is appealing. Instead of asking for a generic exercise, it searches my course materials for examples of the topic, style, and difficulty, then drafts a new problem and a worked solution. The supplies those examples. A second model call checks the result before it reaches me.

That second call was less reassuring than it looked. In the linear algebra trial, the solution treated certain eigenspaces as perpendicular without having the assumptions that would justify it. It also relied on part of the conclusion it was supposed to establish. The checker accepted it anyway. Asking the same small model to read its answer again had not supplied the missing mathematical judgment.

The method problem was easier to isolate. When a request specified a particular kind of proof, the generator kept imitating a different approach in the retrieved examples. Emphasizing the instruction more strongly did not reliably change that behavior. Splitting the verdict into two questions—whether the method matched and whether the mathematics was correct—at least made it possible to reject an answer that passed only one test.

A small comparison then changed the outlook. A cloud-model experiment used the same prompt-building and checking functions on three topics, with three trials each. All nine passed the checks and a hand review found their mathematics sound. The local model had produced no accepted result in two trials of the constrained compactness request. These were different-sized samples on different topic sets, so they are evidence for a useful next experiment, rather than a general model ranking.

Even those nine successes had qualifications. Some proofs used the requested method in a rather superficial way, and two probability problems were almost identical. Correctness, useful practice, and variety remain separate goals. The comparison was also a standalone experiment at this point, not evidence that the cloud route had already been integrated into the tool.

A useful next trial would ask for several different exercises on the same skill, then check both their proofs and whether they demand meaningfully different reasoning. The near-duplicate probability problems show why a string of valid verdicts cannot answer that question.

Retrospective account prepared October 16, 2026, covering the September 6 milestone. The preserves the trials and their limitations. Project links describe the tools as they have developed since.

Indexing and Querying Academic Hub

Sun, 30 Aug 2026 00:00:00 +0000

Once books and notes have been converted to text, the next challenge is finding the right material and showing where an answer came from. The organizes the documents; searches their passages to help answer questions.

The indexer creates a record for each document and groups related material by course. Search first narrows the collection to likely courses and documents, then ranks passages within them. A book can be relevant to a topic overall while only a few paragraphs contain the explanation a question needs.

The answering tool also limits how many passages each file can contribute. That helps keep one highly relevant textbook from crowding lecture notes and other sources out of the material used to write the answer.

In a recorded trial, it combined passages from two sources to answer a question about the spectral theorem, with references back to the material it used. When the collection does not support an answer, the system is intended to make that gap visible instead of dressing up a guess as a sourced result.

An illustrative source reference is Section 7.4, pages 264–266. That tells me which part of a source to open when I want to check an explanation or read further. A reference makes the reasoning easier to inspect; it does not guarantee that the answer interpreted the passage correctly.

This was an early milestone in the project. Since then, the work has expanded to include tutoring hints, answer checking, and more links between related notes. The project pages describe the current behavior, testing, and limitations; this update records the initial step from converted documents to searchable, referenced answers.

Converting Academic Resources to Markdown

Tue, 25 Aug 2026 00:00:00 +0000

The turn books and class documents into text that can be searched alongside my notes. Textbooks and handwritten or mixed-format documents need different approaches, so the project now has a tool for each.

For textbooks, the converter now uses chapter boundaries where possible and records printed page numbers as well as PDF pages. In a four-book check, it avoided duplicate section markers and recovered printed page numbers on 96–98% of pages. A separate pass added descriptions to 764 of 793 candidate figures across five books, skipping the ones judged decorative.

Those page references help me compare a passage with the original textbook, even when the PDF’s page count differs from the numbers printed on the pages. Figure descriptions also make some of the information in diagrams available as searchable text. Both are useful when I need to return to a source and check what it actually says.

Shorter documents such as exams and handwritten notes need a different path. The checks whether ordinary text extraction is sufficient and uses AI to transcribe the harder pages. The work also uncovered problems that a plain text dump can hide: dropped spaces, lost superscripts, and a square-root symbol read as the letter p.

Some notation could be recovered by looking at the page layout more closely. The extractor uses character size and vertical position to reconstruct superscripts and subscripts. That lets it recover some mathematical structure locally before paying for AI transcription.

Update, October 15, 2026: A later run repaired that particular square-root error after comparing it with the source page image. That closes the specific example; other extracted text still needs review.

The records the checks behind these results, their limits, and the ongoing work.

Managing this site with HugoBlox and Claude

Wed, 19 Aug 2026 00:00:00 +0000

Each page on this site starts as a text file. Hugo turns those files into web pages, and HugoBlox supplies the “Academic CV” template for their appearance. I write in Markdown, a simple format for marking headings, links, and other formatting within the text.

Lately I’ve been doing much of the editing with Claude Code, a coding assistant that works directly with the site’s files. It can add a project page, change the navigation, or adjust a layout. I can inspect the exact changes before accepting them.

The template arrives through Hugo modules, reusable packages loaded when the site builds. Small local additions, such as support for GitHub buttons, can extend it without copying the whole theme into this repository. That gives the assistant a useful boundary: the site’s content and customizations live here, while the shared template stays in its own packages.

Recent edits included bringing the main sections together on one scrolling homepage and adding pages for and , two tools in Academic Hub. I also left the template’s unused example pages unpublished, so they are available if I want to return to them.

When I’m ready to publish, I send the reviewed changes to GitHub, where the site’s source files are stored. An automated workflow rebuilds the pages and updates the public site. The saved history lets me see what changed and revisit an earlier version if needed.

That suits how I want to maintain a personal site: edit the content, review it, and let the template and publishing tools handle most of the web-development work.

Introducing Academic Hub

Tue, 18 Aug 2026 00:00:00 +0000

Like any knowledge intensive task, taking a graduate course combines multiple sources of information in various formats: textbooks, lecture notes, presentation slides, problem sets, Youtube video explainers, old exams, and relevant research papers. The standard approach to combining these materials is haphazard, with relevant info spread across each category and only loosely connected by topic–any given section of a syllabus might connect to half a dozen textbook chapters, meaning students spend a lot of time just finding the right source. If a topic depends on pre-requisite knowledge which the student is unfamiliar with (a common issue in my PhD program so far), looking back through foundational textbooks for the right content takes longer than learning the idea. When it comes time for exam review, notes are only loosely connected to problem sets and lecture slides, and none of these are linked to practice problems or prior exams. In short, students spend far too much time categorizing and retrieving relevant information, distracting from higher value learning processes, shifting pedagogical focus from the actual ideas to the mechanics of how different authors organize and refer to those ideas.

My solution for my own coursework was the . If all my materials could be converted to the same plain-text format, then organizing them into a searchable database with relevant categories and connections would be an easy task for any language model. As I developed methods to convert a larger variety of information sources, the potential applications for learning became more and more useful: from that automatically answers my handwritten sidebar questions from lecture to more relevant study guides and , tailored to the specific topics which came up often in past exams, and even multi-round that can help break down complex problems without revealing solutions.

Most of these applications could be replicated with a standard online AI model, but the default agents lacked the context of my specific courses. Retrieval-augmented generation (RAG) models that can train on or incorporate specific files to produce more relevant answers are available, but dropping whole PDFs into a system like a Gemini Notebook is very token expensive, they waste most of their compute just processing inputs. By front-loading the transcription and indexing process, then standardizing it across my courses, I can run any type of LLM agent (subscription based, local, or API) and get highly relevant results based on my exact materials, with citations to source context, at a fraction of the cost. The more source materials I included, the more summaries and problem sets I generated, the better the collection becomes; by the end of the semester, I could just say “looking back at my previous notes and homeworks, help me review this section” and I could create much more useful review materials with far less effort.

Converted materials provide a shared source collection for several study tools; their outputs still need review.

The Academic Hub pipeline is completely reproducible too. Each step is modular, so when I found that my initial transcription approach (using Gemini API credits) was becoming too costly, I was able to switch out specific steps with a subscription-based model (or a local GPU-based model). Applying the entire range of tools to a new course is as simple as dropping in a folder of old notes, slides, and problem sets. Courses can build on each other, so if a topic from Microeconomics I comes up again in Micro II, all of my previous notes can be used to inform the new questions and help me review. Once large PDFs are converted to markdown text files, the storage requirements are minimal–I can to my tablet via GitHub and Obsidian.

While I built it to help study for courses, the processes involved can be applied to any type of knowledge base, from research papers to government reports. I’ve already started expanding the pipeline to academic research, to automate literature reviews and create a structured database of international development interventions and outcomes. I’m eager to expand the features for both and start applying them at a larger scale, including user testing to see if the tools are accessible to those without extensive backgrounds in computing, AI, or knowledge management.

If you have an interesting use case you’d like to try, or just want to discuss the development process, please reach out to me by email at or . All of the code backing up the Academic Hub is available as part of my larger AI-Sandbox project and each subproject has more details in the . I welcome any questions or feedback as I continue to develop this project!