Building reliable AI has never been about making systems sound smarter. It has always been about making them behave correctly when their assumptions fail. My own work on robustness has taken place in two domains that appear unrelated at first glance: adversarial robustness in deep learning, and verifiable retrieval-augmented generation (RAG). One operates in gradients and geometry, the other in documents and evidence. Underneath, they are solving the same problem.

Both ask a single question: what should a system do when it cannot be confident it is right?

Last year, in CMPUT 466, I worked on Exact Geometric Ensemble Adversarial Training (EGEAT) — a research project that reframed robustness as a geometric property of learning rather than an artifact of iterative attacks. This winter, as a UAIS Project Lead, I am applying the same failure-aware design philosophy to VeriRAG-R, a robust and verifiable RAG system designed for noisy, high-stakes documents.

This post is about the bridge between those two projects — and why robustness, regardless of modality, must be designed in rather than bolted on.

The Foundation: What EGEAT Taught Me About Failure

Adversarial robustness exposes an uncomfortable truth about modern deep learning: models can fail catastrophically under perturbations that are imperceptible to humans. Traditional defenses treat this as an optimization problem, relying on iterative attacks like PGD to approximate worst-case behavior. In practice, these approaches are expensive, opaque, and often poorly aligned with the true failure geometry of the model.

EGEAT began with a reframing: robustness is not primarily about iteration, but about geometry.

Instead of approximating the inner maximization with multi-step attacks, EGEAT uses convex duality to derive exact, closed-form adversarial perturbations. These perturbations correspond to the true first-order worst-case direction of the loss, removing approximation error from the robustness objective itself.

But exact perturbations alone are insufficient. One of the most dangerous properties of adversarial examples is transferability: attacks crafted for one model frequently fool others. This turns out to be a geometric phenomenon as well. Independent models often share aligned gradient subspaces, meaning they are vulnerable along the same directions in input space.

EGEAT addresses this directly by enforcing gradient-subspace decorrelation across an ensemble. By penalizing alignment between input-gradient directions, the system rotates decision boundaries apart, reducing shared vulnerabilities. Ensemble and weight-space smoothing further stabilize training by discouraging sharp minima and brittle solutions.

The core lesson from EGEAT was not simply that robustness can be improved — it was why:

Robustness is not a post-hoc patch. It is a property of the geometry the learning process encourages.

A New Domain, the Same Failure Mode

At first glance, Retrieval-Augmented Generation looks unrelated to adversarial robustness. There are no ℓ∞ balls, no input gradients over pixels, no saddle-point objectives. But the failure modes are strikingly similar.

Standard RAG systems perform well on clean, curated inputs. In real deployments, documents are scanned poorly, tables are flattened, sections are missing, and sources disagree. Under these conditions, many systems fail in the worst possible way: they hallucinate confidently, fabricate citations, or fail silently.

In high-stakes settings — legal reference, policy analysis, clinical guidelines — confidence without verification is worse than no answer at all.

This is the problem VeriRAG-R is designed to solve.

As a UAIS Project Lead this winter, I am guiding VeriRAG-R around a principle that mirrors EGEAT’s philosophy almost exactly

Saying “I don’t know” is not a fallback. It is a success condition.

Bridging the Two Projects

Although EGEAT and VeriRAG-R operate at different layers of the AI stack, the design lineage between them is concrete. The connection rests on three shared pillars.

1. Intentional Noise as a Diagnostic Tool

In EGEAT, robustness is evaluated under explicit worst-case perturbations. Failure is not accidental; it is deliberately provoked so the system’s geometry can be inspected.

VeriRAG-R applies the same idea through a Robustness Harness. Instead of assuming clean inputs, we inject controlled noise during document ingestion — OCR corruption, random section dropout, table flattening, and formatting loss. The purpose is not to break the system arbitrarily, but to observe how degradation occurs and which components fail first.

In both systems, robustness is something you test before deployment, not something you benchmark after a failure has already occurred.

[Image placeholder: Robustness harness with injected document noise]

2. Hybrid Logic Instead of Single-Signal Confidence

