This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.
What I Built
I built VoiceStack Atlas, a deployment planner that keeps old speech-tool documentation in its own era. It asks for a runtime profile, reads structured compatibility rules from Sanity, and returns decisions tied to original, commit-pinned sources.
The interesting case is CUDA 12 with cuDNN 8. A generic “GPU requirements” search can surface different documentation eras. The current faster-whisper README documents a specific CTranslate2 workaround; the v1.0.0 README describes a different CUDA stack. I model the condition and documentation status separately, so a historical fact cannot become today's installation instruction.
The same distinction applies to audio: built-in file decoding does not mean an 8 kHz NumPy array will be resampled. The planner separates those paths and reminds the caller that transcription starts when the segment generator is iterated.
Demo
Try CUDA 12 / cuDNN 8 / Raw NumPy array, then change CUDA to 13. The second profile should ask for more evidence rather than inventing an installation command. Switch to CPU and file input to see GPU requirements disappear.
The deployed Astro app reads the public Sanity dataset without a login or browser token. I verified the current CUDA 12 / cuDNN 8 / array profile, the unsupported CUDA 13 profile, and CPU / file input against real Content Lake documents.
Open the full-size screenshot.
Code
Source code and reproducible checks.
Original compatibility annotations, constraints, interface, and evaluation are my work. Public faster-whisper documentation and source code are credited and preserved under their upstream MIT license. No employer code, recordings, datasets, or credentials are used.
My Build Process
I started by asking for conditions, conclusions, actions, and provenance to be separate fields. A polished answer is not useful if it mixes a release-era requirement with a current requirement.
I used the Codex desktop IDE to build a narrow planner and source validation first, then an Astro interface. The build instructions evolved from a real Context-connected agent to a directly verifiable structured-content app. This is a summary of the iteration, not a verbatim prompt transcript: separate conditions from conclusions; preserve literal evidence from pinned files; refuse unsupported profiles; and verify Sanity reads before publishing. An early assumption about the historical README failed its literal evidence check. I corrected the annotation against the actual pinned file. That failure shaped the design: source checks are part of the workflow, not a decorative citation after the answer.
I initially attempted Path One with a Sanity Context Knowledge Base. Public website ingestion succeeded, but the completed build exposed no readable entries, and endpoint creation returned a not-found page. I did not present the offline planner as a working MCP agent. I prepared a direct Content Lake version in Astro instead, because its structured decision model is valuable without a live model loop. The Context harness remains experimental code, not a claimed completed agent.
The second correction was operational. I created source and compatibility-rule documents in a personal public Content Lake dataset, added a native source reference, and configured credential-free browser reads. An import token stays in a local ignored environment file. The frontend has no token and fetches the live rules on each resolution. I checked three profiles against the live dataset before switching the public deployment from the earlier offline prototype.
I kept the decision engine deterministic: a runtime profile must satisfy every applicable condition, and historical records only appear in a separate context section. This makes the result traceable and gives unsupported combinations a useful failure state. I did not use App SDK or Workflows; the scope is an Astro frontend over structured Sanity content.
How I Used Sanity
The Content Lake model has two document types. source stores repository, ref, commit, original URL, and license. compatibilityRule stores when, status, claim, action, and a native sourceRef reference to the pinned source document. Conditions combine device, CUDA major, cuDNN major, and audio input format. The historical/current status is independent of those conditions.
The Astro frontend reads those documents through public GROQ queries and applies all conditions together. It displays an error when Sanity is unavailable; no cached compatibility answer is silently substituted. Tokens used for import stay on the server side and are never shipped to the browser.
Sanity Project Details
Project ID: jud8maoc. Dataset: production.
Inspect the public dataset. It contains four source documents and eight original compatibility rules. No credentials are required.
For example, a rule combines device: cuda, cuda: 12, and cudnn: 8, with status: current, an evidence literal, an action, and sourceRef pointing to a commit-pinned document. A source reference is shared provenance; the historical/current field controls whether the rule can drive a current decision.
Validation and Limits
Local checks cover current versus historical dependency selection, missing versions, unsupported combinations, CPU separation, file versus array handling, and missing or unknown citations. Each curated evidence literal was checked against its pinned upstream file.
I have not run GPU inference or claimed speed, memory, or speech accuracy results. This tool is a deployment planning aid, not proof that a dependency stack works on every machine. The Context prototype has not passed a real retrieval run, and is not the finished submission.
Top comments (0)