DEV Community: Victor

Nebula Agent: An AI That Surfaces Contradictions in Structured Content

Victor — Sun, 27 Sep 2026 10:27:07 +0000

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

What I Built

A Sanity-powered AI agent that answers questions about a fictional board game called Nebula and, crucially, surfaces contradictions between sources.

The agent doesn't just search for keywords. It writes its own GROQ queries(Graph Relational Object Queries) against a Sanity Content Lake in real time, reads the structured articles it retrieves, and when two sources disagree and presents both claims side by side with their source URLs.

The core question:

"According to the Nebula rulebook and errata, how many energy tokens do players start with? Are there any contradictions?"

The agent's answer:

The sources provide conflicting information:

Nebula Core Rulebook - Setup states players start with 5 energy tokens (source)

Nebula Official Errata v2.1 corrects this to 8 energy tokens (source)

A keyword search would have returned both articles. It would not have known which was authoritative, nor that the errata corrects the rulebook. My agent does this because the content was structured.

Demo

Since the agent runs in the terminal, here's a live transcript from two consecutive runs.

Question 1_Energy tokens:

text
👤 User: According to the Nebula rulebook and errata, how many energy tokens
   do players start with? Are there any contradictions?

🤖 Agent using tool: query_documents
   Args: {"query":"*[_type match \"*rule*\" || _type match \"*errata*\" || lower(title) match \"*rule*\" || lower(title) match \"*errata*\"]"}
   Result preview: [{"_type":"article","body":"To win Nebula, you must collect 10 stars..."}]

🤖 Agent: According to the Nebula rulebook and errata, there is a contradiction
regarding how many energy tokens players start with:

* Nebula Core Rulebook - Setup: States that each player starts with 5 energy
  tokens. Source: https://example.com/nebula-rulebook

* Nebula Official Errata v2.1: States that the core rulebook is incorrect and
  that the correct starting amount is 8 energy tokens.
  Source: https://example.com/nebula-errata

Question 2_Win condition:

👤 User: What is the win condition for Nebula?

🤖 Agent using tool: query_documents
   Args: {"query":"*[_type == \"article\" && (title match \"*Nebula*\" || body match \"*Nebula*\")]{title, body, source}"}
   Result preview: [{"body":"Many players struggle with energy management..."}]

🤖 Agent: The sources provide conflicting information regarding the win
condition for Nebula:

* According to the Nebula Core Rulebook and the strategy guide, you must
  collect 10 stars to win (Rulebook, Strategy Guide).

* According to the Nebula Official Errata v2.1, the win condition was updated
  to collecting 12 stars (Errata).

Code

Vicarioy / sanity-nebula-agent

Nebula Sanity Agent

A command-line agent that uses Gemini to answer questions from article content stored in Sanity.

How It Works

The agent checks its Sanity connection, sends a built-in question about Nebula's win condition to Gemini, and answers using Sanity query results. It can query documents with GROQ or list the dataset's document types and fields. Its instructions require source URLs for claims and ask it to show contradictory sources side by side.

The command prints the question, connection status, tool name, a result preview, and the final answer. Query arguments are not printed. Errors are written to stderr.

Stack

Node.js with ES modules
Gemini model gemini-3.5-flash-lite
Sanity project uyvc8si1, dataset production
GROQ for Sanity queries

Setup

Run these commands from the agent directory:

npm install

Create an .env file in the agent directory with both keys:

GEMINI_API_KEY=your-gemini-api-key
SANITY_API_TOKEN=your-sanity-api-token

The Sanity token must have…

View on GitHub

Stack:

Node.js

Gemini 3.5 Flash Lite (free tier)

@sanity/client for GROQ queries

@google/genai for function calling

How i used Sanity

** Structured Content Model**
i defined a single document type in sanity studio using typescript:

export const article = defineType({
  name: 'article',
  title: 'Article',
  type: 'document',
  fields: [
    defineField({ name: 'title',  title: 'Title',  type: 'string' }),
    defineField({ name: 'slug',   title: 'Slug',   type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'body',   title: 'Body',   type: 'text' }),
    defineField({ name: 'source', title: 'Source', type: 'url' }),
  ],
})

