DEV Community: Hyunsik Park

Three fewer graph passes, 12% more time

Hyunsik Park — Mon, 02 Nov 2026 04:14:12 +0000

Bounded Accord’s Speed Demon engineering notes, written on October 31, 2026 and updated after our last push on November 2. Live-board results are practice scores, separate from final judging.

The last graph-construction change in this account removed three complete reads of a five-million-edge array. It preserved the order of every adjacency list and left the shortest-path search unchanged. It passed the correctness checks. The measured program took about 12% longer.

That result came from our entry in Speed Demon, organised by Hackathon Raptors. Bounded Accord implements four tasks in Rust: log aggregation, Boolean and phrase search, a CSV join, and directed shortest paths. The entry repository contains the implementations and their performance records.

The comparisons below cover rejected changes, an officially scored storage improvement, and an input-partitioning change that reached the live board on the last day.

One graph pass can carry more expensive work

Track D stores the graph in two compressed sparse row structures: one for outgoing edges and one for incoming edges. Each row’s edges are contiguous. A forward search from the source and a reverse search from the target can then read their own adjacency arrays without searching the original edge list.

The accepted constructor first parses triples of source, destination and weight. For each direction, it counts degrees, computes row offsets, allocates edge storage, and scans the triples again to fill that storage. There are four full triple scans after parsing.

The candidate counts both degrees while parsing, then fills both adjacency arrays in one shared triple scan. Each edge still appears in its original relative order within its row. Parallel edges, exact duplicates, self-loops and zero weights remain intact. The input byte buffer is released before the edge arrays are allocated in both versions.

The following comparison includes reading, construction, all queries and writing the output:

Measurement	Accepted constructor	Fused constructor
Pinned-image process time	0.858853 s	0.960344 s
Peak native process RSS	192,388 KiB	185,220 KiB
Nonblank, non-comment source lines	281	286

Times are means of the middle three of five runs per version, after fixed warm-ups. Baseline and candidate runs were interleaved on the same Intel Core i5-12500H machine running Ubuntu 24.04 under WSL2. The images were pinned, six workers were used, and the published child timer excluded container startup. RSS came from separate native runs; it is not the official container-memory measurement.

The time ratio, baseline divided by candidate, was 0.894317. Memory fell by about 3.7%. Both timing spread checks passed, but the candidate missed our previously fixed efficiency requirements. We restored the accepted source and executable and checked the full output hash again.

The comparison establishes that this implementation was slower in this environment. It does not identify a cache-miss rate, a memory-bandwidth limit, or the cost of each added write. Counting loop passes supplied a hypothesis; it did not measure the cost of the resulting access pattern.

An exact small-key representation did pay

Track C joins CSV records to countries and counts distinct names per country. Splitting records at every newline would be wrong: a quoted field can contain a newline. In the officially scored pipeline, the producer carries quote parity across input blocks and dispatches only complete logical records. Six workers decode fields and accumulate numeric totals.

Distinctness spans all workers. The accepted design groups requests into 64 mutex-protected shards. Under a shard’s lock, the first occurrence of an exact (name, country) pair sets a membership bit and increments one worker’s count. Summing those counts is valid because the first-pair decision is shared.

The useful storage change was deliberately narrow. When there are at most 256 country groups, including the unmatched group, names of at most 16 bytes fit in two words plus a length. Four words hold the country-membership bits. The key contains every name byte; it is not a fingerprint used as identity. Length distinguishes a short name from a longer zero-padded value. Longer names and larger country tables keep the full-byte fallback.

Against the preceding accepted pipeline, this change reduced pinned-image time from 0.186579 to 0.152485 seconds and native peak RSS from 24,060 to 19,828 KiB. It passed its fixed adoption requirements. Its subsequent official run, run-52f0819fc621, recorded 55.455380 machine points, up from the previous best of 51.737524.

The tests targeted the representation’s boundaries: every inline-key byte position, lengths around 16 and 17 bytes, zero bytes, country-bit boundaries, tables through 513 countries, concurrent first-pair updates and reused scratch storage. Fast-path checks alone would have missed the fallback’s obligations.

A small time saving can lose the combined comparison

A later Track C candidate scanned each complete record for outside-quote commas and quote counts. That metadata let it derive decoded note lengths without visiting every note byte in the decoder. Unescaped names borrowed their input bytes; escaped names used scratch storage. Record framing and membership storage stayed unchanged.

It was correct across the tested cases, including split vector blocks, escaped quotes, embedded newlines, Unicode, BOM bytes and a two-megabyte note. It also reduced measured process time slightly:

Measurement	Accepted parser	Structural-metadata parser
Pinned-image process time	0.150447 s	0.147206 s
Peak native process RSS	20,060 KiB	20,016 KiB
Nonblank, non-comment source lines	393	458

The speed ratio was 1.022018, below our fixed 1.18 adoption requirement. Both timing spread checks passed. The source increase also mattered: Speed Demon’s coefficient charges for source size as well as time, memory and dependencies. Using our local RSS and line-count proxies gave a coefficient ratio of 0.988437, below our required 1.05. These counts differ from the host’s formatted-source and container-memory axes, so the ratio is an estimate, not a predicted official score.