EGEAT does not rely on a single strong model. It relies on ensembles whose sensitivities are intentionally decorrelated. Robustness emerges from disagreement, not consensus.

VeriRAG-R borrows this idea directly. Dense retrieval captures semantic intent but can miss exact details. Sparse retrieval excels at lexical precision but is brittle under paraphrasing. Instead of trusting either signal in isolation, VeriRAG-R treats retrieval disagreement itself as a diagnostic signal.

When dense and sparse retrieval agree, confidence increases. When they diverge, the system becomes more conservative — often triggering partial answers or abstention. This mirrors how gradient disagreement in EGEAT signals reduced transferability and increased robustness.

3. Structural Traceability as Interpretability

One of the most valuable aspects of EGEAT was interpretability. Gradient alignment metrics and loss-landscape visualizations provided concrete diagnostics for understanding failure modes.

VeriRAG-R enforces the same standard through hierarchical chunking. Every answer is traceable to a document, section, paragraph, and page ID. Claims are not simply generated — they are grounded in inspectable structure.

This is the document-level analogue of tracking sensitivity directions in gradient space: failures are observable, not hidden.

Executing the Vision: System First, Team Second

Building robust systems requires structure, but structure should serve the system — not overshadow it.

VeriRAG-R is organized to mirror the pipeline itself: ingestion and evaluation, retrieval and reasoning, and verification and integration. Contributors are grouped by responsibility rather than hierarchy, ensuring each layer of the system is independently testable and inspectable.

The Winter semester follows a deliberate progression:

• establishing a clean baseline,
• introducing hybrid retrieval and robustness testing,
• implementing verification and abstention logic,
• and consolidating the system for public evaluation.

This mirrors how EGEAT evolved as well: theory first, diagnostics second, integration last.

Looking Ahead

Whether we are decorrelating gradient subspaces or cross-referencing noisy PDFs, the goal remains the same: build AI systems that fail safely, visibly, and honestly.

EGEAT taught me that robustness is fundamentally geometric — about shaping the space in which models operate. VeriRAG-R applies that same insight to retrieval and reasoning: reliability emerges when uncertainty is modeled explicitly rather than ignored.

By the end of this semester, VeriRAG-R aims to stand not just as a project demo, but as a blueprint for verifiable, failure-aware AI in domains where trust matters more than fluency.

🌱 Introduction — When Innovation Meets Physical Exhaustion

Hackathons look glamorous from the outside: neon lights, excited crowds, and the promise of creating something futuristic in a weekend.

Reality? Less glamorous.

Try soldering at 4 a.m. with trembling hands.
Try debugging an ESP32 that refuses to connect unless you threaten it.
Try writing SQL queries on no sleep while servo motors scream like tiny mechanical demons.

At NaTHackS 2025, my team and I lived all of that.

But through 64 hours of chaos, exhaustion, and relentless debugging, we built SOILution — a distributed IoT irrigation system designed for farmers facing Prairie drought, soil stress, and unpredictable rainfall.

It pushed every part of me:
my embedded skills, my cloud engineering skills, my analytics skills, and my ability to function while my brain rebooted every fifteen minutes.

This blog is the real story — the architecture, the failures, the decisions, the debugging nightmares, and the moment the dashboard finally lit up at 3:47 a.m. and we realized:

We actually built something meaningful.

Not a prototype.
Not a demo.
A real system that can help farmers conserve water and protect crops.

🌾 Why We Built SOILution — The Prairie Problem

Farmers in Western Canada deal with:

• unpredictable rainfall
• clay-heavy soil that dries rapidly
• limited well water
• outdated fixed-timer irrigation
• zero real-time soil feedback

This leads to:

• Over-watering → wasted water + nutrient runoff
• Under-watering → drought stress + yield loss
• Guess-based decision-making

We reframed the problem like engineers:

💡 What if the soil itself could tell the farmer when it needs water?
💡 What if irrigation could adapt dynamically based on real soil behavior?

This idea became SOILution.

⚙️ SOILution in One Sentence

SOILution reads the soil, learns from it, and waters crops automatically using a distributed network of ESP32 telemetry nodes connected to a cloud backend and real-time dashboard.

Under the hood, it’s a full production-grade ecosystem.