I populated it with three documents that set up a deliberate contradiction:

The title and the source for each of the documents are:
Nebula Core Rulebook; The Setup - https://example.com/nebula-rulebook

Nebula Official Errata - https://example.com/nebula-errata

How to Win at Nebula - https://example.com/nebula-strategy

(The source URLs are placeholder examples. In a real deployment, this field would point to the actual publisher page.)

How the agents read and queries Content

The agent uses function calling with Gemini. It has one primary tool and it was coded out with javascript:

{
  name: "query_documents",
  description: "Run a GROQ query against the Sanity dataset. Returns JSON.",
  parameters: {
    type: "object",
    properties: {
      query: { type: "string", description: "A GROQ query string." }
    },
    required: ["query"]
  }
}

When the User asks a question, the LLM:

Writes a GROQ query itself: an example- *[_type == "article"]{title, body, source}
My code executes it via @sanity/client against project uyvc8sil, dataset production
The JSON result is fed back into the LLM's Context
The LLM reads the content and answers with citations

The system prompt tells the model:
"When two sources contradict each other, show both claims side by side with their sources. Cite the source URL for every claim. Never invent information."

What the agent does with retrieved content

Because the content is structured, the agent can do the following:

Compare specific fields across documents; it reads body from the rulebook and body from the errata and notices the numeric values differ.
Attribute each claim to its source URL; the citations aren't guessed, they're data.
Distinguish types of documents; the errata is authoritative over the rulebook because its title says so.

A plain-text search would have surfaced both documents but had no way to reason about which was newer, more authoritative, or even that they contradicted each other.

Designs decisions that mattered

Schema-informed prompting; The LLM initially guessed type names like card and document, returning empty results. I injected a schema description into the system prompt so it knows to query *[_type == "article"]. This is a small detail that helps to dramatically improved reliability.
Sanity as the source of truth(where the articles are confirmed from); No content is hardcoded in the agent. Every fact the agent reports comes from a live GROQ query against the Content Lake. If I update an article in the Studio, the next question gets the updated answer.
useCdn(false); I disabled the CDN for the agent so responses are always fresh from the Content Lake and always 100% Real Time. This matters for an agent where "the latest errata" is the whole point.

The Sanity Project Details

Project ID: uyvc8sil
Dataset: production
Document type: article (fields: title, slug, body, source)

What I Learned

I learned a lot because this is my first time of hearing about sanity. I learned how to made the case for structured content viscerally clear. So this provide me an opportunity that an LLM can reason about provenance when we have fields like title, body, and source defined in a schema. This led me to understand the difference between these statements "here are two documents" and "these two sources disagree, and here's the URL for each claim".

The hardest part wasn't the LLM logic, it was teaching the agent the schema. Once I stopped trying to make the model guess type names and instead told it was in the content Lake, everything clicked.

Thanks

Thanks to Sanity and DEV for the challenge. It pushed me to build something I'd been wanting to try: an agent that treats structured content as the foundation, not an afterthought.

Correlation vs. Causation: What They Actually Mean

Victor — Mon, 14 Sep 2026 18:48:49 +0000

" Correlation isn't causation" is one of the most repeated phrases in data science and one of the least explained. Here's what each term actually means, why the confusion happens, and four specific ways it goes wrong in practice.

If you've spent any time around data, you've heard "correlation doesn't imply causation" so many times it's become background noise. But if you stopped someone and asked them to define correlation and causation separately, in plain words, a lot of people would struggle. So let's start there, before touching any of the traps.

What Is Correlation?
Correlation is simply a measure of how two things tend to move together. If one goes up and the other usually goes up too, that's a positive correlation. If one goes up while the other tends to go down, that's a negative correlation. If they seem to have nothing to do with each other, that's little to no correlation.

A simple, real example: height and shoe size are correlated. Taller people tend to have bigger feet. That's a positive correlation, and it's intuitive, but notice we haven't said anything yet about why.