We rejected this implementation before submission. Its shorter decoding path did not produce enough whole-program benefit to cover the measured trade-off.

Finding five boundaries without listing every record

A later input-partitioning change reached the local adoption threshold. The first version mapped the immutable CSV file read-only and divided it into six complete-record ranges. Workers borrowed those ranges directly, eliminating the producer’s owned buffers and channels. Its partitioner still scanned the entire input sequentially, collecting record-end offsets to choose just five internal cuts. That version saved memory but missed the time requirement.

The next version computes quote parity in six parallel byte ranges. A prefix XOR supplies the quote state at each proposed cut; a forward scan then finds the next newline outside a quoted field. An escaped quote contributes two quote bytes, so even a cut between them receives the correct starting state. Long quoted records may send several cuts to the same boundary, producing valid empty ranges. After partitioning finishes, six parsing workers borrow the resulting slices. The parser and shared membership tables stay unchanged.

This comparison uses a new fixed batch against the previously accepted producer pipeline:

Measurement	Accepted producer pipeline	Parallel-parity partitioning
Pinned-image process time	0.149709 s	0.124672 s
Container cgroup peak memory	20,582,400 B	18,612,224 B
Source-line proxy	409	491

The time reduction was 16.7%, and the measured memory reduction was 9.6%. The local coefficient ratio was 1.087865, above the fixed 1.05 requirement. That calculation uses time, memory, source size and direct runtime dependencies; image size is a separate build limit. Both implementations had a dependency-axis value of one.

Memory was read from the Docker cgroup with host data prewarmed and a common trusted holder keeping the cgroup available after the timer exited. This measures the container’s recorded peak, but it does not reproduce the host’s parent harness or isolation. The source count is also a local proxy. The baseline had one slower run; the predeclared middle-three mean excluded the fastest and slowest of five runs from each version, with all raw values retained.

Eleven Rust tests, seventeen validation groups and all fourteen image outputs passed. The checks included quote pairs split at every byte position, long records, Unicode, BOM handling and the final record without a newline. The source was frozen before fresh seeds 137 and 138 and reserved seed 139 were generated.

A separate diagnostic sampled the unchanged candidate twice. It captured 620 and 621 CPU events, with text decoding accounting for about 20% in each capture. The earlier producer pipeline also placed text decoding near 21%. These are exclusive CPU sample locations, not elapsed-time shares; they do not establish that a previously rejected parser change should be tried again.

The change's first live-board run, run-e08fc96bfae2, recorded 57.147738 machine points; the previous best was 55.455380. The board measured 0.160190 seconds instead of 0.187834, and 17,788,928 bytes of peak memory instead of 20,283,392. Formatted source grew from 401 to 483 lines. On the board the coefficient rose by a factor of 1.081, close to the local estimate of 1.088, although the two use different time, memory and source-size measurements.

The local winner that lost on the board

An earlier Track D experiment reordered vertices with breadth-first numbering. Its final local version remapped queries early enough to release the permutation before constructing the final adjacency arrays. The fixed native comparison improved from 0.849322 to 0.705578 seconds: about 16.9% less elapsed time. The RSS ratio was 0.997095, and the local coefficient proxy passed its gate.

The official trial was valid but scored 49.524627 machine points. The retained best was 50.424918. We restored the prior source.

Those official values are separate historical runs, not an interleaved experiment isolating the numbering change. The board observation was enough to reject that trial as an improvement over the retained best; it was not enough to explain the reversal. A later local diagnostic compared native and container execution contexts and still did not establish the cause.

This also changed how we described unchanged-source results. A repository push can run tracks whose source did not change. Our best recorded A and D values came from such runs. They belong in the measurement record, but their variation cannot be credited to a new algorithm. On the final day, the unchanged Track A source took 0.189345 seconds in one run and 0.146796 in the next, against its best of 0.130583.

Correctness evidence has a separate job

For the fused graph candidate, seven Rust property tests passed. One checked that parsing preserved the ordered rows in both directions. Another tested every directed three-node graph whose nine possible edges were absent, zero-weight or unit-weight: 19,683 graphs, with every source-target pair checked against Bellman–Ford.

The wider checks covered 117 adversarial and random graphs, repeated queries, large path sums, zero cycles and directed reachability. Seven host examples ran with one, two, six and twelve workers. Fresh tiny seeds 127 and 128 passed before reserved seed 129, with the source frozen. Published sample/full hashes and all fourteen measured or warm-up image outputs matched.

These checks made a performance comparison meaningful by ruling out the tested wrong-answer cases. They do not prove every possible input correct or turn a slower result into a useful optimisation. The graph invariants still have to hold: path sums remain 64-bit, reverse edges retain their own weights, and bidirectional search cannot stop merely because it found a meeting.

The entry at code freeze

