DEV Community: CodersAcademy006

Every repository is haunted

CodersAcademy006 — Sat, 31 Oct 2026 08:58:47 +0000

There is a file in vLLM that imports a module which does not exist.

# tests/plugins/vllm_add_dummy_platform/vllm_add_dummy_platform/dummy_attention_backend.py
from vllm.attention.backends.placeholder_attn import PlaceholderAttentionBackend

On upstream main at 900b8b08e2, checked today:
vllm/attention/backends/placeholder_attn.py was deleted on 24 September 2025,
in commit 969b4da3a6, titled "[V0 Deprecation] Remove placeholder attn (#25510)".
PlaceholderAttentionBackend is defined nowhere in the repository today. That
line has been importing a module that does not exist for thirteen months.

Being careful about what that does and does not mean, because I checked and my
first guess was wrong. The file is not orphaned: dummy_platform.py:32 names
vllm_add_dummy_platform.dummy_attention_backend.DummyAttentionBackend as a
string that vLLM resolves at runtime, and the plugin is pip-installed in a two
GPU CI job. My first instinct was to say this must break that job. Then I looked:
forty one commits have touched the paths that trigger it since the deletion, the
most recent in September, and the line is still there. So either that code path
is never reached or the job does not gate anything, and I cannot tell which
without two L4s.

What I can tell you, from reading alone, is that the reference is dead. That is
the claim this tool makes, and it is the only claim it makes.

I did not find it by reading vLLM. I found it by asking a repository who it
still talks to, and listening for the answers that nobody is there to give.

Ghost in the Machine

The theme this week is spooky, or honouring the past. I went for both, because
the thing I wanted to build only works if you take the haunting seriously.

Every repository is built on top of its own dead. Files get deleted, and the
deletion is clean in the only place anyone checks, which is the directory
listing. What does not get cleaned is everything that was pointing at the file:
the import that resolves to nothing, the CI script that still invokes a test
that was removed, the docstring that says "see this other module" about a module
that was buried two years ago. Those references survive. They say a name, and
nothing answers.

So: ouija finds them, and ofrenda builds them an altar.

Live: https://codersacademy006.github.io/ouija/

What counts as a ghost

The whole tool is one claim, and I wanted the claim to be the kind that can be
proven wrong:

This exact file is gone. Nothing replaced it. Something still says its name.

Getting from the idea to something that survives contact with a real repository
was almost entirely a process of deleting my own false positives. Six of them,
in the order they embarrassed me:

It was renamed. moved_module.py disappears from the directory, so git calls
it a deletion. A file with that basename exists one folder over. Not dead.

It became a package. tracing.py is deleted and tracing/__init__.py appears.
Every from vllm.tracing import ... still works perfectly. My first run reported
this as a ghost with 29 live references, and the top five results in vLLM were
all the same mistake wearing different names.

The name is a substring. My first version matched symbol names, so a deleted
ir/value.h matched the text value.handle in a test file, and size_t was
confidently declared dead across the whole of Triton. A reference only counts if
the characters either side of it are not more path.

It is a bulk list. TensorRT-LLM reported 234 proven ghosts, more than
every other repository in the corpus put together. Four files produced 232 of
them: legacy-files.txt, ruff-legacy.toml, pyproject.toml and
.pre-commit-config.yaml, each enumerating the same long inventory of paths for
tooling to skip. That inventory being full of files that no longer exist is one
piece of stale config. Calling it 232 separate hauntings would be inflating a
headline on purpose. A living file that names ten or more distinct dead files is
a list of them, not a reference to any one of them, and its mentions stopped
counting. That repository has 31.

It is a changelog. This one was subtler. My first full corpus run reported
77 ghosts in a single repository, more than every other repository combined.
All 77 came from docs/daily-updates/2026-04-*.mdx, a dated log that lists the
pull requests merged each day. A changelog naming a file it deleted is doing
exactly its job. That is a memory, not a haunting. Once dated and archival
documents stopped counting, that repository had four.

It is a redirect. vLLM's mkdocs.yaml has a line reading
training/routed_experts_replay.md: training/routed_experts.md. The file on the
left is gone, which is the whole point: the line is the redirect that sends
anyone following an old link to the page that replaced it. That is a deletion
handled properly, and my tool was reading it as a deletion forgotten. A line
that names both a dead file and a living one is pointing at the replacement.

It is a module path that means something else. The worst one, and the last
to go. A python file's import path is a strong signal, so I was also matching
the last two components of it. TensorRT-LLM deleted
.../modeling_v2/catalog/torch/empty.py, whose last two components are
torch.empty. That repository was reported as having twenty three dangling
references to it, every one of them a line that allocates a tensor. A module path
now has to be the file's whole path from the repository root, and has to appear
in an import or quoted in prose rather than called.

I kept the evidence tiering rather than hiding the weak cases. If the surviving
reference carries two or more path segments, or the file's full import path used
as an import path, it can only mean this file, and it is reported as proven.
If only the bare filename survives it is suspected, listed separately, and
never folded into a headline number, because a bare image_processor.py in a
docstring is as likely to be talking about somebody else's file as about this
repository's.

What it found

repository	proven	suspected	files buried	deletions read
`TensorRT-LLM`	31	6	319	696
`vllm`	9	4	1093	1799
`llama.cpp`	7	0	586	773
`pytorch`	6	1	163	578
`cutlass`	5	6	1630	1875
`opensre`	3	5	655	1687
`TensorRT`	3	2	622	924
`triton`	2	3	584	916
`numba-cuda`	2	0	31	49
`automodel`	1	3	99	458
`graphify`	0	2	23	43
`TransformerEngine`	0	1	87	208
`flash-attention`	0	1	365	422

29 distinct projects, 19 of them with any deletion history at all. 69 proven
ghosts and 34 suspected, out of 6391 files buried for good across 10671
deletions. 6 projects came back clean.

The sweep ran against local clones. For any repository where my checkout carries
my own branches, the numbers above come from a throwaway worktree at that
project's upstream default branch instead, so every line quoted below is one
anybody can go and read.

Browse the altar

Three worth reading:

vLLM. The dead import at the top of this post.

TensorRT-LLM, and a correction I had to make to myself. My clone of it sits
on an older branch of my own, and there the tool found three example scripts
opening with from tensorrt_llm.builder import Builder against a deleted
module. A good finding, except that upstream had already deleted those example
scripts too. They were ghosts in my checkout, not in the project.