Correlation is purely descriptive: it tells you two variables tend to change together, and roughly how strongly, using a number called the correlation coefficient (often written as r), which ranges from -1 (perfectly opposite) to +1 (perfectly together), with 0 meaning no relationship at all. That's the entire job of correlation: describe a pattern. It has no opinion on what's causing that pattern, or whether anything is causing it at all.

What Is Causation?
Causation is a stronger, different claim: it means one variable directly produces a change in another. There's a mechanism connecting them, and if you intervened and changed the first variable, and only that variable, the second one would change as a result.

Take a simple example: turning up your oven's temperature causes your food to cook faster. If you change the temperature, cooking time changes because of that action. There's a direct, physical mechanism (more heat transfers energy faster), and you can test it by changing nothing else and watching the result change predictably.

A useful mental test for causation: "If I could reach in and change only this one thing, would the other thing change as a result?" If yes, that's a causal relationship. If you can't actually intervene, or if changing one doesn't reliably move the other, you're probably just looking at correlation.

Why We Keep Mixing Them Up
Human brains are pattern-matching machines; we're wired to notice when two things happen together and jump to "one must be causing the other," because that instinct was useful for survival long before it was useful for data analysis. The problem is that correlation is easy to measure (a single formula gives you a number) while causation is hard to establish (it usually requires careful experiments or reasoning about mechanisms). So we default to the easy signal and treat it like the hard one.

This is exactly where the four classic traps come in; they're the specific ways a real, measurable correlation can exist without any real causation behind it.

Confounding Variables (The Third-Variable Problem)

This happens when a hidden third factor is actually driving both variables you're looking at, making them look connected to each other when they're really both just reacting independently to something else.

The classic case: ice cream sales and shark attacks both rise in summer. It's not that ice cream causes attacks, or attacks cause ice cream sales warmer weather (the confounder) independently drives more people to buy ice cream and more people into the ocean at the same time. The confounder never shows up if you only look at the two headline variables.

In real analysis work, common hidden confounders include location, income, age, and season they quietly explain relationships that look meaningful on the surface.

Reverse Causality
Sometimes the relationship is genuinely causal, just pointing the opposite direction from what you assumed. A model might show "customers who contact support more often churn more," tempting you to conclude support interactions drive churn.

Just as plausible: customers who are already unhappy and about to leave contact support more because they're frustrated. The outcome is quietly driving the presumed cause.

Reverse causality is sneaky because the correlation itself carries no signal about which direction is correct you need outside knowledge, timing data, or a controlled study to untangle it.

Coincidence (Spurious Correlations)
Given enough variables and enough time, some completely unrelated trends will line up purely by chance. This is the trap behind the famous "spurious correlations" examples; like per-capita cheese consumption tracking almost perfectly with the number of people who died tangled in their bedsheets. There is no mechanism connecting them at all. With enough random series being compared, some pair will always match closely just by luck which is why testing dozens of variables against each other without a hypothesis ("data dredging") is such a well-known danger in statistics.

Selection Bias
This trap comes from how the data was collected, not from the variables themselves. If your sample isn't representative of the population you're trying to understand, you can manufacture a statistical link that isn't real or hide one that is.

A classic case: surveying only customers who already responded to a marketing email makes that email look more effective than it is, because people who never open emails are systematically missing from the data. The relationship you're seeing was baked in by how the sample was built, not by anything the two variables are doing to each other.

So How Do You Actually Prove Causation?
If correlation alone can't do it, what can? A few real tools researchers and data teams use:
● Randomized controlled trials (RCTs): randomly split a group in two, change one variable for one group only, and compare outcomes. Randomization cancels out confounders on average, so any difference in outcome can be attributed to the variable you changed.
● Natural experiments: when you can't randomize, look for situations where something close to random chance assigned the variable anyway (like a policy that took effect in one region but not a neighboring one).
● Statistical controls: _techniques like propensity score matching or regression with control variables that try to account for known confounders mathematically, when an experiment isn't possible.
● _A believable mechanism: even strong statistical evidence is more convincing when there's a plausible, explainable reason why one thing would cause the other.