🧱 Architecture — A Full IoT Ecosystem Built in 64 Hours

This wasn’t a typical hackathon throwaway project.
It was a multi-layer system with real engineering rigor.

[Soil Moisture Sensor]
        ↓
[ESP32 Node]
  - ADC smoothing
  - Calibration curves
  - Slope detection
  - Offline caching
  - Fault-tolerant Wi-Fi
        ↓
[HTTPS → Supabase REST]
        ↓
[Supabase Postgres]
  - Telemetry store
  - Crop thresholds
  - Zone configs
  - Watering logs
        ↓
[Real-Time Dashboard (Vite + JS)]
  - Trend graphs
  - Soil-risk scoring
  - Zone monitoring
  - Water savings
        ↓
[Automated Irrigation]
  - PWM servos
  - Safe actuation
  - Soft-start motion

🔧 ESP32 Firmware — Turning Noisy Sensors Into Reliable Insights

🧪 1. Moisture Acquisition Pipeline

Capacitive sensors = noisy, nonlinear, and chaotic.

Raw readings fluctuated ±15% every few seconds — completely unusable for real farming.

So we built a multi-stage smoothing pipeline:

• Rolling average (5 samples)
• Median filter
• Normalized calibration (dry/wet endpoints)
• Slope detection
• Debouncing

🖼️ [Insert Image: Moisture sensor setup / wiring diagram]

The math workflow:

float filtered = median(rolling_average(raw, 5));
float normalized = (filtered - dry) / (wet - dry) * 100;
float slope = (curr - prev) / dt;

We reduced variance from ±12% → ±3.5%.

⚡ 2. Servo Actuation Without Brownouts

Every servo movement caused ESP32 resets.
Turns out: servo stall current caused voltage dips → brownouts.

Fixes:

• Dedicated 5V rail
• Ground isolation
• PWM-safe pins
• Soft-start angle sweep

🖼️ [Insert Image: Servo valve controlling irrigation]

void safe_move(int target) {
  int curr = servo.read();
  int step = (target > curr) ? 1 : -1;
  while (curr != target) {
    curr += step;
    servo.write(curr);
    delay(10);
  }
}

Irrigation became rock-solid stable.

🌐 3. Fault-Tolerant Telemetry Pipeline

Rural Wi-Fi isn’t dependable.
So we engineered the ESP32 transport layer like a production IoT device:

• HTTPS + TLS
• Exponential backoff
• Duplicate suppression
• EEPROM offline caching

for (int i = 0; i < 6; i++) {
  if (send(payload)) return;
  delay(pow(2, i) * 1000);
}
store_in_buffer(payload);

We unplugged the router for 15 minutes.
The ESP32 cached everything and synced instantly on reconnection.

🗄️ Supabase — The Cloud Brain

We built a proper PostgreSQL schema (not hackathon spaghetti):

• telemetry — sensor readings
• thresholds — crop moisture rules
• zones — configuration for each farm zone
• watering_activity — water savings
• profiles — user metadata

Fast queries. Indexed tables. Real-time subscriptions.

📊 Dashboard — Turning Telemetry Into Decisions

We built a dynamic, real-time dashboard:

• Vite + Vanilla JS
• TailwindCSS
• Recharts
• Supabase Realtime

Farmers can:

• monitor moisture in real time
• see recovery curves
• track irrigation events
• view risk scoring
• visualize savings

Realtime updates come from Supabase Postgres-change broadcasts:

supabase.channel('telemetry')
  .on('postgres_changes', { event: 'INSERT', table: 'telemetry' }, (payload) => {
    updateDashboard(payload.new);
  })
  .subscribe();

It feels like a heartbeat monitor for the soil.

🧠 Soil Behavior Intelligence — Early ML Layer

We modeled soil behavior using

• drying velocity
• recovery slope
• decay coefficient (λ)
• saturation delay
• REI (recovery efficiency index)
• thresholds per crop

This produced a Soil Confidence Score (0–100).

Future versions will use:

• LSTM time-series modeling
• TinyML on the ESP32
• NDVI satellite vegetation data

💥 Challenges — The Brutal Truth