Our last push before the November 2, 15:00 UTC code freeze was commit f00c64fca46bb4124462c053305a1395c596035f. It only updated the performance records; its source is the same as commit 29a57dc3752e417842e5bc2bf4796170c2ead170, which carried the parallel-parity change. The table lists the best live-board value for each track. The values come from different recorded runs, not a simultaneous four-track timing batch.

Track	Process time	Machine points	Run
A: Ingest	0.130583 s	61.431366	`run-8ed375c52049`
B: Index	0.918916 s	55.479075	`run-a9ce34cd1404`
C: Join	0.159350 s	57.219847	`run-596f68f709a3`
D: Traverse	0.723518 s	50.424918	`run-396084b71fdb`

The A and D bests came from pushes that changed other tracks, with their own source unchanged. C's best came from the final, documentation-only push, which re-ran the parallel-parity source; its first run had scored 57.147738. These are practice-board machine results, not final judging or an award: final scoring reruns the recorded commit on a held-out dataset, and judges contribute 35% of each track total. The per-track PERF.md files retain the unsuccessful comparisons alongside the accepted changes; MEASUREMENTS.json binds the best values to run IDs and source hashes.

For the next graph-construction change, the missing evidence is where the modified access pattern spends time. For the CSV pipeline, the open question is whether the board's 8% coefficient gain holds on the held-out dataset.

The implementations, validation and this article were developed with Codex; Claude Code added the November 2 board results. Algorithm references, measurement limits and assistance disclosures are retained in the entry repository. Task definitions and the official scoring procedure are published by Hackathon Raptors.

What the House Heard: a ghost story told by your smart home's sensor logs, offline with TabPFN and Gemma

Hyunsik Park — Thu, 29 Oct 2026 12:05:50 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

A house with sensors keeps a diary every night. CO₂ climbs when someone breathes in a closed room, the hallway motion sensor fires when someone walks past, a contact sensor knows when the front door opens. What the House Heard reads one night of that diary on your own computer and asks: who was in which room, minute by minute, and did anything turn up in a room that nobody walked to?

TabPFN, Prior Labs' tabular foundation model, estimates for every room and every minute how likely it is that a person was there. Anything that looks like a person in a room nobody reached through the hallway, while the bedroom is still occupied, gets flagged. Gemma 4, running locally through llama.cpp, then tells the night back as a short ghost story, and a fact check makes sure the story quotes only times and readings that are really in the logs.

That is how I read the theme: the ghost story is already in the machine, and the job is to let it out without the diary leaving the house.

The data in the demo is synthetic. A simulator writes seven ordinary nights for a four-room flat and one Halloween night with three events nobody can explain, plus decoys that look strange but are not: a cat that sets off motion sensors, a lamp left on after bedtime, a fridge compressor that hums every 45 minutes, and a resident who cannot sleep and sits in the dark living room.

Demo

Live report: https://hyunsikparker.github.io/what-the-house-heard/sample/report.html

TabPFN flagged exactly the three injected events and none of the decoys:

Time	Room	Why it is strange
02:47–02:55	living room	nobody crossed the hallway, the bedroom still looked occupied; CO₂ up 45.6 ppm in the dark (1.4 lux at most), sound up to 53.5 dBA, 7 motion triggers
03:12–03:19	kitchen	same pattern with the light on (82.3 lux) and CO₂ up 99.3 ppm
03:33	hallway	the front door contact opened and the hallway motion sensor saw nothing

The resident who sat in the dark living room at 00:51 and the walk to the kitchen at 01:58 came through the hallway, so they count as explained. The cat's walk at 04:18 was not flagged; in the simulation a cat trips motion sensors but adds no CO₂.

Here is part of what Gemma wrote from that evidence:

You lie in the dark, listening to the rhythmic breathing of your partner beside you. The house is silent until the sensors begin to betray your sanctuary. At 02:47, something moves in the living room despite no one leaving the bedroom. You hear a disturbance, a sound reaching 53.5 dBA, while the humidity climbs to 46.7%.

The boring explanation: A faulty sensor or a small pest is moving through the walls and vents, while a neighbor may have briefly propped the door open.

The report ends with: Fact check passed: 3 clock times and 6 readings in the story all appear in the evidence (attempt 1).

Code

HyunsikParker / what-the-house-heard

Offline ghost stories from smart-home sensor logs: TabPFN finds who was where, Gemma tells the night, a fact check keeps it honest. Synthetic data.

What the House Heard

A smart home records a lot at night: CO₂, light, sound, motion, the front door. What the House Heard reads one night of those logs on your own computer and asks a plain question: who was in which room, minute by minute? Anything that looks like a person in a room nobody walked to gets flagged. A local Gemma model then tells the night back as a short ghost story, and a fact check makes sure every time and reading in the story comes from the logs.

Built with PriorLabs-TabPFN. Made for the DEV Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine All data in this repository is synthetic (see simulate.py).

How it works

simulate.py writes seven ordinary nights for a four-room flat (labelled: which rooms had a person in them) and one unlabelled Halloween night. The ordinary nights include the things that…

View on GitHub

How I Built It