What is still there on upstream main at 6adeccc026 is quieter and I like it
more. Line 42 of .github/CODEOWNERS:

/tensorrt_llm/builder.py @NVIDIA/trt-llm-devs

A rule routing review of a file that does not exist. Two live files also carry
the comment # Modified from tensorrt_llm/builder.py _init_max_seq_len, which
is now a pointer to nothing.

Triton, on upstream main at 0861b90f69. .pre-commit-config.yaml still
defines a hook that regenerates .github/workflows/integration-tests.yml from
an .in file. Both the workflow and the .in file were deleted in April 2025,
in "[REPO] modularize worklfows (#6582)". The hook is still in the config, and
it survives precisely because it is broken: its files: pattern can never
match, so it never runs, so it never fails.

The model writes prose, and nothing else

Each ghost gets a two-sentence epitaph from gemma3:4b, running locally through
Ollama. Every path, date, commit hash, line number and count on the page is read
from git by the detector. The model never sees a number.

That was not the original design. It is the result of catching it lying.

The first prompt included the burial date. gemma3:4b took a file buried on the
eighteenth of June and eulogised it as having vanished "on the sixth of June". It
had not been asked to mention a date at all. The fix was not a better
instruction. The fix was taking the date out of the prompt, so there was nothing
left for it to get wrong. It now receives the commit subject with the digits
stripped out, the kinds of files that still mention the dead one, and nothing
else.

Two guards survive on every epitaph: no digits, and no month or weekday names,
since it is never given a date. Across the whole published site, 46 epitaphs
were requested and one tripped a guard. It is printed on the page, flagged
in red, next to the epitaph that broke the rule. Regenerating it quietly until
it behaved would have made the page prettier and the claim worthless.

A small model given one prompt repeats itself

The first batch of epitaphs was unusable for a different reason. Eight ghosts,
eight calls, and five of them opened with the words "It rests here". Measured
properly, eight epitaphs produced 3 distinct openings.

The fix is one line of prompt. There are eight opening instructions, and each
ghost gets one chosen by hashing its file path, so a given file always receives
the same instruction and the output stays reproducible. Same model, same
temperature, same everything else:

	distinct openings
one prompt for every ghost	3 of 8
rotated opening instruction	7 of 8

bench_angles.py runs both arms back to back and writes every raw epitaph to
bench_angles.json, so the table above can be checked rather than believed.

Sweeping a whole laptop without losing the sweep

Fifty clones on one laptop, twenty nine distinct projects, is a long job, and
ray alone (thirty one thousand commits, seven and a half thousand deleted
files) takes a larger share of it than everything else put together. The first
version was a shell loop, and I killed it twice to fix detection bugs. Both
times I threw away everything it had already done, including a very expensive
ray.

So the corpus run is a Temporal workflow. One repository
is one activity. Temporal records each completed activity in the workflow
history, so a worker that dies is replaced by one that replays the history and
continues from where the last one stopped.

That is a claim worth testing rather than asserting, so durability_test.sh
does it: it waits for the sweep to get going, sends the worker SIGKILL with no
chance to save anything, starts a fresh one, and checks the finished count only
ever goes up.

before kill:      8 repositories finished
SIGKILL sent to worker pid 11807 at 07:00:12
with no worker:   query unanswerable (), workflow state is on the server
new worker:       pid 12098
after restart:    10 repositories finished
RESULT: resumed at repository 9, the first 8 were not scanned again

While the worker is dead, the progress query comes back
no poller seen for task queue recently, worker may be down. The work is not in
the worker. The worker is just the thing holding the shovel.

Building that found a real bug of my own. The activity declared a five minute
heartbeat timeout and never sent a heartbeat, so any repository slower than five
minutes would be abandoned and retried until the workflow failed. ray is very
much slower than five minutes.

Why open matters here

This tool reads your git history. Not your public repositories, your real ones:
the private monorepo, the client work, the thing you have not shipped yet. It
walks the whole deletion record, pulls the last living version of every buried
file, and greps the entire working tree.

Sending all of that to a hosted API so a model can write a nice sentence about
ghosts would be an absurd trade. The valuable half of this tool, the detection,
has no model in it at all. It is git and the Python standard library, nothing
installed, nothing to import, no key. --no-model gives you the complete
findings with nothing loaded.

The prose half is 3.3 GB on disk and takes about seven seconds per epitaph on an
M-series laptop with no GPU. It runs on a plane. That is the whole point: the
part that touches your source never leaves the machine, and the part that writes
is small enough to come with you.

That cuts both ways, and it caught me out. I built the site, went to push it,
and my own tooling refused on the grounds that I was about to publish private
data. It was right. The pages quote real paths and real lines, and the sweep had
read repositories that are nobody's business but mine. Worse, a file listing
every project folder on this laptop was already committed.

So publishing has three rules now, each of which fails closed. Only repositories
confirmed public. Never my own clones, because a clone of my own public
repository can still hold a branch I have not pushed. And for a third-party
repository where my checkout carries my branches, scan a throwaway worktree at
upstream's default branch instead of my working copy. Fourteen repositories made
it onto the site. Fifteen did not.

A tool that reads everything has to be careful about what it says out loud, and
that is far easier to get right when the model is on the same machine as the
secrets rather than on the other end of a request.

There is a quieter reason too. A tool about things that outlive their
infrastructure should not itself depend on an endpoint that might be gone in
three years. An ofrenda built on an API that gets deprecated is a joke with a
punchline I did not want to be in.

Run it

git clone https://github.com/CodersAcademy006/ouija
cd ouija

python3 ouija.py /path/to/your/repo              # the findings, no model
python3 ouija.py /path/to/your/repo --json > ghosts.json
python3 ofrenda.py ghosts.json -o ofrenda.html   # epitaphs, needs ollama

Python 3.9+, git, and ollama pull gemma3:4b if you want the altar. No pip
install. There is nothing to install.

python3 test_ouija.py

builds a throwaway repository containing one real ghost and three things that
only look like ghosts, and asserts it finds exactly the one.

What it does not do

It finds dangling references to deleted files. It does not find dangling
references to deleted symbols inside files that still exist, which is the
larger and harder problem, and the one my first version failed at so badly that
it declared size_t dead.

It will not tell you a ghost is harmful. The vLLM import is a real broken import.
The Triton hook is a leftover that cannot fire. A docstring pointing at a
deleted module is just stale. Those are three different severities and the tool
reports all three the same way, because deciding which of them matters in your
repository is not something a filename can tell you.