A Quick Checklist Before You Claim Causation

● Could a third factor explain both variables?
● Could the arrow of cause and effect be pointing the other way?
● How many other variables did I compare before I found this one?
● Does my sample actually represent the population I'm making claims about?
● Do I have experimental evidence, or just an observed pattern?

Why This Matters
None of this means correlation is useless a strong correlation is a great lead. It tells you where to look. The mistake isn't noticing the pattern; it's stopping there and calling it an explanation. Treat correlation as the start of an investigation, not the end of one.

"""Demonstrating why correlation does not prove causation in marketing.

Scenario:
- A company spends more on ads during the holiday season.
- Customers also buy more during the holiday season.
- Holiday demand causes both variables to increase.
- Marketing spend has no causal effect in this simulation.
"""

import numpy as np

rng = np.random.default_rng(42)
months = np.arange(24)
holiday_season = (months % 12 >= 9).astype(float)

# Holiday demand is a hidden third variable (a confounder).
marketing_spend = 10 + 20 * holiday_season + rng.normal(0, 2, size=24)
sales = 100 + 80 * holiday_season + rng.normal(0, 5, size=24)

correlation = np.corrcoef(marketing_spend, sales)[0, 1]

print(f"Correlation between marketing spend and sales: {correlation:.2f}")
print("A high correlation alone does not prove that marketing caused the sales.")
print("In this simulation, the true causal effect of marketing spend is zero.")

# Once we compare months within the same season, the misleading relationship
# largely disappears because the hidden seasonal factor is held constant.
non_holiday = holiday_season == 0
holiday = holiday_season == 1

non_holiday_correlation = np.corrcoef(marketing_spend[non_holiday], sales[non_holiday])[
    0, 1
]
holiday_correlation = np.corrcoef(marketing_spend[holiday], sales[holiday])[0, 1]

print(f"Correlation in non-holiday months: {non_holiday_correlation:.2f}")
print(f"Correlation in holiday months: {holiday_correlation:.2f}")
print("To test causation, use a randomized marketing experiment or A/B test.")

HealthBridge: Engineering an Offline, CPU-Only LLM to Bridge Nigeria’s 1:4,000 Doctor-to-Patient Gap

Victor — Sun, 06 Sep 2026 16:12:47 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

I built HealthBridge; an offline, CPU-only AI assistant designed to tackle Nigeria's severe doctor shortage and connectivity barriers.

Specifically, here is exactly what I delivered:

A fully offline LLM-powered health education tool
I packaged a quantized large language model (Qwen2.5-1.5B-Instruct in GGUF Q4_K_M) so it runs entirely on a standard laptop's CPU. No internet, no GPU, and no recurring cloud costs making it viable for rural and peri-urban Nigerian communities where connectivity is spotty or unaffordable.
A triage and patient education interface
I built an interactive assistant (working through the Streamlit interface challenges you saw in the report) that does four specific jobs for community health workers, patients, and caregivers:

. Explains common symptoms in plain language.

. Describes basic treatments (e.g., oral rehydration therapy for cholera/diarrhea).

. Guides users on when to urgently seek hospital care (red-flag triage).

. Actively steers people away from seeking advice from unqualified friends, neighbours, or unregistered local pharmacies.

Crucially, it is strictly scoped as a complement to professionals; it never claims to replace clinical diagnosis.

A lightweight, resource-optimized runtime
I chose the llama.cpp runtime and carefully picked the Q4_K_M quantization to hit the sweet spot: coherent, medically-contextual responses while fitting comfortably inside an 8GB RAM budget (peaks at just 1.7 GB during my tests). The model runs at 16.76 tokens/second on integrated graphics; no discrete GPU required.
A zero-dependency deployment pipeline
I set up a download_model.sh script to fetch the model via Hugging Face, but after that initial download, the entire inference pipeline runs completely offline. I ensured the model file itself isn't committed to git, so evaluators can pull it fresh and run it immediately on the ADTC standard laptop (10th–12th gen i5, 8GB DDR4, Ubuntu 22.04).