Occupancy with TabPFN. Each room-minute becomes one row with twelve features: CO₂ and its five-minute rise, how far CO₂ sits above the room's recent floor, light, sound above the room's median, motion over three minutes, temperature and humidity changes, the door contact, the time of night and the room. TabPFN gets a 3,000-row sample of the labelled nights as its context. There is no training loop: fit() stores the context and predict_proba() scores all 2,160 room-minutes of the new night. As a check, I gave it six labelled nights and asked about the seventh: it labelled every room-minute correctly. Simulated sensors are much cleaner than real ones, so I read that as "the pipeline works", not as a claim about a real home. Two fits (the check and the real night) take about a minute on the CPU of an M4 Mac mini.

From probabilities to ghosts. A room counts as occupied when TabPFN puts it above 0.5 for at least two minutes. The event is unexplained when nobody crossed the hallway in the three minutes before and the bedroom still looks occupied. "Crossed the hallway" means TabPFN's hallway probability or the raw hallway motion count, because during development the motion sensor alone missed a quick walk and turned a trip to the kitchen into a ghost.

The story with Gemma. Gemma 4 12B (QAT, Q4_0) runs in llama.cpp's server with thinking turned off. The prompt contains only the evidence: two residents in bed, the explained walks, and the flagged events with their readings. The rules ask for a second-person story of 150 to 220 words that quotes at least three readings exactly and invents nothing the sensors could not record. One story takes 25 to 45 seconds.

The fact check. Gemma is a good storyteller and a careless clerk. An early draft gave the kitchen "a sound up to 45.3 lux": the right number with the wrong unit, which my first, number-only check let through. The check now pairs every number with its unit (ppm, lux, dBA, %) and every clock time with an event window. When a story fails, the narrator asks again with the next seed, up to four times. Gemma also kept telling the reader they were alone in the house although the logs show two people in the bedroom; telling it that the reader lies awake next to the other resident fixed that. The check does not catch every flourish: the door still "clicks open" in the story, although a contact sensor records no sound.

Why Does Open Innovation Matter?

Sensor logs are a record of when you sleep, when you get up and when your home is empty. Here that record never leaves the computer: TabPFN runs on the CPU, Gemma runs in llama.cpp, nothing calls a hosted API, and the whole thing works with the Wi-Fi off.

Local weights also made the fact check cheap. Retrying a story with a new seed costs half a minute on my own machine rather than another metered request, so the pipeline can afford to reject a story over one wrong unit.

TabPFN's in-context learning suits homes, because every flat is laid out differently and nobody wants to train a model per household. In the simulation, six or seven labelled nights as context were enough.

A note on versions: Prior Labs recommends TabPFN-3.5, which needs a licence acceptance on their platform. I used TabPFN v2 because its weights run offline without an account; 3.5 uses the same scikit-learn interface.

Prize Categories

Best Use of TabPFN
Best Use of Gemma

Built with PriorLabs-TabPFN. All sensor data in the demo is synthetic. The code and this post were produced with Claude, Anthropic's AI agent.

FileNap: local Gemma file plans, with a way back

Hyunsik Park — Mon, 19 Oct 2026 23:22:14 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

FileNap is a local file-planning app for a small pile of receipts, notes and saved reading. Gemma reads short previews and proposes destinations. Each proposed move comes with a reason and an exact quote from the file. You review the plan, select the moves to approve, and keep a record that supports undo.

The chore it aims to reduce is opening files one by one to decide where they belong. The intended user is someone with a small inbox to sort who still wants to check the decisions. This prototype handles up to 16 files in one plan; it does not reorganize an entire drive.

Demo

Watch the recorded local demo.

The recording uses 12 fictional documents. Gemma proposed nine moves, kept a checklist in place and left two files for review: an ambiguous document and a deliberate prompt-injection example. After approval, the nine files moved into Receipts, Notes and Reading. Undo returned them to the inbox. A separate filesystem check confirmed that all 12 original SHA-256 hashes were restored.

Planning took 89.6 seconds on an Apple M4 Mac with 32 GiB of memory. The 42.6-second edit removes most of the model wait and slows the review steps. The same page includes the 111.3-second full recording at its original timing, with English captions for both versions.

These are fictional test documents, not evidence of accuracy on personal files or time saved in everyday use.

Code

Source code, tests and run instructions.

The application is a new Python project started during this week's build window. It uses the standard library, a local Ollama runtime and a browser interface. The application code is MIT licensed; model weights are not redistributed.

How I Built It

Gemma supplies the content-based decisions. File names such as paper_001.txt do not tell the app whether a document is a receipt, a note or something to read. The model receives the selected names, text excerpts, folder goal and permitted destinations, then returns a structured plan.

The recorded run used a cached Gemma4 11.9B Q4_K_M model with thinking disabled. Its manifest and weight hashes are documented in the README. The public Ollama tag had changed by the time of verification, so the shared tag name alone does not reproduce these exact cached bytes.

The file-operation code checks model IDs, destinations, source quotes and the saved file state. Applying a plan requires approval. Moves preserve existing destination files, and undo leaves a conflict visible if a moved file has changed or its original name has been recreated.