And it only sees what git saw. A file that was never committed was never buried,
and leaves no ghost.

Every repository that has lived long enough is standing on files it does not
remember deleting. Most of them went quietly. Go and find the ones that did not.

Repo: https://github.com/CodersAcademy006/ouija
Licence: MIT

Built for the Hacktoberfest Open-Source AI Challenge: Week 4, Ghost in the Machine.

Entering Best Use of Gemma, because gemma3:4b writes every epitaph locally
and nothing else writes them, and Best Use of Temporal, because the corpus
sweep is a durable workflow and the kill test above is the receipt.

GraphSloth: auditing 29 abandoned project folders so I don't have to

CodersAcademy006 — Fri, 23 Oct 2026 11:12:42 +0000

GraphSloth: auditing 29 abandoned project folders so I don't have to

Live demo · Source

What I Built

My ~/Desktop/Project folder has 29 project folders in it, about 95GB total. I had no idea which ones were safe to archive and which ones I'd regret deleting. Auditing that by hand is exactly the kind of task International Sloth Day exists for, so I built something to do it instead.

GraphSloth scans a folder of projects and, for each one, pulls real facts: disk size, git commit age, and (for git repos) a real Graphify structural extraction — real tree-sitter AST parsing, zero LLM cost — giving node/edge counts and the most-referenced symbol. A local Gemma model then reads those facts and returns a verdict: ACTIVE, DORMANT, or ARCHIVE-CANDIDATE, with a one-sentence reason that has to cite the actual numbers, not invent anything.

Nothing gets deleted automatically. The output is a static report, and an optional --apply flag only moves archive candidates into a sibling _Archive/ folder, one at a time, asking before every move.

Demo

Real run against my actual Desktop: 29 folders audited, 10 flagged ARCHIVE-CANDIDATE (29.4G reclaimable if I trust them), 16 ACTIVE, 3 DORMANT. 9 of those were flagged with real deploy signals and automatically kept out of the archive pile, including my own live e-commerce store and a production exam-scoring backend.

Caught Lying to Itself

All three of these were found by running GraphSloth on my own live, production folders, not a test suite, and each one got fixed the same day I found it.

A live store flagged safe to archive. Srijan Saree, a real store with real orders, came back as ARCHIVE-CANDIDATE. The deploy-signal check only looked at a folder's top level; the store's actual code and its .vercel config sat one folder down. Fixed by checking one level into subfolders when the top level isn't a git repo itself.

One busy repo almost spoke for 34. OSS, 26.8G holding 34 separate git clones, was one busy clone away from being called ACTIVE as a whole. My first nested-repo fix picked whichever single clone was touched most recently and judged the entire 26.8G folder by it — only 10 of the 34 clones had actually moved in the last 30 days. Fixed by detecting a multi-repo container and reporting the real distribution instead of one point sample, with a hard cap: a container with stale repos among its recent ones is never called ACTIVE.

A raw exception almost shipped as a verdict. A single Ollama timeout, right after a restart, nearly produced a report with the literal text [Gemma call failed after 3 attempts: timed out] sitting in a folder's "reason" field. Turned out the model emits a chain-of-thought before its answer, and a complex fact block pushed that past a 300-second timeout on CPU-only inference. Fixed by passing think: false and capping num_predict — the same call that used to hang indefinitely now returns in single-digit seconds — plus a check that catches and retries that shape of error before anything publishes.

When It Actually Died

Partway through the real run, the OS killed the process. Not a bug in my code — Gemma sits at about 8GB resident in RAM, and my laptop ran low on memory in the background while the audit was running. 27 of 29 folders were already done, but they only existed as text in a log file. I had to write a second script just to parse completed verdicts back out of stderr output.

That's exactly the problem Temporal workflows exist to solve, so I rebuilt the audit loop as one. temporal_audit.py runs the same per-folder audit, but each folder's result is a durable activity instead of a line in a Python list. I proved it, not just claimed it: started a 5-folder run, let 2 finish, kill -9'd the worker process mid-activity, confirmed with temporal workflow describe that the workflow was still alive on the server with its 2 results intact, restarted the worker, and watched it pick up from folder 3 instead of starting over.