In short: I built a portable, cost-free, offline health-information kiosk-in-a-laptop that gives populations accurate, actionable guidance—bridging the gap between community pharmacies and overstretched hospitals, without ever pretending to be a doctor.

Demo

https://youtu.be/PI3vzJGBDSA

Code

https://github.com/Vicarioy/adtc-2026-submission-template.git

How I Built It

Here is the technical walkthrough of how I built HealthBridge; covering the architecture, the tough trade-offs, and the exact steps I took to wrestle it onto resource-constrained hardware.

Model Selection: The "Goldilocks" Search The first decision was choosing the brain. I couldn't just pick the biggest model.

What I tested: I ran local benchmarks with Phi-3-mini-4k (3.8B—too much RAM, risked exceeding the 8GB target), Qwen2.5-0.5B (fit easily but gave vague, sometimes incorrect health advice), and Llama-3.2-1B (decent, but weaker at following multi-turn health Q&A prompts).

The decision: I chose Qwen2.5-1.5B-Instruct. It sits perfectly in the middle strong enough to reason through symptom-checking and triage logic, yet small enough to leave headroom for the OS and interface. Its multilingual tokenizer also helps handle local language nuances when users describe symptoms in pidgin or their native tongue.

Quantization Strategy (The Accuracy-vs-Memory Trade-off) A raw 1.5B FP16 model wouldn't fit in 8GB comfortably, so I needed compression.

I rejected Q4_0 (too much precision loss—critical for medical context) and Q5/Q8 (too heavy).

I settled on GGUF Q4_K_M. This uses K-means grouping on the most important weight matrices. It applies 4-bit quantization but allocates bits more intelligently across layers. This preserves the model's "reasoning" capability far better than flat quantization, giving me medically coherent responses while keeping peak RAM at just 1.7GB, well under the 8GB ceiling.

Runtime & Inference Engine (llama.cpp) The competition rules strictly mandated llama.cpp, but honestly, it was the perfect choice anyway.

I compiled llama.cpp with standard x86-64 CPU optimizations (leveraging AVX2 instructions on Intel chips).