An undo-collision test caught a bug where the journal could report an incomplete undo as finished. That case now preserves both files, reports the conflict and supports retry. The final 19 tests passed on macOS and Linux/WSL2, including interrupted moves, edited files, collisions and local HTTP boundaries.

A correct quote can still accompany a wrong classification. FileNap keeps review in the flow. It is a working prototype, and its recovery tests do not cover every possible filesystem race.

Why Does Open Innovation Matter?

The open-weight model lets this project run its inference locally with a documented model artifact. FileNap's client accepts only a loopback model endpoint, does not follow redirects or use environment proxies, and has no hosted fallback. Development used Ollama with cloud features disabled and an already-cached model, without an inference API key.

Open source also makes the decision boundary inspectable: the prompt, validation checks and code that moves files are in the repository. The model makes suggestions; the application records approved actions. Someone adapting the project can examine both parts before trusting it with a folder.

Prize Categories

Best Use of Gemma.

AI assistance: Codex assisted with implementation, tests, demo preparation and this submission draft. The results above come from local test and recording evidence. No personal documents or private agent-session transcript are included.

OutingFold: a pocket field guide that shows what Gemma left out

Hyunsik Park — Mon, 05 Oct 2026 21:16:08 +0000

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

What I Built

OutingFold turns park notes into a small field guide you can fold and take outside. Paste the source text, let local Gemma suggest useful excerpts, review the selection, then save an offline page or print it.

The card has places for practical details, things to look and listen for, cautions, and a detail you notice yourself. It is for a short visit where a few source excerpts would be useful and another open browser tab would not.

The difficult part was deciding what a model should be allowed to put on that page. A fluent summary can drop the second half of a warning. An exact quotation can do the same thing if it leaves out the next sentence. OutingFold therefore shows the lines the model left out alongside the ones it chose. Both need review before export.

Demo

Open OutingFold. No account or installation is needed for the recorded example or manual selection.

Click Try the park example. This loads an actual saved response from gemma4:12b-it-q4_K_M, using nine excerpts from the National Park Service's Theodore Roosevelt Island page. It does not run inference in the browser.

The response leaves the ranger-program paragraph out and puts two trail-surface descriptions under “Look and listen.” To try the review controls, add S2 and move S6 and S7 to “Plan the visit.” Read the remaining source lines, tick the review confirmation, and continue to the Save step to download or print. Those edits produce the example below; they are reader edits, not a better model response.

The downloaded HTML keeps all the pasted notes, including omitted excerpts, in an expandable section. It has no scripts or external assets. The printout keeps only the selected excerpts and space for handwritten observations.

Download that PDF. This is a browser-generated PDF, not a photograph of a field trial. I have not tested OutingFold outdoors or on a physical printer.

Code

Source, setup and test records · MIT license

This is a new project begun on October 5 for Week 1. The app uses plain browser modules and a Node server, with no npm dependencies. To run fresh selections, install Node.js 22 or later and Ollama, then:

git clone https://github.com/HyunsikParker/outingfold.git
cd outingfold
ollama pull gemma4:12b-it-q4_K_M
npm start

Ollama must be running. Open http://127.0.0.1:4318. The model download is roughly 8 GB; the recorded run used an Apple M4 with 32 GB RAM. Smaller machines have not been tested.

How I Built It

Each source line gets an ID. Gemma reads those lines and returns a short JSON selection:

{"picks":[{"id":"S6","section":"plan"},{"id":"S9","section":"care"}]}

That is an illustration of the format, not a recorded response. The actual prompt, schema and raw outputs are in the repository.

The application validates the IDs and sections, then copies the original substrings. It rejects unknown IDs, duplicate IDs and extra fields. There is no field for generated card prose. Length limits keep the selection small enough to review, and exports stay disabled until the reader confirms that review. Changing a source line or selection clears the confirmation.

The first completed evaluation exposed the gap between exact copying and useful selection:

Predeclared case	What happened	Request time
NPS park excerpts	Retained the selections required by the test	8.533 s
Synthetic closure and exception	Kept the restriction and its qualification	10.835 s
Sparse observation notes	Returned no selections and missed two relevant lines	3.490 s

The run stopped at that failure. A fourth, prompt-injection case was not run. One earlier request had been cancelled without a result. The complete report includes the failed case; these three examples are too few to estimate general accuracy.

All completed responses passed the source-copy check, but the empty response passed it by selecting nothing. That check alone would make a poor success metric. The interface now tells the reader when Gemma selects nothing and lets them choose from the unchanged source. It also leaves empty card sections explicitly marked as having no selection.

Nine software tests pass without running a model. They cover source copying, invalid selections, limits, HTML escaping, retention of omitted notes, and local API boundaries. Browser checks covered source edits, manual recovery, downloads, keyboard focus, 320 px and 390 px viewports, the three-step editor, and the one-page A4 example shown above.

Why Does Open Innovation Matter?

The model runs on the reader's computer through Ollama. After downloading the weights, this selection step needs no hosted inference account or API key. The app sends notes only to its loopback server and local Ollama, which is useful when the notes contain private plans. The public demo does not send typed notes to a model.