• Sensor noise made us question reality
• Servos kept frying our power rails
• Supabase write conflicts required UPSERT logic
• We manually scraped government soil data
• Sleep deprivation turned small bugs into epic battles

But every challenge forced a stronger architecture.

🏆 Accomplishments We’re Proud Of

• ✔ Full IoT → Cloud → Dashboard → Automation pipeline
• ✔ Stable ADC pipelines for low-cost sensors
• ✔ Reliable servo-based irrigation
• ✔ Scalable PostgreSQL schema
• ✔ Early soil behavior analytics
• ✔ ~65% sensor accuracy under noise
• ✔ Won 1st Place — EcoTech Division

Not hack.
A blueprint.

🚀 What’s Next for SOILution

🌤 Weather + Satellite Integration

RAIN API, NDVI maps, soil moisture index.

🤖 TinyML on ESP32

Local prediction → less cloud dependency.

🌾 Real Farm Deployments

Testing across wheat, barley, canola fields.

📡 ESP-MESH

Wireless mesh networks for large farms.

🧰 Built With

Hardware

ESP32, Capacitive sensors, Servo motors, External PSU

Software

C++, JavaScript, SQL

Cloud

Supabase (Postgres, Auth, Realtime)

Frontend

Vite, TailwindCSS, Recharts

🌟 Final Thoughts — Engineering Under Pressure

SOILution wasn’t just a hackathon project. It was:

• embedded engineering
• cloud architecture
• time-series analytics
• distributed telemetry
• human endurance

At 3:47 a.m., when the dashboard finally lit up with real moisture data, we knew:

We didn’t just build a hackathon project.
We built a real system.

A system that can help farmers conserve water, protect crops, and turn soil into data.

And we’re just getting started.

When I first started my career in cybersecurity, my world revolved around defense. Automating workflows, analyzing system vulnerabilities, and anticipating attacks became second nature. Every line of code, every script I wrote, had a single goal: protect and secure.

Little did I know that these same principles would later guide me into a completely different frontier: Generative Adversarial Networks (GANs).

Seeing the Adversary in a New Light

At first glance, GANs seemed worlds apart from cybersecurity. One creates, the other critiques. One is about production, the other protection. But both domains share a core principle: adversarial thinking.

In cybersecurity, I was constantly predicting what an attacker might do. In GANs, I was trying to stabilize the delicate balance between a generator and a discriminator. Mode collapse, vanishing gradients, and unstable convergence — all felt familiar, not in threat, but in strategy and anticipation. My experience anticipating attacks now helped me troubleshoot GANs more efficiently.

Automation: From Defense to Creation

Writing scripts to automate repetitive security tasks taught me efficiency, precision, and reproducibility. These same skills became invaluable when managing GAN pipelines, tracking experiments, and systematically evaluating generated outputs.

What once protected systems was now producing complex data, realistic images, and structured simulations. The mindset was the same, but the goal had shifted: from defense to creation.

Recognizing Patterns Everywhere

Pattern recognition was another bridge between the two worlds. In cybersecurity, spotting anomalies in system logs or network traffic was essential. In GANs, understanding latent spaces, interpreting subtle correlations, and fine-tuning outputs rely on the same sharp analytical skills. The challenges changed, but the core ability to see patterns others might miss remained.

Lessons from the Journey

This transition taught me a few key lessons:

• Skills are transferable. Expertise in one domain can open doors in unexpected areas.
• Curiosity fuels growth. Following your interests can reveal opportunities you never imagined.
• Persistence matters. Both cybersecurity and GANs require iterative experimentation, patience, and adaptability.

Bridging Defense and Creativity

Moving from cybersecurity to GANs hasn’t been about leaving one field behind — it’s been about leveraging my experience in a new, creative way. Today, I combine the rigor of security, the precision of automation, and the curiosity of research to explore generative AI.

The intersection of defense and creation is full of opportunities. It has taught me that skills aren’t just for one purpose — they are tools to approach problems in innovative, unexpected ways. And as I continue exploring GANs, I’m excited to see how much further this journey can go.

“Adversaries exist in both defense and creation; understanding one can unlock mastery of the other.”