(Temporal's workflow code has to be deterministic, so it forbids filesystem and subprocess access in the workflow definition itself. That meant splitting the workflow logic from the activity implementation into two files: ta_workflow.py stays sandboxed and clean, ta_activities.py does the real I/O and is only imported by the worker process.)

The Bug I Almost Shipped

My first version scored folders mostly on git commit age. That's wrong for anything that's deployed and stable: a live backend I rarely need to touch would look just as "stale" as something I actually abandoned a year ago. Several of my own folders are live production services, and under the first version they were one unlucky LLM response away from getting flagged for archiving.

So GraphSloth checks for cheap, local, no-network deploy signals — vercel.json, .vercel, docker-compose.yml, render.yaml, fly.toml, a live URL in the README — before Gemma ever sees the folder, and the result is a hard rule in code, not something I'm hoping the model remembers: a folder with any deploy signal can never come back as ARCHIVE-CANDIDATE. It's capped at DORMANT and shown with a visible warning instead. This isn't proof a service is actually live, so the flag means "check this yourself," never "it's definitely fine."

Why Open Innovation Matters

Zero cost. Graphify's extraction is local tree-sitter parsing with no API key. Gemma runs locally through Ollama. Auditing dozens of gigabytes of my own code costs nothing.
Privacy. Several of these folders are private client work. None of their contents leave my laptop.
Real evidence beats guessing. Most "clean up your projects" advice is pure vibes based on file dates. Grounding the verdict in an actual structural graph of the code is the same idea that worked for OneGraph, an MLH Hack Day project I built the week before this challenge: an LLM reasoning over real graph facts is more trustworthy than an LLM reasoning over nothing.

Code

CodersAcademy006 / graphsloth

Graphify + local Gemma 4 (+ Temporal) audit of abandoned project folders, Hacktoberfest Week 3

GraphSloth

Live demo →

A lazy-friendly audit of your abandoned project folders. Built for the Hacktoberfest Open-Source AI Challenge: Week 3 ("Slow and Steady").

Most developers have a ~/Desktop/Project folder full of things they built, half-finished, and never looked at again. Deciding what's safe to archive is tedious enough that nobody does it. GraphSloth does it for you, overnight, and cites real evidence instead of guessing.

Real run against the author's own Desktop: 29 folders audited, 10 flagged ARCHIVE-CANDIDATE (29.4G reclaimable), 16 ACTIVE, 3 DORMANT. 9 of those were flagged with real deploy signals and kept out of the archive pile automatically, including a live e-commerce store and a production exam-scoring backend.

How it works

For each top-level folder:

Disk size — du -sk.
Git facts — last commit age, branch, dirty state. Checked one level into subfolders too, for folders that hold a git repo rather than being…

View on GitHub

Prize Categories

Best Use of Gemma, Best Use of Temporal.

OneGraph: grounding Gemma 4's code reviews in a real dependency graph instead of a guess

CodersAcademy006 — Thu, 22 Oct 2026 13:12:55 +0000

OneGraph: grounding Gemma 4's code reviews in a real dependency graph instead of a guess

An LLM code review tool that reads a diff in isolation has a blind spot: it cannot see what else in the repository depends on the lines that changed. It can comment on the diff, but it cannot tell you the function you just touched is called from nineteen other places, three of them in a different service. That is not a hallucination in the usual sense, it is a coverage gap, and it is the gap code-review-graph and the knowledge-graph-over-vector-search approach in this post about replacing grep-based review both set out to close, each in their own way.

OneGraph is my attempt at the same problem, built for Hacktoberfest Hack Day Pune x GDG on Campus VU. It pairs Graphify, a tree-sitter based dependency graph extractor, with Gemma 4, and wires the result directly into PR-Agent as a live /graph_risk command. There's also a related post worth reading if you want the extraction side in more depth: Graphify: AST-Based Knowledge Graphs for Agent Code Navigation.

Repo: https://github.com/CodersAcademy006/onegraph
Live demos: https://graphs-site-omega.vercel.app/
Live in a real PR: https://github.com/CodersAcademy006/onegraph-flask-demo/pull/1

The split that makes this work

Everything in OneGraph follows one rule: code owns the facts, Gemma owns the words.

Graphify extracts. graphify extract --code-only runs tree-sitter over the repo and builds every call, import and containment edge into a real graph. No LLM call, no API key, $0 to build, deterministic.
Graphify labels. graphify label runs community detection (Leiden/Louvain) and names every cluster.
Gemma 4 narrates. It reads the graph traversal result, not the raw source, and writes the plain-English explanation. It never computes risk, it never counts dependents, it only describes what the graph already proved.
PR-Agent posts it. A /graph_risk comment on any pull request, with a risk level computed from a real blast-radius count and a link to the full interactive graph.

The risk level is arithmetic, not a model's opinion of its own severity. A self-rated "this feels risky" from an LLM is noise; a count of how many real call sites a changed function has is a fact.

What it looks like on a real PR

I ran this against a real demo PR, not a constructed example, and verified the result through the GitHub API before trusting it:

The comment text comes from a small f-string template in pr_graph_risk.py:

comment = (
    f"**Risk: {level}**, full repo graph: **{node_count:,} nodes / {edge_count:,} edges** "
    f"({real_time_ms}ms, $0 LLM cost to build)\n\n"
    f"Affects: {affects}\n\n"
    f"{gemma_analysis}\n\n"
    f"Graphify's own viewer: force layout, community clusters, click any node.\n"
    f"{graph_url}"
)

Everything numeric in that string comes from graph.json, computed before Gemma ever sees a prompt. Gemma only fills in gemma_analysis.

Wiring into an existing tool, not rebuilding it

PR-Agent already has a tool registry. Adding /graph_risk is two lines:

# pr_agent/tools/pr_graph_risk.py registers itself here
command2class = {
    ...,
    "graph_risk": PRGraphRisk,
}

I did the same thing for deepwiki-open: one environment variable, ONEGRAPH_BACKEND=graphify, gates research_chat()'s context source. Unset, the original embedding-RAG path runs untouched. Both diffs are in the repo under integrations/, each under 40 lines against the upstream file.

Real scale, not a toy demo

I ran Graphify against four public repos end to end, nothing trimmed, nothing simulated. Every number below is read directly from the extracted graph.json:

Repo	Nodes	Edges	Communities
pallets/flask	2,151	3,569	n/a
NVIDIA/Megatron-LM	48,295	133,164	1,275
Graphify-Labs/graphify (the sponsor tool, graphing itself)	18,552	42,018	865
supabase/supabase	65,361	247,294	1,400

All four are live, clickable, force-directed graphs, not screenshots. Supabase's 65k-node graph loads and stays interactive because Graphify's exporter aggregates above a node-limit into community clusters for rendering, while graph_stats() still reports the true full count underneath.

The honest finding from the A/B test

I ran the same question against the project both with and without the graph as context, to see whether grounding actually changes anything. The tempting headline would be "zero hallucinated citations," but that is not what the data showed: the embedding-RAG baseline did not hallucinate either, both runs were 100% citation-accurate on the files they cited.

The real difference was coverage. The graph-grounded answer found and cited more of the actually-relevant call sites, because it could traverse real edges instead of ranking chunks by embedding distance. This matches what the vector-search-replacement post above found independently: vector search returns what is semantically similar, a graph traversal returns what is actually connected. Those are not the same question, and for a dependency question, only one of them is the right one.

What it actually costs to run

Instead of estimating a token price, I measured one real Gemma 4 call end to end, served locally through Ollama (gemma4:12b-it-q4_K_M), no API key, no cloud bill:

wall time: 132.8s
prompt_eval_count (input tokens): 2,438
eval_count (output tokens): 1,658
context sent: 6,697 characters
cost: $0

That is the real number for one /graph_risk run on a local machine, not a projection.

A bug the subprocess wrapper hid

core.py wraps the graphify CLI with subprocess.run(..., cwd=str(path)). Early on I passed a relative Path into export_graph_html() and got a bare CalledProcessError with nothing useful in stderr. The cause: a relative path gets re-resolved against the changed cwd inside the subprocess, so the graph-json argument silently points somewhere that does not exist. Running the underlying graphify export html command directly, outside the wrapper, worked fine and gave it away. The fix is one .resolve() call at every site that calls into the wrapper. It is a small bug, but it is the kind that looks like a Graphify problem until you actually trace where the path gets rewritten.

Try it on your own repo

./onegraph <github-url> [slug]

Clones, extracts, labels, exports, deploys, and prints the live URL. For a judge who wants to run it on their own repository right there during review.

Why open source mattered for this build

Graphify's extraction is $0 because it never calls an LLM to understand structure, tree-sitter already knows the grammar. Gemma running locally through Ollama means the narration step also costs nothing per call, which matters for a tool meant to run on every PR, not just a demo. And because PR-Agent and deepwiki-open are both open, the two-line and one-env-var integration points above are things anyone can verify by reading the actual diff, not something I am asking you to take on faith.

Full README, architecture, and every screenshot above: https://github.com/CodersAcademy006/onegraph

RaktSetu: blood for an emergency patient in minutes, without the phone tree

CodersAcademy006 — Sat, 17 Oct 2026 19:02:49 +0000

This is a submission for the Hacktoberfest 2026 Week 2 challenge.

What I Built

When a patient in an Indian hospital needs blood urgently, someone at the blood bank desk picks up a phone. They call the bank down the road, then another, then start working through a list of donors who may or may not answer, may or may not be eligible, and may or may not be anywhere close. India has more than 28 lakh donors registered on the government's e-RaktKosh platform, and almost none of them are reachable this way at 2 AM.

RaktSetu replaces that phone tree. A nurse shares the patient's location and answers four questions: what is needed (whole blood, red cells, platelets or plasma), the blood group, how many units, and how urgent. Or they type it the way they would say it: "O+ blood required, 2 units, Andheri, urgent accident case." From there RaktSetu:

Reserves what nearby blood banks already have on the shelf, nearest first.
Recruits donors only for the shortfall, in batches, nearest and eligible first, widening the search when nobody answers.
Tells each donor exactly where to go: hospital, a map link, and the number to call, plus a private page where they can say yes, no, or reply in their own words.
Stands everyone else down the moment the request is covered.

Who pays: hospitals and blood banks, as a monthly subscription. What they are buying is staff time during the worst ten minutes of someone's day. Donors and patients never pay anything; blood donation in India is voluntary by law, and the product is built around that.

The spark: a hackathon pitch called RaktKhoj (team Blood Boys, Build What Moves India) laid out this exact problem, including the fact that 12% of Indian districts are more than 100 km from the nearest blood bank. RaktSetu is my own independent build on that problem statement, with its own name, code and architecture.

Demo

Live: https://answered-buyer-latin-underground.trycloudflare.com

The demo runs from my laptop through a temporary tunnel. If it happens to be offline when you visit, the screenshots here and the repo show the full flow.

To try it: fill in any hospital name and number, tap Use demo location (Andheri, Mumbai), answer the four cards, and press Dispatch. Then scroll to the Donor simulator and either answer for a donor or tap Open donor page to see exactly what they would get on their phone. Try typing a reply like "haan aa raha hoon, 20 min mein" or "can I come after 6pm?" and watch where it lands on the hospital side. Each batch gets 60 seconds before the search moves on.

Code

CodersAcademy006 / raktsetu

Emergency blood-donor dispatch console — Gemma + Temporal + MongoDB Atlas (Hacktoberfest 2026)

RaktSetu

Emergency blood dispatch for hospital and blood-bank staff. Built for the Hacktoberfest 2026 "Side Hustle" DEV Challenge.

Staff share the patient's location and answer four questions (component blood group, units, urgency), or describe the need in a sentence. RaktSetu then:

Reserves units from nearby blood banks first (within 10 km, exact group before other compatible groups, each unit taken by an atomic conditional decrement so two requests never claim the same one).
Recruits donors only for the shortfall, through a durable Temporal workflow: batches of eligible, compatible donors nearest first, every donor at a radius before widening (5, 10, 25, 50 km), early wake-up when a whole batch has answered, and a hard stop when nobody is left.
Tells donors exactly where to go: hospital, map link, callback number, and a private link to a donor page where they accept, decline or reply in their own words.
…

View on GitHub

How I Built It

The design rule I held myself to: the open model does the language work, and every medical or safety decision stays in plain, testable code. Each piece of open technology has a job the product would fall apart without.

Gemma: three jobs, each with a guard

Gemma 3 (4B, served locally through Ollama) handles everything that involves messy human language, and each of its outputs passes a deterministic check before anything acts on it.

1. Reading requests typed in a hurry. Gemma turns "critical: B+ x3 units, near Powai" into structured fields. Then the code checks that the blood group, the unit count and the locality it returned all literally appear in what the nurse typed. Early on, a request for blood "in Delhi" could get quietly matched to the closest Mumbai locality in the list. Now it is refused with a message telling staff what to fix. A model that helpfully fills in a gap is the most dangerous kind of mistake in this domain, so the system sends the request back instead.

2. Writing to donors. Gemma writes the warm, human opening of each outreach message. The facts that follow (what is needed, which hospital, the map link, the number to call) are assembled from the database record. Any draft containing a digit or a link is thrown away, so the model can never invent an address or a phone number that sends a donor to the wrong place.

3. Understanding replies. Donors answer however they answer. "haan aa raha hoon, 20 min mein pahunch jaunga" becomes an accept with a 20 minute ETA. "Sorry, I had fever last week" becomes a decline with a note for staff. During testing, Gemma read "Can I come after 6pm instead?" as a yes. So now any negation or condition in a reply (a question mark, "after", "instead", "maybe", "kal") vetoes an accept and puts the reply under Needs a call, with the donor's number one tap away. Marking a donor as coming when they are not is the expensive error; one extra phone call is cheap.

If Gemma is slow or unreachable, the wording falls back to fixed text. Dispatch never waits on the model.

Temporal: waiting on humans, durably

The hard part of this product is time. You message ten people, then wait. Some answer in a minute, some never do, and the server should be able to crash in the middle without anyone getting messaged twice or forgotten.

EmergencyRequestWorkflow is a Temporal workflow that:

reserves bank units first and finishes immediately if the banks cover everything,
sends a batch of the nearest eligible donors and waits on a durable timer,
treats each donor's reply as a signal, so the moment the target is met it stops,
wakes early when every donor in a batch has answered (for example, all declined) instead of sitting out the timer,
works through every eligible donor at a radius before widening (5, 10, 25, then 50 km),
and when it ends, tells every donor still pending that they are no longer needed.

Activities are retry-safe: each message is written as an upsert keyed on request and donor, so a retried activity never messages the same person twice. This mattered in practice. The network I built this on drops connections to the database every so often, and I watched activities fail mid-request, retry with backoff, and carry on exactly where they left off, with the hospital view never noticing. The workflow logic is covered by tests that run the real workflow on Temporal's time-skipping test server, including the full escalation ladder and the all-decline early wake-up.

MongoDB Atlas: geography and medicine in one query

Donors and blood banks live in Atlas with 2dsphere indexes. Finding the next batch is a single $geoNear query that also applies the medical rules, so the batch limit counts only donors who can actually give:

Eligibility, from India's NBTC guidelines: age 18 to 65, at least 45 kg, and 90 days since the last donation for men or 120 days for women.
Compatibility by component. Red cells follow the familiar donor table. Plasma runs the other way: AB is the universal plasma donor and Rh does not matter. Platelets follow the plasma rule and give Rh-negative patients Rh-negative donors only.

Bank stock is reserved with an atomic conditional decrement, so two hospitals asking at the same moment can never be promised the same bag.

Built to be trusted

Staff endpoints sit behind a per-hospital access code (switched off for this public demo, since all data is synthetic). Each donor's link carries a random ID in the URL fragment, so it never shows up in server logs. Staff only see a donor's phone number after that donor says yes or asks for a call. The page runs under a strict Content Security Policy with no inline scripts or styles. 33 tests cover the medical rules, the model guards and the workflow.

What is simulated

I do not have access to e-RaktKosh, so donors and banks are synthetic: 460 donors and 13 banks across Mumbai, plus a cluster near Pune and Nashik with no banks at all, which is what the 12% of districts far from a bank look like. Messages are shown in the donor simulator and on the donor page instead of going out over WhatsApp. Sending is behind a single NotificationProvider interface, so plugging in the WhatsApp Cloud API changes one file and nothing in matching or the workflow.

Why Does Open Innovation Matter?

The pitch that inspired this never made it past a demo. That is the usual fate of good public-interest ideas: building them for real needs a team, a budget, and an API bill that grows with every message.

Open tools change that math. Gemma runs on the hospital's own machine, so a patient's blood group and location never leave the building, and reading a donor's reply costs nothing per message. That matters for a product whose busiest night, a highway pile-up or a dengue surge, is exactly when a per-request bill would spike. Temporal's open-source server gave me production-grade durable workflows on a laptop, the same engine large companies run, with no license standing between a solo builder and reliability. And because each of these is open, a state health department or an NGO can inspect exactly how a donor gets chosen, run it themselves, and change it. For a system that decides who gets asked to give blood, that transparency is part of the product.

Prize Categories

Best Use of Gemma: request parsing, outreach writing and donor reply understanding, each with a deterministic safety guard.
Best Use of Temporal: the whole dispatch lifecycle is one durable workflow that retries failed steps, resumes after crashes, and never double-messages a donor.
Best Use of MongoDB Atlas: the data layer, with geospatial matching, eligibility in the query, and atomic bank-stock reservation.

Butterflies don't take weekends off: 40,000 Pune sightings and a forecast that fell apart when I removed one column

CodersAcademy006 — Sat, 10 Oct 2026 06:27:30 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

On an average Sunday, Pune's naturalists log 12.2 butterfly species. On an average Monday they log 4.0.

I did not believe the butterflies had a schedule, so I built a forecaster, backtested it on a year it had never seen, and then took away the one feature I suspected. The forecast went from useful to useless.

This post is the build, the number, and the afternoon a worker process got kill -9 in the middle of a 13-minute download and the pipeline finished anyway.

What I Built

Fieldcast answers the question that comes before "what is this bird?". It answers which day should I go?

For the next seven days near Pune it forecasts how many butterfly species and how many bird species local observers will log, drops the wet days, and prints the best one on a single page with the species most likely to turn up. You read the card, pocket the phone, and go.


Place	Pune, 30 km radius (18.52, 73.86)
Data	40,186 research-grade iNaturalist observations (2019 to 4 Oct 2026) and daily Open-Meteo weather
Model	TabPFN v2, open weights, CPU only, no training loop
Prose	Gemma 3 4B running locally through Ollama
Plumbing	Temporal workflow with retries, heartbeats and checkpoints
Output	One printable card, light, dark and print layouts
Test	365 held-out days against a seasonal average and gradient boosting

Demo

Live card: codersacademy006.github.io/fieldcast/card.html

On a phone, which is where you will read it before you leave:

And on paper, so the phone can stay in your pocket:

The forecast it generated on 6 October 2026:

It picks Saturday 10 October: dry, 34.8 C, about 27 butterfly species and 20 bird species expected. The likeliest sightings:

Species	Model-estimated chance it is logged that day
Lemon Migrant	97%
Lemon Pansy	87%
Common Mormon Swallowtail	77%
Red Pierrot	66%

Look at that chart again. Five weekdays sit near 19, then the weekend jumps to 27. I will come back to that jump, because it turned out to be the whole story.

Does the forecast work?

I trained on everything before 5 October 2025 (2,469 days) and tested on the next 365 days. Two baselines: a seasonal average (the mean for that time of year) and gradient boosting on the same features.

Group	Model	Rank correlation (Spearman)	Error (species)	Best-day lift
Butterflies	Seasonal average	0.36	6.03	0.65
Butterflies	Gradient boosting	0.48	5.34	1.45
Butterflies	TabPFN	0.52	5.14	1.40
Birds	Seasonal average	-0.04	11.40	0.74
Birds	Gradient boosting	0.38	9.27	1.54
Birds	TabPFN	0.37	8.36	1.69

Best-day lift: each week I took the day the model ranked highest and divided what was logged that day by the week's average day. 1.0 means the pick was no better than that week's average day. TabPFN's picks averaged 1.4 times the butterfly species and 1.7 times the bird species of a normal day.

TabPFN wins on butterflies and ties gradient boosting on birds, with the lower error. On individual species it beats the seasonal average for 11 of 14 (ROC AUC), and loses on three: Lemon Migrant, Red Pierrot and Rose-ringed Parakeet, which scores 0.476, below a coin flip. AUC measures ranking only; I did not validate calibration, so read the percentages as model estimates, not calibrated probabilities. The full per-species table is in the repo.

That is a decent result. It is also where most weekend projects stop, with a table and a pat on the back. I kept going because of the chart above.

The ablation that ate my result

Why would a model that knows the season and the monsoon predict a weekend jump of 8 species? Because it learned something I handed it. One of my features is a weekend flag.

So I ran the backtest twice, with and without it. Same data, same split, same model.

Group	Weekend flag	Rank correlation	Best-day lift	Weeks the pick was a weekend day
Butterflies	with	0.52	1.40	52 of 52
Butterflies	without	0.33	0.95	13 of 52
Birds	with	0.37	1.69	52 of 52
Birds	without	-0.07	1.06	21 of 52

Without the flag, the butterfly forecast drops to a lift of 0.95, which is slightly worse than picking a day at random. The bird forecast falls to a rank correlation below zero. With the flag, every single week's best day is a weekend day, 52 out of 52.

The forecast is mostly a forecast of people.

Same butterflies, three times the logging

Here are all 2,834 days in the dataset, averaged by weekday. Each number is the count of distinct species logged that day.

	Mon	Tue	Wed	Thu	Fri	Sat	Sun
Butterfly species	3.98	4.18	4.29	4.37	4.40	7.82	12.22
Bird species	2.96	3.09	3.22	3.39	3.83	5.52	7.13

Weekdays average 4.24 butterfly species and weekends 10.02, a factor of 2.4. For birds it is 3.30 against 6.32, a factor of 1.9. Now the number that explains it: observers log 9.7 observations on a weekday and 25.3 on a weekend day, a factor of 2.6. Divide species by observations and the two kinds of day come out close, about 0.44 species per observation on weekdays and 0.40 on weekends.

Pune does not get more butterflies on Sunday. It gets more people holding phones. The model learned that correctly, and that is the problem with calling it a butterfly forecast.

I kept the flag in the shipped model on purpose. If you are choosing a day for a trip, "a day when a lot will be logged" is a fair proxy for "a day when someone nearby is looking". But the card now says what it is, and I would not put it in front of anyone as a map of where the animals are.

Code

CodersAcademy006 / fieldcast

TabPFN + local Gemma forecast of which day to go outside near Pune

Fieldcast

Which day this week is best to go outside near Pune, and what will you probably see. TabPFN forecasts daily butterfly and bird species counts from weather and calendar. Local Gemma writes a one-page printable card.

Finding that shaped the project: observers log 2.6 times more observations on weekends, so a forecast of logged species is largely a forecast of people. ablate.py removes the weekend flag and shows how much of the skill disappears.

python3.11 -m venv .venv && .venv/bin/pip install -r requirements.txt
brew install ollama && ollama serve & ollama pull gemma3:4b
.venv/bin/python fetch.py                                  # iNaturalist + Open-Meteo, about 20 min
TABPFN_ALLOW_CPU_LARGE_DATASET=1 .venv/bin/python model.py backtest   # about 10 min, writes metrics.json
TABPFN_ALLOW_CPU_LARGE_DATASET=1 .venv/bin/python model.py forecast   # about 9 min, writes forecast.json
.venv/bin/python card.py                                   # writes card.html

Durable run (survives a killed worker, resumes the fetch from its page checkpoint), with the optional Sentry tracing of the Gemma step:

…

View on GitHub

How I Built It

Code owns the numbers, Gemma writes the words, Temporal keeps it all alive.

Features and model

Day of year as sine and cosine, the weekend flag, a slow year trend, and rain and temperature windows over 7 and 30 days. The 30-day rain window is how the model learns the monsoon.

TabPFN is a tabular foundation model, so there is no training loop to tune. One regressor predicts species per day and one classifier per common species predicts "will it be logged today". On a MacBook Air M5 CPU the backtest takes about 10 minutes and the forecast about 6.

Ordinary Python then ranks the seven days, drops the wet ones and builds a data structure that holds every number that will appear on the card.

Temporal: the afternoon I killed the worker

The fetch alone takes about 13 minutes, because iNaturalist pages are slow and polite. A laptop sleeping, a network drop or one bad page should cost a retry, not the whole run. So the pipeline is a Temporal workflow, and each step is an activity:

step = dict(start_to_close_timeout=timedelta(hours=1),
            heartbeat_timeout=timedelta(minutes=2),
            retry_policy=RetryPolicy(initial_interval=timedelta(seconds=5),
                                     backoff_coefficient=2, maximum_attempts=8))
await asyncio.gather(*[workflow.execute_activity(fetch_obs, g, **step) for g in GROUPS],
                     workflow.execute_activity(fetch_weather, **step))
await workflow.execute_activity(merge_obs, **step)
await workflow.execute_activity(run_forecast, **step)
return await workflow.execute_activity(make_card, **step)

Butterflies, birds and weather download in parallel. Each long activity runs its blocking code in a thread and heartbeats every 10 seconds, so Temporal can tell a slow step from a dead one. The fetch also writes a checkpoint file after every page.

Then I tested it properly. Mid-fetch, I ran kill -9 on the worker. Temporal got no goodbye. Two minutes later the heartbeat timeout fired, Temporal scheduled attempt 2, I started a fresh worker, and the fetch resumed from the last saved page instead of starting over.

Then it got more interesting, because the run failed for a real reason I had not planned. The forecast step died six times in a row with TabPFN's guard: "Running on CPU with more than 1000 samples is not allowed by default." I had set the override as an environment variable in my shell, and the worker did not have it. I fixed it in code with one line in model.py, restarted the worker, and the pending retry succeeded on attempt 7 without anyone re-running anything.

Total wall time for the whole run, kill, bug and fix included: 24 minutes 42 seconds, status Completed. I checked that the resumed run matches a clean one. The weather table is identical. The resumed data has 40,191 rows against 40,186, and the extra 5 are observations people uploaded in between. The 7-day forecast agrees within 0.4 species on every day.

Gemma: let it talk, never let it count

Gemma 3 4B writes three sentences on the card: why this day, what to look for and in what order, and a reminder to leave the phone alone. It gets the facts in its prompt. Every number on the card comes from code.

A small model told to follow a format does not always follow it, so I measured. Over two batches of 30 cards, 17 and 18 of them broke the three-sentence rule, which is about three in five. Across the 60 cards, zero invented a number. So the checker rejects any draft with the wrong length or any digit that is not in the facts, retries up to five times, and falls back to a plain template if all five fail. The model decides the wording. The code decides what counts as acceptable.

What this does not show

The backtest feeds the model the actual weather for the test year, not archived forecasts, so real use will score lower.
Gradient boosting is close behind TabPFN here. I will not claim a big win over it.
Without the weekend flag, the forecast has little left. That is the finding, and it is also a limit.
I have not yet carried the card outside and checked it against what I saw.

Run it

CodersAcademy006 / fieldcast

TabPFN + local Gemma forecast of which day to go outside near Pune

Fieldcast

python3.11 -m venv .venv && .venv/bin/pip install -r requirements.txt
brew install ollama && ollama serve & ollama pull gemma3:4b
.venv/bin/python fetch.py                                  # iNaturalist + Open-Meteo, about 20 min
TABPFN_ALLOW_CPU_LARGE_DATASET=1 .venv/bin/python model.py backtest   # about 10 min, writes metrics.json
TABPFN_ALLOW_CPU_LARGE_DATASET=1 .venv/bin/python model.py forecast   # about 9 min, writes forecast.json
.venv/bin/python card.py                                   # writes card.html

Durable run (survives a killed worker, resumes the fetch from its page checkpoint), with the optional Sentry tracing of the Gemma step:

…

View on GitHub

python3.11 -m venv .venv && .venv/bin/pip install -r requirements.txt
brew install ollama && ollama serve & ollama pull gemma3:4b
temporal server start-dev                      # UI at localhost:8233
.venv/bin/python workflow.py worker            # second terminal
.venv/bin/python workflow.py run               # third terminal, writes card.html
.venv/bin/python ablate.py                     # the weekend ablation

Change LAT and LNG in fetch.py and model.py to point it at your own city.

What I Learned

Run the ablation you are afraid of. One column decided whether this project was a result or an artifact. The tables looked good right up until I removed it.
A forecast of observations is a forecast of observers. Citizen-science counts carry the habits of the people who log them. Rank correlation will not tell you that. A weekday table will.
Durability is a design choice you make before the crash. The heartbeat and the checkpoint cost about ten lines. The kill -9 cost me two minutes of waiting and nothing else.
Make the language model describe and never decide. Gemma is wrong about format three times in five and has never been wrong about a number, because it never makes one.

What's Next

Replace actual weather with archived forecasts so the backtest matches real use.
Model observer effort directly, so the forecast separates animals from people.
Carry the card outside and compare it with what I actually see.

Why Does Open Innovation Matter?

Anyone can check the weights. TabPFN's v2 checkpoints are public on Hugging Face and the README pins them, so anyone can rerun the backtest and the ablation and get my numbers. The newer v3.5 weights sit behind a licence gate, so I used the open ones and stayed reproducible.
Almost nothing leaves the machine. The only network calls are two public APIs. Gemma runs locally, so the card writer needs no key and no account, and it sees a weather summary and nothing else.
The data is a commons. Every row is a person who photographed a butterfly and let strangers identify it. A forecast built on that should be shareable the same way, so the repo has the fetch script, the model, the metrics and the ablation.

Prize Categories

Best Use of Gemma: Gemma 3 4B runs locally through Ollama and writes the card prose from code-supplied facts, behind a checker that rejects wrong length and invented numbers, measured over 60 runs.
Best Use of TabPFN: the whole forecast is TabPFN, a regressor for daily counts and a classifier per species, backtested on a held-out year against gradient boosting and a seasonal baseline, then ablated to show how much of its skill is observer behaviour.
Best Use of Temporal: the pipeline is a Temporal workflow with parallel activities, heartbeats, retries and checkpointed resume, demonstrated by killing the worker mid-fetch and by recovering from a real configuration failure on retry.

I Built a Local DuckDB Engine to Mathematically Settle Cricket Debates

CodersAcademy006 — Fri, 29 May 2026 12:02:39 +0000

For years, sports commentators have repeated the same clichés about T20 cricket: "You have to win the powerplay," "You need an anchor to win," and "Team X always chokes."

I wanted to know if any of that was actually true.

The problem is that querying 15+ years of historical ball-by-ball telemetry (over 294,000 deliveries) via commercial sports APIs is painfully slow and brutally rate-limited.

So, I built Midwicket—an open-source SDK that bypasses APIs entirely. It pulls raw open data into a local DuckDB and PyArrow engine, turning your laptop into a sub-millisecond sports data warehouse.

To test the architecture, I wrote a logistic regression Win Probability model (AUC 0.87) trained on 1,239 IPL matches. Because the query engine is entirely local, I could calculate the exact Win Probability Added (WPA) for every single ball ever bowled.

When I ran the numbers, the data completely broke some of the sport's biggest myths.

1. The "Choke Index" is real, and it's ruthless.

I queried the database for every match where a chasing team reached an 80% Win Probability at any point, but still managed to lose the game.

Franchise	80%+ WP Matches	Chokes	Choke %	Rating
Royal Challengers Bangalore (RCB)	9	6	66.7%	Notorious
Mumbai Indians (MI)	10	4	40.0%	High
Chennai Super Kings (CSK)	10	3	30.0%	Moderate
Kolkata Knight Riders (KKR)	9	2	22.2%	Composed

The Finding: RCB has a staggering 66.7% choke rate from commanding positions. If they reach an 80% probability of winning, they are mathematically more likely to throw it away than finish the job. KKR, on the other hand, converts almost 78% of these positions.

2. The Anchor vs. The Finisher (Kohli vs Dhoni)

Who is more valuable in a run chase: the guy who bats for 15 overs to build a foundation (Kohli), or the guy who comes in at the end (Dhoni)?

The WPA math heavily favors the finisher.

Player	Total Innings Analyzed	Positive WPA %	Average WPA per Innings
MS Dhoni	10	80%	+46.5%
Virat Kohli	10	70%	+25.8%

The Finding: Kohli is vastly consistent, but Dhoni mathematically contributes ~20% more total win probability per innings. The model reveals that run-chases are highly non-linear; the leverage in the final 3 overs is so massive that a finisher essentially holds the entire win probability of the team in their hands.

3. "Winning the Powerplay" is a myth. Over 19 is the cliff.

If you simulate a catastrophic 2-wicket collapse at any point in a chase, the Powerplay (Overs 1-6) is surprisingly forgiving—a collapse there drops your win probability by about 25%.

However, a collapse in Over 19 drops it by 60.9%.

By the 19th over, the margin of error mathematically compresses to zero. It is the definitive breaking point of the sport.

The Open Source Engine

If you’re a sports analytics nerd, a data engineer, or just someone who wants to run SQL queries against 15 years of sports data without paying for an API, I’ve open-sourced the entire engine, the PyArrow schema, and the trained models.

Check out the repo here: Midwicket on GitHub

I’d love to hear your thoughts on the architecture, the DuckDB implementation, or the data findings! What team should I run the choke index on next?