An API could perform the same selection task. Running open weights locally gives this version control over where the notes go and avoids a per-request inference charge. The tradeoff is real: a large initial download, memory requirements, and speed that depends on the machine. This prototype uses one fixed model; changing it requires changing the code and retesting.

The prompt, validation rules, failed response and export code are available together. A reader can inspect why a line appeared on the card and repair a poor selection without waiting for another model call. The app's job ends when the reviewed page is saved. The blank fourth panel leaves something for the visit itself to supply.

Prize Categories

Best Use of Gemma. Gemma performs the local excerpt selection in the running app. The hosted example preserves one real response from the recorded evaluation.

AI assistance and sources: I used OpenAI Codex to help develop the code and write-up. The woodland image was generated with GPT Image and is an illustration, not a photograph of the example park. Test results above come from the saved run and software/browser checks. The park example quotes NPS text, retrieved October 5; it is a collection of excerpts, not the entire page or a current conditions report. No claim to original U.S. Government works. OutingFold does not verify the source or plan a route; check hours, closures, weather and access before leaving.

ShiftCal: a local Gemma roster reader for someone close to me

Hyunsik Park — Mon, 05 Oct 2026 01:04:11 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

Someone close to me finds it cumbersome to move a rotating shift roster into a calendar. ShiftCal takes their own shifts as text, uses local Gemma to read the dates and shift types, and prepares a calendar file after they check each row.

A night shift makes the problem concrete. 31일 나이트 means a night shift on the 31st. With the example hours of 23:00–07:00, an October shift ends on November 1. Typing the wrong end date would leave a misleading calendar entry. ShiftCal calculates that boundary in tested code and shows both dates for review.

The real-person need is confirmed. The schedules shown here are fictional, and I have not yet collected feedback from the recipient.

Demo

Open the interactive recorded demo.

Click Try a recorded example. The fourth row, 4일 이브닝?, stays unresolved. Correct it to Evening only if the original roster confirms that shift, or remove it. Check each remaining row to enable the calendar export. Day-off rows stay visible but create no event.

The public page replays a saved response from an actual Gemma run; it does not host inference. To process new text, follow the local setup in the README. The app needs Python and Ollama, with no Python or JavaScript packages. It currently accepts text only and uses Korea Standard Time.

Code

Source, setup and tests on GitHub · MIT license.

How I Built It

Gemma (gemma4:12b-it-q4_K_M, through Ollama) extracts a day and a D/E/N/O shift code from each Korean or English input line. Each result remains beside its source. Missing or duplicated model rows are flagged; explicit uncertainty stays unresolved.

JavaScript handles dates, shift hours and iCalendar formatting. It rejects invalid dates, duplicate dates and overlapping shifts. Changing a row or its settings clears the relevant confirmation. Export stays blocked until the remaining rows are valid and checked. There is no automatic calendar sync.

The Python server listens on loopback, calls a fixed local Ollama address and rejects foreign origins and Host headers. It limits input size and handles one extraction at a time. It does not log or save roster text. Users are asked to leave out names, workplace details and other people's shifts.

Fifteen unit tests passed, including month and year boundaries, leap years, overnight overlaps, uncertainty and server access checks. Four synthetic fixtures also went through the actual model: three matched exactly, with 13 of 14 date/code pairs matching overall. In the remaining row, 주간 had no date. Gemma left both fields unresolved instead of retaining the expected day-shift code. The row remained visible and could not be exported. These are small functional checks, not an accuracy benchmark.

Desktop and mobile layouts were checked, along with a fresh three-line extraction in the browser. Calendar-app import and recipient field testing remain unverified. Reimporting a file may create duplicates; the app recommends a separate calendar.

Why Does Open Innovation Matter?

An open-weight model makes local roster processing possible without sending each schedule to a hosted model service. Open source makes the boundary around that model visible: the prompt, schema, validation and export code are all in the repository. Someone adapting ShiftCal can change the shift hours or inspect a date calculation without depending on a private API.

The first model download needs an internet connection and disk space. Local inference still needs suitable hardware and electricity; the application has no per-request service charge.

Prize Categories

Best Use of Gemma. Gemma performs the Korean and English roster extraction in the local application. The public demo includes a recorded response from that same implementation.

AI disclosure: Codex generated and revised the implementation, tests and prose under my direction. I supplied and confirmed the real-person problem. Executed tests and model responses were checked; no interview, testimonial or field trial is claimed. This entry uses the Fully Autonomous development disclosure.

Constraint Clerk: A Source-Cited Changeover Agent

Hyunsik Park — Sat, 03 Oct 2026 15:13:18 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

Fully Autonomous AI build. Codex generated and revised the implementation, original fictional records and this writeup. The verification below is an actual Sanity Content Agent response. No human coding or venue experience is claimed.

What I Built

Constraint Clerk checks a changeover plan for a fictional pocket theater. A cart needs to reach backstage before an 18:12 cue. The September survey records a 940 mm passage, but an October sound screen reduces it to 690 mm. The unfolded cart is 880 mm wide.

