Start your day with intelligence. Get The OODA Daily Pulse.
Informing your decisions with actionable intelligence
Start your day with intelligence. Get The OODA Daily Pulse.
Informing your decisions with actionable intelligence
A few weeks ago I introduced a new capability we are building for the OODA Network we call The Demand Signal, a procurement intelligence product that leverages the power of an NVIDIA DGX Spark to produce insights for tech companies seeking to serve federal government missions. We are still building but the project is already delivering value for the network. This post provides an update as well as some lessons learned from building it which can inform your use of local models as part of integrated solutions.
The Demand Signal brings in multiple authoritative data sources on government procurement. These are the same data sources used by commercial firms that repackage and sell this data to startups (including feeds from government procurement sites like SAM.gov). Our DGX Spark evaluates these, ranks them for relevance and categorizes them by topic. A web app receives a feed from the Spark and presents the results in ways useful to high tech companies seeking to improve service to government missions.
Four sources feed it now: SAM.gov, Department of War contract announcements, DoD SBIR/STTR topics from the defense SBIR portal, and NIH/HHS funding opportunities from Grants.gov.
The site enables full-text search across every procurement, a daily archive going back to launch, RSS feeds per edition and site-wide, and a sign-up flow using the same platform OODA Network membership already runs on so our members can easily access.
The architecture is simple to describe but took real trial and error to get right. A Mac holds the code of record and is the GitHub remote. A DGX Spark runs the pipeline: ingestion, extraction, local inference, against its own local Postgres database, which is the system of record. Railway hosts the public site and a second Postgres that is sent what the web app needs to display results to users, plus two years of trailing history, refreshed nightly. The full corpus stays on hardware OODA controls. Railway stays small and fast, because serving a website and archiving a corpus are different jobs that don’t need the same database.
Code moves from the Mac to the Spark by rsync commands, and from the Mac to Railway by a git push that Railway auto-deploys.
OpenClaw runs on the Spark as the orchestrator behind ingestion, extraction, and drafting. It also runs Archie, an agent I talk to, and Archie has become the part of this whole system I interact with the most.
Every morning Archie sends me a daily briefing straight off the Spark: what came in overnight, what got flagged, what changed in the corpus since yesterday. It’s reading directly from the system of record, not from whatever’s been projected out to Railway yet, so it’s the freshest possible look at what the pipeline actually did. This ensures I get a look at what the system is doing so I can catch anthing I might want to recategorize.
The more useful part is how Archie can help me when something falls through the cracks. If a procurement item gets ranked wrong, too high, too low, doesn’t matter, I tell Archie to demote it, and it does. That’s a real write against the database, not a suggestion I then have to go apply somewhere else myself.
Archie’s write access stays narrow on purpose. It can adjust the things I actually need to touch day to day, like a ranking. It can’t touch ingestion or extraction logic; that stays code, reviewed and committed the normal way.
Although most AI work we are doing is done on a local model, I found it better to empower Archie with more brainpower. So underneath, Archie defaults to Claude Sonnet as its brain, with a heavier model available for harder questions. Archie can still use the local model on the Spark as a fallback, but I enjoy the quality and speed of frontier models for the kind of tasks he has.
Archie handles the corpus day to day. A different AI handles the build itself.
Most of the coding is done by a Claude project. To borrow a term I learned from Ken Huang, my role in this project is as a Harness Engineer. I spent a great deal of time configuring the project with instructions and guidance and references to ensure it does things my way. Then I direct what is to happen and engineer the production of code. Claude writes based on my objectives and commits code on the Mac code repository clone through a sandboxed connection. I deploy the code, run migrations, and touch anything that needs a web UI or credentials Claude doesn’t have. That split is clean.
The thing I’d most recommend copying, independent of anything DGX Spark-specific, is how we keep one living document. We call it STATE, and every session is told to read it before doing anything else. It holds only current truth: what’s built, what’s open, what’s next. The reasoning behind any of it, the failed attempts, the “why did we do it this way,” lives in dated session notes that STATE links out to.
What actually matters is that STATE corrects itself in the open. When something it asserted turns out wrong, the fix goes in as a labeled correction, not a quiet edit, so the next session (human or Claude) sees the mistake and the fix together instead of inheriting a clean-looking answer that hides how we got there. Standing rules get repeated verbatim across notes so they survive between sessions, and we track how many times a given rule has actually paid for itself rather than treating it as settled after the first time it mattered. It’s a small habit, and it turns a coding assistant with no persistent memory into something closer to a colleague who’s actually been on the project the whole time.
If you’re setting one up, expect to lose time to the unified memory before anything else. If a client times out while a model is loading, Ollama aborts the load, but the memory doesn’t come back. It leaks into the driver, invisibly, because this hardware can’t even show you GPU memory usage the normal way. The only symptom is that everything queues forever while the health check still answers fine. The only fix is a reboot. We ended up pinning the keep-alive setting, capping timeouts, and running a watchdog that checks a lightweight metadata endpoint before ever risking a real generation call.
Don’t trust localhost either. On this hardware, plain localhost can resolve to an IPv6 address that isn’t what you meant, and the hostname itself resolves through the router to several stale addresses. We pin everything to 127.0.0.1 explicitly and ban the string localhost from config entirely.
And the setting that’s supposed to keep a model warm doesn’t do what you’d assume. Ollama’s native API respects a keep-alive flag; the OpenAI-compatible endpoint most tooling actually talks to ignores it completely. We lost real time to that before finding it needs to be set per request instead.
One more thing worth knowing before you commit to a model. We planned to run GPT-OSS-120B, tested it against Nemotron 3 Super once the hardware arrived, and switched: better long-context handling, better agentic behavior. Then the production pipeline ended up back on GPT-OSS after all, because only one 120-billion-parameter model can stay resident in memory at a time, and Nemotron was what we wanted for interactive work instead. The two models split jobs rather than one replacing the other, which isn’t what we expected going in.
Every feature beyond the free daily front page sits behind OODA Network membership, using Memberful for sign-in: one click, no new password. We don’t store anything about user’s membership on our own servers. Memberful stays the one place that’s true, and we just ask it the question at sign in. If you’re not a member yet and you land on an edition page, you don’t get bounced to a login screen. You get a real page telling you what’s actually there right now, updated nightly, so you know exactly what you’d be unlocking.
Members see the whole graph: every edition, full search, the complete archive, the feeds. It’s the same door the rest of OODA Network membership opens, not a separate paywall bolted onto this one product.
We will keep building, adding new data sources, and taking feedback from members on what they want next.
Stay tuned for more! And please kick the tires on the site yourself. Non-members can get a good overview of what the government is buying. Members can dive deep into the entire graph and get pointers to the full documentation on what the government needs from the high tech world.
For more see: demandsignal.oodaloop.com
About the Author
Informing your decisions with actionable intelligence
Informing your decisions with actionable intelligence