I wrote a Python wrapper that uses llama-cpp-python to interface with the .gguf file. The key tweak here was setting n_ctx=32768 (to utilize Qwen's full context window for long patient histories) but carefully tuning n_batch to 512 to maximize throughput without blowing up the CPU cache.

This setup gave me 16.76 tokens/second on an integrated UHD 620; fast enough for real-time conversation.

The Interface Nightmare (Where I Almost Broke) You noted in the report that building the interface was a massive problem, and you're right. Streamlit kept timing out or failing silently.

The issue: Loading a 1.5B GGUF model inline during Streamlit's startup sequence blocks the main thread. Streamlit's watchdog timer would kill the process if the model loaded slower than ~10 seconds.

How I fixed it: I decoupled the model lifecycle. Instead of loading the model globally, I wrapped it inside a st.cache_resource decorator with lazy initialization meaning the model only loads on the first user prompt, not when the page boots. I also spawned the llama.cpp inference in a separate background thread with a queue, so the UI remains responsive while the model warms up. This single architectural shift made the app stable and prevented timeouts.

Deployment & Zero-Connectivity Pipeline Since internet is the problem, I had to make internet the non-requirement.

I wrote a download_model.sh script to fetch the .gguf from Hugging Face only once during setup.

I strictly excluded the ~900MB model file from git using .gitignore. The evaluator runs the script, grabs the model, and from that point forward, every inference call hits the local filesystem. No API keys, no network retries, no cloud latency.

The entire app runs on localhost; I pinned the environment dependencies (llama-cpp-python, streamlit) to specific versions to guarantee reproducible builds on the ADTC Ubuntu 22.04 target.

Domain-Specific Prompt Engineering Because I'm legally and ethically scoped to education/triage, not diagnosis, I hardcoded a system prompt that:

Explicitly states: "I am an educational assistant, not a doctor. Do not take my advice as a clinical diagnosis."

Guides the model to always include a "Red Flag" section in responses (e.g., "Go to a hospital immediately if you see blood in stool or have a high fever over 39°C").

Instructs the model to actively deflect dangerous queries if a user asks for a prescription, it responds with safety advice and urges them to visit an MDCN-registered practitioner.

Prize Technology Highlight: This project squarely falls into Edge AI / On-Device AI categories. By combining gguf quantization with llama.cpp, I built a production-ready, CPU-only LLM that democratizes health information in bandwidth-scarce regions; proving that impactful AI doesn't require the cloud.

5 ML Math Concepts I Stopped Memorizing (And Started Actually Using)

Victor — Sun, 06 Sep 2026 15:16:26 +0000

I've been deep in linear algebra and calculus for the better part of a year. But up until this week, I realized i was still treating core ML math like the chain rule and eigenvalue; as a syllabus checklist. Week 3 of my structured deep dive is when i finally forced myself to stop, derive them by hand and connect them to actual code using numpy. Here are some of the concepts that finally clicked:
1. The Chain Rule Is the Engine Behind Backpropagation
Every neural network learns by adjusting its weights, and it knows which direction to adjust them in because of the chain rule. A network is really just a stack of functions: input goes through a layer, then an activation function, then another layer, and so on. To know how much a single weight buried deep in that stack contributed to the final error, you need to differentiate through every function it passed through. That's exactly what the chain rule lets you do. I traced this end to end: starting from gradient descent (which says "move the weights a little in the
direction that reduces error"), through the activation function's own derivative, back to the weight itself. Once I could follow that chain by hand instead of trusting a library to do it, backpropagation stopped feeling like magic and started feeling like bookkeeping.
2. The Gaussian (Normal) Distribution Is Everywhere in ML
The bell curve isn't just a statistics-class cliché; it shows up constantly in machine learning: in how we initialize weights, in the noise assumptions behind linear regression, in probabilistic models, and in how we reason about errors clustering around a mean. Understanding its two parameters; mean and variance, is really understanding "where is the data centered" and "how spread out isit," which turns out to be one of the most reused ideas in the entire field.
3. Eigenvalues Are the Secret Behind Face Recognition
This was the concept that surprised me most. Eigenvalues and eigenvectors which sound purely academic are the foundation of techniques like PCA (Principal Component Analysis) and the classic "Eigenfaces" approach to face recognition. The idea: a face image has thousands of pixels, but most of the meaningful variation between different faces can be captured by a much smaller set of directions, the eigenvectors with the largest eigenvalues. Compress along those directions, and you keep what matters while discarding noise. Linear algebra, doing real work.
4. The Laplace Rule of Succession: Smoothing for Probability
What's the probability of an event you've never seen happen? Naively, zero but that's usually wrong and dangerous in ML, especially in text and classification models where an unseen word or category shouldn't automatically get a probability of zero. The Laplace rule of succession solves this by adding a small smoothing count to every outcome, so nothing is ever assigned a flat-out impossible probability. It's a simple idea with a name that sounds far more intimidating than it is.
5. Sampling and Confidence Intervals: Choosing Data You Can
Trust
You can't train on an entire population, so you sample from it; but that raises an obvious question: how do you know your sample actually represents the population? This is where confidence intervals come in. They give you a principled range around an estimate, along with a stated level of certainty, so that when you pick a dataset you know how much to trust conclusions drawn from it. This felt directly relevant to my own work, since a lot of real-world data (like the regional health data in my thesis project) is sampled, imperfect, and needs exactly this kind of scrutiny.
Why This Matters
None of these five ideas are new inventions, they're decades old. But sitting with the math instead of skipping to the library call changed how I read papers. When something behaves strangely, I now have a better instinct for whether the culprit is a distributional assumption, a smoothing issue, or a bad sample, instead of just tuning hyperparameters and hoping.
Next up: going deeper into differential calculus and connecting it more directly to optimizers beyond
plain gradient descent.