Finding both numbers is not enough. The agent must identify which claim applies, follow the explicit supersession, then combine width with cart state, preparation time, route duration and crew availability. Folding makes the cart narrower, but requires two crew and three minutes of preparation. The wider east passage has a timed closure. The west passage has no measured width.

The output separates blocked, feasible and unknown, with source records for each check. It never converts a missing measurement into permission to proceed. All venue and equipment records are original fiction, not a real inspection or safety assessment.

Demo

Open Constraint Clerk — no login required.

Start with View recorded AI verification. It loads the real October 3 response, its calculated result and the retrieval trace. Expand Full actual answer and Actual retrieval trace to inspect them. Selecting a source opens the original record, including the superseded survey.

The public demo is static: viewing the recording makes no new AI request. The other controls run the local checker. Changing inputs clears the recorded response, so a local result cannot be mistaken for a fresh model answer.

Example	Result	Verification scope
Original unfolded cart, north route	Blocked: 880 mm cart, 690 mm passage	Real Content Agent + Context conversation; also locally reproducible
Folded cart, same route and two crew	Feasible against the documented constraints; finish 18:10	Local deterministic check only
Folded cart, unmeasured west route	Unknown; width evidence is missing	Local deterministic check only

Code

Source repository · MIT licensed.

The React interface, TypeScript checker, local agent server, Sanity Studio schema and pinned lockfiles are included. The README explains how to run the local demo and reproduce the cloud integration with a separate project and your own credentials. 21 local tests pass, including source supersession, closure boundaries, missing measurements, canonical reference recovery and transport limits. Type checking and the production build pass.

How I Used Sanity

One dataset, two scoped Context endpoints

The Content Lake holds 19 fictional documents: 11 ccSource records and eight ccClaim constraints. A claim stores its target, property, value, effective date and optional supersedes reference. Routes refer to passages; folding requirements and crew rosters remain separate records.

A Knowledge Base was built from that dataset. One read-only Context MCP endpoint exposes only the KB. A second exposes only the project's ccSource and ccClaim records. The agent uses Sanity Content Agent through the AI SDK, with built-in read, write and web search disabled.

The request follows this path:

The harness reads the KB outline and exposes knowledge_base_read to the model.
The model reads a relevant KB entry, then calls the custom check_plan tool.
check_plan queries the live dataset using Context's groq_query, restores canonical reference arrays using array_field_reader, validates the typed records and runs the checker.
The model explains that result with exact source document IDs. The structured result is authoritative for the selected plan.

The actual result

One live conversation on October 3 made four model HTTP requests and four agent tool calls: two KB reads and two plan checks. Each plan check retrieved 19 structured records and restored four canonical reference arrays.

The final answer cited cc-claim-north-current for 690 mm and cc-claim-north-old for the explicitly superseded 940 mm survey. It blocked the 880 mm unfolded cart, a 190 mm shortfall. The roster and 18:07 calculated finish passed; width was the blocker.

The response also kept its scope: it described folding's requirements but did not claim to have evaluated the folded variant. That alternative is shown separately as a local check.

Where retrieval needed a stricter boundary

Context can outline an array instead of returning its full contents, even when it has one reference. The first adapter rejected that output rather than calculating with incomplete links. The corrected adapter reads each outlined array through array_field_reader and checks its document ID, field, count, indices and cropping flags. A truncated response fails closed.

The KB also has one reviewed, unresolved issue: a derived east-passage entry omits a closure interval that exists in the original structured source. The issue has not been dismissed. Exact intervals and measurements come from the validated records, not generated KB prose. The saved dataset was read back and matched the original seed's full typed-content hash.

Cost and runtime limits

The project was automatically assigned a USD0 Growth Trial, with automatic downgrade to Free after 30 days. Only Free-included features were used; there was no paid upgrade or hosting purchase. Paid overages were disallowed.

A durable one-conversation permit was reserved before inference. Limits were four model requests, four agent tool calls, 90 seconds, no SDK retries and 512 KiB per model response. The provider has no token-output cap, so none is claimed. No further live attempts were made. Immediately afterward, the usage screen still showed 0/1,000 credits and USD0; the settled consumed-credit count was not yet reflected and is not claimed to be zero.

The public site has no model endpoint or tokens. The optional agent server is loopback-only. The README discloses two low-severity production dependency advisories and 12 separate Studio/CLI advisories, including the mitigations and remaining limits. No all-clean security audit is claimed.

Sanity Project Details

Project ID: r7tbo2j3
Dataset: production (public, original fictional records)
Document types: ccSource, ccClaim
Knowledge Base: Constraint Clerk — North Pier Room (kb4e4xT6fMwh)
Dataset source filter: _type in ["ccSource", "ccClaim"] && _id match "cc-*"

This is a separate project from the Path Two entry. Neither its content nor its submission was changed for this build.

Agent Session

The public recorded verification contains the actual question, selected plan, answer, structured result and timestamped retrieval trace. Its answer and trace match the original private run receipt. Credentials, private paths and unrelated work are excluded. This is the application agent's verification record, not an uploaded coding-session transcript.

The integration follows the official Sanity Context MCP, Knowledge Base and Content Agent interfaces.

Alibi Atlas: A Continuity Workbench for Fiction

Hyunsik Park — Sat, 03 Oct 2026 09:22:23 +0000

An entry for the Sanity Challenge — Path Two.

What I Built

Alibi Atlas is a continuity workbench for fiction. It asks a narrow question: can a character be where the scene puts them?

The starter case, The missing lantern, has three characters, four places and six events. Mira appears at the archive and the dock at overlapping times. Theo has four minutes to make a ten-minute journey. Jules says they visited the dock, but that statement is not treated as an established scene.

The app puts physical conflicts beside a timeline and a diagram of authored routes. Select an event, try different times or a different place, and see which conflicts remain. These preview changes stay in the browser; they do not rewrite the author's Sanity content.

It is a tool for checking a fictional draft, not for deciding whether a real person's account is truthful.

Demo

Open Alibi Atlas — no login needed.

Try this short walkthrough:

Select Checks the departing boat. Change its time to 18:34–18:44, then choose Apply to preview. Mira's overlap is resolved, with enough time for the eight-minute journey.
Select Delivers to the keeper and try 18:30–18:38. The second physical conflict disappears.
Select Jules's account needs a decision. Change it to This happens in the story. A new overlap appears: the keeper is now established at the tower and the dock at the same time.
Reset preview restores the loaded story. Inspect report JSON shows the case, changes, findings and source metadata for inspection or manual copying.

Example preview report · 390px layout

Code

GitHub repository — MIT licensed, with local setup, Studio instructions and tests.

The public viewer is a Next.js static export on GitHub Pages. It reads the real public Sanity dataset through @sanity/client. Studio runs separately for authenticated authoring. No write token is bundled into the viewer, and there is no runtime AI call.

My Build Process

Codex generated and revised the implementation, fictional case, documentation and this article. This is a record of an autonomous AI build, not a claim that I wrote the code by hand or a verbatim prompt transcript.

The brief and the schema

The working brief, paraphrased, was to build a fiction-continuity editor backed by real Sanity content. Characters, places, journeys and scenes needed their own documents. A character's statement had to remain separate from an event established by the author. Readers needed to test corrections without changing the published story.

That distinction became an explicit certainty field rather than something inferred from the wording of a scene. Each event also keeps the author's scene or dialogue note visible in the inspector.

Document	Count	What it records
Character	3	Name and role
Place	4	Name and diagram coordinates
Journey	4	Two place references and a minimum time
Story event	6	Character, place, interval, certainty and source note
Case	1	Time window and references to the other documents

The case references those documents instead of storing the story as one block of prose. A GROQ query dereferences them into the graph used by the workbench. Journey times are authored constraints, not estimates from map coordinates. The analysis uses the shortest connected, undirected route; a missing route stays unknown and appears as a review item.

Where the early attempts broke

An initial-value resolver tried to use context.documentId. TypeScript rejected that API. The replacement uses fixed starter IDs and explicit initial-value templates. The starter tool creates the 18 linked documents through the authenticated Studio client and reads them back without overwriting existing documents.

The first architecture put Studio inside the Next.js app. It was separated so the public reader could be a static export while authoring retained its authenticated session. This build uses the Sanity client and Studio, not the App SDK or Sanity Workflows.

The first all-clear wording was too strong when a route could be missing. It now says only that no physical conflicts were detected under the authored constraints. Unknown journeys still need review.

Browser checks also caught a stale validation message after reset. Reset now starts a fresh inspector without remounting it on every input change. The time-input automation changed displayed values without updating React until native key input was used; the final correction checks used keyboard input.

What was checked

All 12 domain tests passed, including nested overlaps, route choice, reported accounts, missing routes and invalid references or intervals. The public Pages workflow passed tests, type checking, the static build and deployment. At 390px, the page had no horizontal overflow; the timeline scrolls inside its own container.

A published description change produced the live-update notice and kept an in-progress preview. An actual Studio event edit reduced the public viewer from two physical conflicts to one after refresh, without preview edits. That test edit was then restored. A complete case readback matched the pre-test snapshot, and the dataset again contained the original 18 documents.

The visible report was read back with two preview edits, zero physical conflicts and one reported-account review. Browser automation did not confirm a completed file download or clipboard contents, so neither is claimed from the buttons alone. The inspectable JSON and linked example make the payload available directly. The controller also stalled on a dirty-preview refresh confirmation; a separate reader verified the new published content, and clean-preview refresh worked.

The prototype handles one case and one time window. It does not infer travel times, prove a statement is true or review every kind of plot hole. The aim is to expose contradictions the author can inspect, with the underlying event and source note still visible.

Sanity Project Details

Project ID: 0k0a3q37
Dataset: production — public, original fictional demonstration content only.
Published documents: 18 across the five schema types above.

The viewer queries published content without a token. Sanity remains the authoring source: publishing a change raises a notice, and the reader chooses when to reload it. A connected query failure shows an error instead of silently substituting the local fixture.