DEV Community: Tariq Davis

The code was fine. The green check was lying.

Tariq Davis — Mon, 17 Aug 2026 15:50:40 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The bug wasn't in my code. It was in the thing I trusted to tell me my code was fine.

I build and sell ebooks. Not the kind of software most people picture when they hear "bug" — no server, no users, no stack trace at 3am. Just a document that has to render correctly on a stranger's Kindle.

But I lost two full days to two different bugs this year, and when I finally sat down and looked at both of them side by side, they were the same bug wearing two costumes. Both times, the code was fine. Both times, the thing I trusted to check the code was quietly lying to me. And the gap between "what my tools told me" and "what was actually true" is exactly where both bugs were hiding.

If you've ever shipped something with a green test suite and watched it break in production anyway, this is your bug too. Mine just happened to live in an ebook.

Bug one: I rebuilt a document by eye, and my eye is an idiot

Here's the setup. I had a finished 18-page PDF — a product, already built, already looked good. What I did not have anymore was the code that generated it. The source was gone. Lost to a container reset. All that survived was the output.

I needed to make edits. So I did the obvious thing: I opened the PDF, looked at it, and started rebuilding the source to match what I saw.

This went badly in a way I didn't notice for hours.

I looked at the body text and figured it was about 9.6pt. It was actually 11px. I looked at the chapter titles and called them 27pt. They were 30px. I eyeballed the rail widths, the margins, the colors — all slightly off, all in ways that looked close enough that nothing screamed at me. And three diagrams I couldn't quite make out? I quietly replaced them with my own versions and told myself they were "unreconstructable."

They were not unreconstructable. That's the part that stings.

Because here's what I forgot: a rendered PDF is not a picture of the source. It contains the source. Every font size is sitting right there in the file as a Tf operator. Every color is an rg operator. Every position is a text matrix. The exact values I was squinting at and guessing — 11px, 30px, the real colors, the real diagram coordinates — were all in the file, as numbers, the entire time I was eyeballing them.

I wasn't missing information. I was ignoring it in favor of a guess.

The fix was to stop looking and start reading:

import zlib, re

d = open('lost_source.pdf', 'rb').read()

# who made this file? (tells you which engine to reproduce with)
for m in re.finditer(rb'/(Producer|Creator)\s*\(([^)]*)\)', d):
    print(m.group(1).decode(), '->', m.group(2).decode())

# pull the real values out of the page streams
for s in re.findall(rb'stream\r?\n(.*?)endstream', d, re.S):
    try:
        c = zlib.decompress(s.strip(b'\r\n')).decode('latin-1')
    except Exception:
        continue
    for m in re.finditer(r'/F\d+ ([\d.]+) Tf', c):   # font sizes
        print('font size:', m.group(1))
    for m in re.finditer(r'([\d.]+) ([\d.]+) ([\d.]+) rg', c):  # colors
        print('color:', m.groups())

The moment I ran that, the guessing stopped. The fonts were exact because I was no longer estimating them — I was copying them out of the file. The rebuild became a transcription instead of an impression. And the "unreconstructable" diagrams turned out to be perfectly reconstructable the second I read their actual coordinates instead of squinting at their shapes.

Lesson, stated plainly: if you're reconstructing something from its output, the output usually still carries the real values. Measure them. Do not trust your eye when the file will just tell you the number.

Bug two: every test passed, and the thing was still broken

Different day, different project — an EPUB this time. There's a small design element between sections of the book: a kicker line of text, and a thin decorative rule centered under it. On my machine it looked perfect. In my test renders it looked perfect. On an actual Kindle, the rule jammed itself against the left margin like it was scared of the middle of the page.

So I fixed it. Then I fixed it again. Then again. Five times.

Fix 1 & 2: I used flexbox to center it, plus a tall min-height so it'd sit in the middle. The Kindle ignored both. Collapsed straight to the top.
Fix 3: Classic margin: 0 auto on the element. On older Kindle software, margin: auto is silently treated as margin: 0. It didn't center. It did nothing.
Fix 4: I made the rule a 1px-tall element with a background color. The Kindle didn't paint the background. The rule didn't shift — it vanished.
Fix 5, the one that worked: three em-dash characters — ——— — in a paragraph with text-align: center.

That last one is almost embarrassingly simple, and why it worked is the entire point of this post. It worked because it's the exact same mechanism the book's chapter titles already used, on the same device, successfully, the whole time. I didn't need to invent a centering technique. I needed to reuse the one that was already proven inside this exact file, on this exact reader.

But here's the real bug, the one underneath all five failed fixes:

Every single test render passed. My local renderer was more capable than a Kindle. It honored flexbox. It honored margin: auto. It painted hairline backgrounds. So every broken fix got a green light from my tools and a red light from the actual device. I wasn't debugging the bug. I was debugging against a renderer that didn't share the Kindle's limitations — which meant my tests were confidently telling me "fixed" four times in a row while real readers would've seen it broken.

I only made progress when I stopped trusting the lenient renderer and forced my test to reproduce the actual failure — I disabled margin: auto in my check on purpose, to make my tool as dumb as the target device. The instant my test could fail the way the Kindle failed, it caught the bug immediately.

Lesson, stated plainly: a passing test is only worth as much as the conditions it runs under. If your test environment is more forgiving than reality, a green check isn't proof — it's a nicer-looking version of the bug.

The two costumes, one bug

Line them up:

	What I trusted	What was actually true	Where the truth was hiding
Rebuild by eye	My visual estimate of the PDF	Exact font/color/position values	Inside the PDF's own operators
The centering rule	A passing test render	The Kindle's real behavior	In the actual failure condition

Same shape both times. I trusted a convenient signal — my eye, my green test — instead of measuring the real thing. And both bugs lived precisely in the gap between the two.

This is not an ebook lesson. It's the thing under most bugs that survive more than one fix:

The log that looks clean because it isn't logging the thing that's actually failing.
The test that passes because it mocks away the exact condition that breaks in prod.
The metric that's green because it's measuring something adjacent to what you care about.
The "it works on my machine" that is true, and useless, because your machine is more forgiving than the one that matters.

When a bug survives your fix, the first thing to distrust isn't your code. It's the signal that's telling you your code is fine. Go make your check as harsh as reality — measure the real value, reproduce the real failure — and the bug usually stops hiding.

What I'm proud of

Not the fixes. The fixes were small — a regex and three em-dashes. What I'm proud of is that I stopped treating each bug as a code problem and started treating it as a trust problem, and that reframe turned two separate two-day slogs into one lesson I now reach for automatically. The next time something survives a fix, I don't touch the code first. I go interrogate whatever told me the code was fine.

That's the resilience win. Not harder code — harder checks.

Check out my website: www.tagzauthor.com
Support TagzAuthor: ko-fi.com/tagzauthor
My author page: Amazon Bookstore

I Built Three Cybersecurity Products. I Didn't Realize They Were One System Until the Third.

Tariq Davis — Fri, 07 Aug 2026 14:32:53 +0000

This didn't start as a system. It started as a side hustle.

I wanted a business built around the field I was actually in — hacking, AI, cybersecurity — something I could build on while I learned how to navigate all of it. So I stopped overthinking it. Made a plan, outsourced the heavy lifting to AI so I could direct it instead of drown in it, and started.

This was also a stretch where I was building my relationship with God, and that ended up being the ground I stood on through the uncertainty of starting something with no idea if it would work.

The first one was a test

Bug bounty. I thought people wanted a clean way into that world, so I made a starter kit — methodical, easy to digest, the thing I wish I'd had.

After a month, I got a little traction. Mostly free-preview downloads, nothing huge. I went into cybersecurity and bug bounty communities on Reddit, posted on Dev.to, actually helped people instead of pitching them, and that got TagzAuthor its first real attention. Small, but real. It's all still new and incomplete, so I didn't expect more than that.

That was the test. It passed.

The second one carried more weight

Next I built the Cybersecurity Intelligence Framework. This one mattered more, because it solved cybersecurity reporting for me — the gap between finding something real and being able to say it in a way that holds up under review.

Then the timing got strange. A few weeks after I finished it, I landed an application security internship. Felt like more than coincidence.

So I did the obvious thing: I wrote down every piece of gold I could pull from it. That experience was exactly what I'd been missing, and I wasn't going to keep it to myself. With AI helping me shape it, I turned the whole thing into a methodology, and then into a book — the most in-depth, experience-based thing I've written. It's ready for Amazon now.

And then it happened again. Days after the first internship ended, I got a second one. A whole new layer of experience that completed what the first one started.

The third one connected everything

Out of that second round, I built my own version of an AI x Cybersecurity Toolkit — practical, accessible tools and methods for making cybersecurity manageable, even fun to work with.

It carries the part most technical guides leave out: the human side. The stillness that lets information organize itself instead of forcing it. It's built to teach beginners how to iterate their own systems while they work, not just follow mine.

Here's the part I didn't plan. Because of how I think — in systems, always half-anticipating the next piece — plus some genuine luck, the three frameworks locked into one ecosystem. They connect and support each other with no friction. The Toolkit is how you think, the Bug Bounty Kit is what you do, the CIF is how you defend what you found.

Three different starting problems. Same method underneath. I drew this after I noticed the connection, not before.

I didn't design that. I noticed it after the fact.

Where this goes

That accident gave me a blueprint. I know how to build the next ones now, and the direction from here is going to be worth watching.

I won't spoil it. I'll just leave it here for the ones who tune in and wait — this is a metal that's slow to melt and slow to cool.

Wish me luck. God bless everyone who read this.

The three guides, bundled:

www.tagzauthor.com/l/security-bundle

Free previews are up if you want to read before you commit.

Support TagzAuthor: ko-fi.com/tagzauthor
My author page: Amazon Bookstore

Your AI Doesn't Know the Difference Between Knowing and Guessing

Tariq Davis — Fri, 24 Jul 2026 02:44:43 +0000

Your AI Doesn't Know the Difference Between Knowing and Guessing

I asked a local model what seven times eight was.

Not in chat. Through a tool-calling setup I wired myself, where the model reaches for tools on its own.

It reached for a tool called "Math." That tool does not exist. It made it up, answered with full confidence, and did the same thing again on a second machine running identical config.

In plain chat, the same model answered 56 without a problem.

Two Failures, Not One

The obvious one is that it couldn't do tool-calling. Math and tool-calling are separate skills, trained separately, and this model had one and not the other.

The failure underneath is the one that matters.

It didn't know it was guessing.

It produced a mechanism it had no basis for and delivered it in the same voice it uses for things it actually knows. No hedge, no flag, no difference in tone between the real part and the invented part.

That's not an AI problem. That's the oldest reporting failure there is, running inside a model instead of inside a document.

I Already Had a Name for It

I built the Cybersecurity Intelligence Framework around three categories, because reports don't get rejected for wrong findings. They get rejected for claims sitting in the wrong category.

Proven. You can point at what supports it. A log line, a response body, a screenshot.

Inferred. Concluded from evidence, not directly stated. Say consistent with, not proves.

Assumed. No source yet. Name it, don't bury it.

✗  "The attacker accessed the database."
     no source. stated as fact. category error.

✓  "An authenticated session accessed the database at 02:14,
    consistent with the observed pattern."
     same evidence. defensible.

Same evidence. Completely different standing.

The model did exactly what the top line does. Took something with no source and stated it as fact. The difference is it can't be taught to catch itself, so the catch has to happen outside it.

Which gives you two jobs. Find where it starts guessing. Then read what it hands back like a report you have to defend.

Job One: Find the Ceiling

Run it twice before you depend on it.

Level one: the simplest version of the task, answer you already know.

Level two: same task, wrapped in the structure you actually plan to use.

# Level 1 - simple, known answer
ask(model, "7 x 8")            # -> "56"   holds

# Level 2 - same model, wrapped in tool-calling
run_agent(model, "7 x 8")      # -> calls tool "Math" (invented)
                               # -> confident answer, false mechanism

Reliability at level one tells you nothing about level two. If it holds at one and breaks at two, that gap is the ceiling.

Build under it.

Security already works this way. Burp Suite exists because nobody trusts what a browser reports at face value. An AI that invents a tool and a server that returns a clean response it should have rejected are the same failure in different clothes.

Job Two: Read the Output Like a Report

Everything it gives back goes through the same three categories.

Which parts can you point at a source for. Which parts are reasonable but unverified. Which parts came from nowhere and got stated anyway.

It won't mark them for you. One voice for all three.

What I Did With It

I run two environments, one for hunting and one for building, carrying the same local AI layer so a tool written for one runs on the other unchanged.

The tool that hallucinated got built, tested, and removed.

I didn't remove the AI. Direct chat and single-file generation held up fine. Multi-step autonomy didn't. So the automation runs the rote weight, capturing findings, drafting from the ledger, ranking scan output, and stops at every point where being wrong costs something. Those points are mine.

The ceiling test is what told me where to draw that line.

What's in the Toolkit

Twelve chapters, three parts.

Part I is how you think before touching anything. Treating the model as an opponent instead of an assistant. A six-step loop that takes a raw thought through capture, external testing, and defense before it earns a place anywhere. The ceiling test. A test for whether you needed to build a tool at all or whether a conversation with the right constraints already does the job. Learning a new team by what people actually own instead of what their title says. Compressing a concept to one sentence with no technical words. Then the three categories in full.

Part II is what to use and where to go. Real tool names by role: recon, intercept, pipeline, monitoring, and where the AI layer sits among them. A five-step certification path, ordered, prices and links included. Five prompts you paste your own situation into.

Part III is where each of these got tested and what it cost when it failed.

The recon workflow the loadout compresses is in the Bug Bounty Starter Kit. The reasoning system behind the three categories is in the CIF. This one sits across both.

Free preview covers the posture and the ceiling test. Enough to run on something today.

www.tagzauthor.com/l/ai-cyber-preview

Support TagzAuthor: ko-fi.com/tagzauthor
My author page: Amazon Bookstore

Your Cybersecurity Report Gets Rejected. It's Not Because the Finding Is Wrong.

Tariq Davis — Tue, 09 Jun 2026 15:31:16 +0000

Your Cybersecurity Report Gets Rejected. It's Not Because the Finding Is Wrong.

The report comes back. No explanation at first — just a rejection.

The finding was real. The vulnerability existed. The log proved it. But the report said "the attacker accessed the database" when all it could actually prove was "an authenticated session accessed the database at 2:14AM."

One embedded assumption. That's all it takes.

That gap — between knowing what happened and being able to say it in a way that holds up — is where most cybersecurity output breaks down. Not at the finding. At the reasoning.

I'm a cybersecurity student who kept running into this pattern across bug bounty, lab work, and academic research. The finding was usually right. The structure around it wasn't. So I built a framework to fix that.

The Real Problem

Most cybersecurity training teaches you what to look for. Very little teaches you how to reason about what you find.

You end up with the right information and the wrong structure. Reports that don't survive review. Bug bounty findings marked N/A. Research proposals that collapse under questioning. All the same root cause — the reasoning wasn't made visible.

The intelligence cycle has been around for decades. Proven, inferred, assumed — these aren't new ideas. What's missing is an operational version. Something you can actually run on a real problem, with AI prompts that execute each stage so the output is defensible the first time.

The Fixed Version

The broken report said: "The attacker accessed the customer database."

The defensible version: "An authenticated session accessed the customer database at 2:14AM. Based on IP geolocation and session timing, this is consistent with the observed threat actor pattern."

Same evidence. Completely different standing.

The difference is one word: consistent with. That's the line between a proven claim and an inferred one. Most people don't know they're crossing it until someone challenges the report.

What I Built

The Cybersecurity Intelligence Framework is my attempt to make this operational.

Five-stage intelligence cycle with a trigger question, real example, and AI prompt at each stage. Four reasoning modules — Strategic, Adaptive, Perceptual, Attribution — with a routing guide so you use the right lens for the right problem. An evidence discipline section that names the three categories every claim falls into and the five errors that kill reports. Four output templates with companion prompts. And a master prompt that takes any situation, routes it through the full framework, produces a first draft, and labels every inference and assumption explicitly.

The AI handles the structure. You handle the accuracy. That division is the whole system.

Who It's Actually For

Not just students. Anyone who needs to produce defensible cybersecurity output consistently — junior analysts writing first threat reports, bug bounty hunters whose findings keep getting marked informative, IT workers presenting security findings to management, researchers who need conclusions that survive peer review.

The problem is universal. The domain just happens to be cybersecurity.

Free preview is available — enough to understand the core problem and see the framework in action before committing to the full guide.

www.tagzauthor.com/l/cyber-intel-preview

More frameworks and guides coming. This is just the start.

Support TagzAuthor: ko-fi.com/tagzauthor
My author page: Amazon Bookstore

I Finally Finished the Tool I Abandoned — Here's What GitHub Copilot Actually Did

Tariq Davis — Sun, 07 Jun 2026 05:47:01 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Most people trying to record an audiobook fail before they ever hit record. Not because their voice is wrong or their book isn't ready, but because they lack a system for recording. They sit down, attempt a whole chapter, hit a wall twenty minutes in, and walk away with inconsistent audio that's harder to edit than it should be.

ATTUNE structures the recording before it starts. Paste a chapter, get a set of 30-minute session windows with vocal load scoring, cold read risk flags, and a performance register on each one. Built for a phone in a quiet room — no studio, no equipment budget, no production team.

Demo

🔗 github.com/FlowArchitect895/attune

The Comeback Story

The spec for this existed before the challenge. A detailed one — problem identified, features mapped, logic described. No code. Just a notes file that had been sitting there because there was always something more urgent.

The Finish-Up-A-Thon was the forcing function.

Before: A spec. A problem statement. No working tool.

After: A working MVP with three features the original spec didn't include — Vocal Load Scoring, Cold Read Risk Detection, and Performance Register Analysis. Those weren't planned. They came out of actually building the thing and noticing what was missing.

My Experience with GitHub Copilot

Copilot didn't write this app. It extended it — three times, at three specific points where I knew what I needed but hadn't written it yet.

Export Plan

First ask: generate a function that exports the session plan as a downloadable markdown file. Copilot scaffolded the entire thing — Blob creation, URL generation, auto-download. One prompt.

Cold Read Risk Detection

This one wasn't in the original spec. The idea came mid-build: authors sight-reading dense sentences mid-session is where takes get ruined. Flag those sentences before recording starts.

Copilot wrote the detection logic and integrated it into the existing analysis function. First pass was too aggressive — flagging short sentences that didn't need it. One refinement prompt fixed the thresholds.

Performance Register Detection

The deepest one. Asked Copilot to analyze each session's dominant emotional register using keyword frequency — TENSION, GRIEF, INTROSPECTION, DIALOGUE, ACTION, EXPOSITION — and surface it as a badge with a one-line performance note.

That single feature shifted what ATTUNE is. Not just a scheduler. A director.

Studio Anywhere Checklist

Eight items. No professional equipment assumed. The checklist exists because the tool is built for people who don't have studios — which is most of the people who want to make audiobooks.

Progress Tracking

Mark sessions done as you record. Watch the bar fill. No score, no gamification — just accumulation of real work completed.

I Built a Tool That What Actually Happens When You Let an AI Agent Hunt Your Own Blind Spots

Tariq Davis — Sun, 31 May 2026 03:31:32 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

The Tool That Investigated Me While I Was Building It

I didn't plan ECHO Hunt.

It came out of a simple question I kept sitting with: when you build something with AI, did you actually learn anything — or did the AI just carry you through it and you called it progress?

That question has weight when you're building alone. No CS degree, no bootcamp, no senior developer to tell you what you missed. Just you, an AI, and a string of errors that may or may not mean anything. That's how I build. That's how most people building with AI today build. And nobody has a tool that tells you the truth about what actually happened in a session.

So I built one.

Where the idea actually came from

Vibe coding is how I build. How most people build with AI now. You describe what you want, the AI generates it, you run it, fix errors, iterate. You ship something real. But there's a problem nobody talks about: you have no idea what you actually learned vs what the AI just did for you.

The forensic framing came naturally. I study Digital Forensics. My research group spent months building an academic proposal on IoT cybersecurity challenges in the Caribbean. I know what it means to investigate something without the right tools, without the right lab, without the institutional support that makes forensic methodology accessible.

That gap between what the framework assumes and what actually exists — that's the same gap between what vibe coding produces and what the builder actually retains.

ECHO Hunt applies forensic investigation logic to a vibe coding session. Not as a metaphor. As a structure.

The cognitive TTPs

Before I built anything, I needed a framework for what "blind spots" actually means. I didn't want a vague "learning reflection" tool. I wanted something that could name what went wrong the way a forensic report names evidence.

Four cognitive TTPs — Tactics, Techniques, and Procedures, borrowed directly from MITRE ATT&CK framing:

Borrowed Confidence — you accepted AI output without verifying it
Shallow Resolution — you fixed the error without understanding why it existed
Pattern Blindness — you repeated the same error class multiple times without recognizing it
Premature Exit — you moved on before your understanding was solid

These aren't personality judgments. They're patterns of behavior that appear in session logs. Observable. Huntable.

Why Hermes Agent specifically

The build needed something that could reason across an entire session log — not just summarize it, but investigate it. Form hypotheses before analyzing. Hunt each one against the evidence. Return structured output that the game layer could use without any additional AI calls during gameplay.

That's an agentic task, not a prompt task. A single LLM call can summarize. An agent can investigate.

Hermes Agent's skills system made this real. I created a custom skill called echo-hunt — procedural memory that Hermes loads and executes as a reusable investigation procedure. One call via hermes -z and the entire hunt runs: hypotheses formed, evidence collected, TTPs mapped, attribution challenges generated with locked correct answers and plausible distractors.

Everything pre-computed before gameplay starts. Zero AI calls during the investigation. The game runs entirely on cached data.

The part I didn't expect

I built the game layer to eliminate hallucination on the Evidence Integrity score. The first version of ECHO had Hermes generating a number — and it kept changing on identical inputs. Meaningless.

The fix was architectural. Remove the generated score entirely. Calculate it from player behavior instead:

Each TTP attribution you get right or wrong
Each pre-hunt declaration that matches or misses Hermes's findings
Each confirmed finding weighted by severity

Hermes provides the evidence. You interact with it. Your decisions produce the number.

That shift — from AI-generated to player-computed — is what made ECHO Hunt honest. The score isn't Hermes's opinion of your session. It's a record of how accurately you read your own blind spots.

What Hermes found about me

I ran ECHO Hunt on the session where I built ECHO Hunt.

Shallow Resolution [MODERATE]: Configuration issues were handled by repeatedly replacing files rather than analyzing why the specific settings were failing.

Borrowed Confidence [HIGH]: Acceptance of a large-scale UI rewrite immediately following a minor skill update, assuming the logic was correct without testing.

Premature Exit [LOW]: Using a wait-time heuristic to resolve a loading screen issue instead of implementing a proper readiness check.

The confirmed finding that hit hardest:

"The sequence of 'still not working' → 'try changing format' → 'config is getting corrupted' → 'paste in a clean config' shows a lack of diagnostic precision."

That's not a generated critique. That's evidence from my own session. I spent hours trying to get the Hermes gateway API server running on port 8642. Every attempt fixed the surface. None of them diagnosed the root cause. Eventually I pivoted to hermes -z as a CLI approach — which worked immediately. Shallow Resolution, confirmed.

The tool I built to catch blind spots caught mine. That's either ironic or exactly the point. Probably both.

The cultural layer

There's no forensic lab in Jamaica built for this. No senior dev ecosystem, no bootcamp pipeline that hands you a structured environment and says "learn here." What exists is curiosity, whatever tools you can access, and the willingness to figure it out.

That's just the reality. And it shaped everything about how ECHO Hunt was built and who it's for.

The self-taught builder outside formal systems doesn't need another tutorial. They need something that tells them the truth about what happened in the session they just finished — not what the AI thinks they learned, but what the evidence shows. The gap between those two things is where real growth either happens or doesn't.

ECHO Hunt exists in that gap. It treats your thinking like it matters enough to investigate. Not because you went to the right school or work at the right company — but because you showed up, built something, and deserve to know what you actually walked away with.

That's what a tool for the Caribbean builder looks like. That's what I wanted to make real.

🎥 Watch the full demo

🔗 github.com/FlowArchitect895/echo-hunt

I Built a Cognitive Threat Hunter on Hermes Agent — It Analyzed the Session Where I Built It and Found Three Blind Spots

Tariq Davis — Sun, 31 May 2026 02:59:39 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

What I Built

ECHO Hunt — a cognitive threat hunter for vibe coding sessions built on Hermes Agent.

Vibe coding is how most people build with AI today. You describe what you want, the AI generates it, you run it, fix errors, iterate. It works. But did you actually learn anything, or did the AI just carry you through it?

ECHO Hunt finds out. Paste your session log, declare your blind spots before the evidence arrives, then face what Hermes actually found.

It's not a report generator. It's an investigation you participate in.

Demo

🎥 Watch the full demo

Code

🔗 github.com/FlowArchitect895/echo-hunt

My Tech Stack

Hermes Agent + echo-hunt skill
Node.js + Express
Vanilla HTML/CSS/JS

How I Used Hermes Agent

The echo-hunt skill

Hermes Agent runs a custom skill called echo-hunt. It takes a vibe coding session log and performs a cognitive forensic hunt — forming hypotheses before analyzing anything, hunting each one against the evidence, and mapping findings to four cognitive TTPs:

Borrowed Confidence — accepted AI output without verification
Shallow Resolution — fixed the error, didn't understand why
Pattern Blindness — repeated the same error class without noticing
Premature Exit — moved on before understanding was solid

The architecture

ECHO Hunt calls hermes -z with the echo-hunt skill prompt. One call. Hermes pre-computes the entire investigation — hypotheses, findings, TTP classifications, attribution challenges with locked correct answers and plausible distractors. Zero API calls during gameplay. Everything runs on cached data.

The declaration layer

Before Hermes hunts, you declare your blind spots. Three questions. You commit to answers before the evidence arrives. This is the adversarial layer — you vs your own perception of what happened.

The confrontation layer

Your declarations face what Hermes found. Three outcomes:

Signal — you caught what Hermes caught
Ghost — Hermes found something you missed entirely
Noise — you flagged something Hermes didn't

The challenge layer

Each confirmed finding becomes a TTP attribution challenge. 4 options, 20-second timer. Wrong answer drops integrity 10%. Correct answer earns points. The timer is the pressure — forensic decisions don't wait.

The verdict

The Evidence Integrity score is computed from actual player behavior — signals vs ghosts, correct vs wrong TTP attributions. Hermes doesn't generate the number. You produce it.

What Hermes found about me

I ran ECHO Hunt on the session where I built ECHO Hunt. Here's what it found:

Shallow Resolution [MODERATE] — Configuration issues were handled by repeatedly replacing files rather than analyzing why the specific settings were failing
Borrowed Confidence [HIGH] — Acceptance of a large-scale UI rewrite immediately following a minor skill update, assuming the logic was correct without testing
Premature Exit [LOW] — Using a wait-time heuristic to resolve a loading screen issue instead of implementing a proper readiness check

The confirmed finding that hit hardest: "The sequence of 'still not working' → 'try changing format' → 'config is getting corrupted' → 'paste in a clean config' shows a lack of diagnostic precision."

That's not a generated critique. That's evidence from my own session, hunted by the tool I was building while I was building it.

The Full Report

The downloadable Cognitive Threat Report captures everything — pre-hunt declarations, hunt hypotheses, confirmed findings, TTPs with severity, genuine understanding moments, and next session focus. It's a real document, not a game summary.

What makes it different from a standard AI analysis: the pre-hunt declarations are locked in before Hermes runs. So the report shows not just what happened in the session, but the gap between what you thought happened and what the evidence shows. That delta is the most useful thing in it.

What Happens When the Breach Happens Somewhere the World Forgot to Defend

Tariq Davis — Sun, 17 May 2026 04:36:09 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

What Happens When the Breach Happens Somewhere the World Forgot to Defend

I'm a 21-year-old Cybersecurity and Digital Forensics student at Caribbean Maritime University in Jamaica. My research group spent months building an academic proposal on IoT forensic challenges in the Caribbean — the gap in standards, the resource constraints, the fact that most forensic frameworks were designed for labs that don't exist here.

That research sat in a document. It felt incomplete. Not wrong — just theoretical.

Then I built Threat Trace in 12 days for the Gemma 4 Challenge and something clicked.

The problem I kept running into

Caribbean institutions — hospitals, universities, government facilities — are deploying IoT devices at scale. Smart sensors, networked cameras, connected infrastructure. Most of it is third-party managed, under-resourced, and running firmware that hasn't been updated in years.

When a breach happens, the forensic playbook assumes things that don't exist here. Dedicated forensic hardware. Large IT teams. Vendor support that shows up same-day. Regulatory frameworks that actually map to the local legal environment.

None of that is guaranteed in Jamaica. Most of it isn't there at all.

So when I started thinking about what to build for this challenge, I didn't want to build another generic demo. I wanted to build something that made the problem tangible — not a report you read and forget, but something you feel.

Why a simulator and not a tool

There's a difference between knowing forensic methodology and understanding why it matters.

I've studied the 6-stage forensic process. I know what chain of custody means. But reading about it and making a decision under pressure are different things. The second one sticks.

I built Threat Trace so that when you choose to reboot a compromised sensor instead of isolating it first, you feel it. The integrity meter drops. The feedback tells you exactly what you just destroyed. And then you have to keep going with contaminated evidence.

That's the lesson. Not a textbook explanation — the consequence.

The game generates a full investigation from any IoT incident you describe. Gemma 4 31B reads your scenario and builds 6 forensic stages, each with real decision points, real evidence, and real consequences for wrong choices. At the end you download a forensic report — actual methodology, actual findings, usable outside the game.

How I actually built it

I didn't start with code. I started with a scenario.

"A smart water pressure sensor at a children's hospital in Mandeville began sending encrypted packets during maintenance windows — always 1AM-3AM, never consecutive nights. A nurse in the maternity ward noticed hot water pressure dropped every time the anomaly occurred."

I wrote that prompt and fed it to Gemma 4 through the Google AI Studio API. What came back wasn't what I expected.

Gemma didn't just map an attack technique. It identified a function in the generated firmware called trigger_valve_bleed() — called immediately before send_encrypted_payload(). The physical pressure drop wasn't a side effect. It was a signal. The attacker was using the hospital's water valves as an out-of-band heartbeat to confirm successful exfiltration to a local observer.

I didn't tell Gemma to find that. It reasoned to it from context.

It also caught that the non-consecutive timing was deliberate evasion of threshold monitors. And it noted that a nurse — not IT, not a SIEM alert — was the first line of detection. That detail is the most Caribbean thing in the whole report. And Gemma put it there.

That's when I knew the model could carry this build.

The architecture decision that made it free to run

One API call per investigation. That's it.

When you submit a scenario, Gemma generates everything upfront — all 6 stages, every choice, every consequence, every narrative, the full report. During gameplay there are zero API calls. Every response is instant because it's already computed.

This matters because the communities this tool is meant for can't afford per-request costs at scale. Front-loading the generation makes free 24/7 deployment viable. Cached scenarios cost nothing to replay.

The structured JSON output from Gemma 4 was critical here. The model's thinking mode can produce loose text that breaks parsing. Forcing the output format through the API config takes the parse failure rate from around 50% to near-perfect. The game state is deterministic — the correct answer is pre-computed, so scoring requires no AI at runtime.

Why Gemma 4 31B specifically

Three reasons that weren't negotiable.

Context window. IoT incidents don't happen in isolation. Logs from 12 sensors, network captures, firmware analysis, infrastructure context — it all needs to be in one prompt for the model to reason across it. Gemma 4 31B's 256K context window handles that. Most open models cap at 8K-32K. That's not enough.

Structured output. The game lives or dies on clean JSON. Gemma 4 delivers it when you configure the output correctly.

Open model. The whole point of this build is accessibility. Using a closed API to solve an accessibility problem is a contradiction. Gemma is open. Anyone can run it locally, self-host it, extend it. That matters for the communities this is built for.

What the Caribbean context actually changes

Most forensic simulators are built for abstract environments. Generic corporations, unnamed cities, fictional institutions.

Every case Threat Trace generates is grounded in real Caribbean constraints — NWC managing critical hospital infrastructure remotely, university IT volunteers running forensic investigations with borrowed hardware, JCF Cybercrime Unit reporting requirements, the Jamaica Cybercrime Act.

When Gemma generates a case set in Mandeville or St. Elizabeth, it doesn't just change the location. It changes the available resources, the institutional dynamics, the observation chain. The Mandeville hospital case had a nurse as the first line of detection because the IT team was small and overwhelmed. Gemma inferred that from the context I gave it.

That specificity is what makes the tool feel real rather than academic.

What I actually learned

I started this as a student who'd written a research proposal about IoT forensics in the Caribbean. I finished it having built something that demonstrates the problem more clearly than the proposal did.

The 40/60 score and 70% evidence integrity on my first run through my own simulator told me more about my actual forensic decision-making than any exam has.

Gemma 4 didn't just power the build. It challenged me inside it.

That's what an open model at this capability level makes possible — not just better apps, but tools that give real feedback to the people who need it most, running in environments that can't afford anything else.

🎮 Play Threat Trace →

🔗 GitHub

I Built an IoT Forensic Investigation Simulator Powered by Gemma 4 — Paste Any Incident, Get a Full Case with Evidence, Decisions, and a Forensic Report

Tariq Davis — Sat, 16 May 2026 07:00:53 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

I built Threat Trace — an IoT forensic investigation simulator that takes any incident scenario and turns it into a playable 6-stage investigation, powered by Gemma 4 31B.

You describe an incident. Gemma reads it and generates a complete forensic case — real evidence, real decision points, real consequences. Every stage puts you in front of a choice. Wrong calls contaminate your evidence or break chain of custody. At the end you get a downloadable forensic report you can actually use.

This isn't a quiz. It's a training tool built for people who don't have access to expensive forensic labs — specifically designed around the Caribbean institutional context: small IT teams, limited hardware, JCF Cybercrime Unit reporting requirements, and the kinds of incidents that actually happen here.

Demo

🎮 Play Threat Trace →

Try the pre-loaded scenarios or paste your own IoT incident. Every input generates a unique case.

Code

🔗 github.com/FlowArchitect895/Threat-Trace

How I Used Gemma 4

I chose Gemma 4 31B Dense. Here's why that was the only real option for this project.

The Architecture: Front-load everything

Gemma does all the heavy work once — at generation. When you submit a scenario, one API call produces the entire investigation: all 6 stages, every choice, every consequence, every narrative, and the final report. During actual gameplay there are zero API calls. Every response is instant because it's already been computed.

This makes free 24/7 deployment viable. Cached scenarios cost nothing to replay.

Why 31B Dense specifically

256K context window. IoT incidents don't happen in isolation — they involve logs from multiple devices, network captures, firmware dumps, infrastructure context. I needed a model that could hold an entire incident in one prompt and reason across all of it. No other open model has that context window.

Structured output reliability. Gemma 4's thinking mode produces clean, parseable JSON when you force the output format correctly. Without it the parse failure rate is around 50%. With it — near perfect. The game state depends on deterministic output, so this wasn't optional.

Open model. The whole point of this build is accessibility. Running on a closed API defeats that for the communities this tool is meant to serve.

What Gemma actually does

The depth surprised me. I threw this at it:

Gemma mapped it to T1041 — Exfiltration Over C2 Channel and built the case around an Industrial IoT water pressure sensor. But it didn't stop at the attack technique. It identified that the pressure drop was caused by a function called trigger_valve_bleed() — executed immediately before send_encrypted_payload(). The physical action preceded the data transmission. That means the attacker was using valve actuation as an out-of-band heartbeat to confirm successful exfiltration to a local observer.

It also caught that the non-consecutive timing wasn't random — it was deliberate evasion of basic threshold monitors. And it flagged the exfiltrated payload as internal VLAN mapping data, identifying the sensor as a pivot point for lateral movement, not the final target.

A nurse found the breach. Not IT. Gemma put that in the analysis without being told to.

That's adversarial reasoning. Not pattern matching.

The Caribbean context layer

This is what makes it different from a generic forensic simulator. Every generated case includes:

Resource constraints realistic to Jamaican institutions — the Mandeville case used university tools to compensate for limited forensic hardware budgets
JCF Cybercrime Unit and Jamaica Cybercrime Act reporting requirements
Third-party utility dependencies — NWC managing critical hospital infrastructure with no on-site visits in 8 months
The human observation chain — a nurse, not a security system, was the first line of detection

That last point is the most Caribbean thing in the report. And Gemma put it there without being told to.

The downloadable report reflects all of this — not a game score, an actual forensic document.

Judging criteria mapped

Intentional model selection — 256K context for multi-artifact IoT scenarios, structured JSON for game state reliability, open model for the communities this serves.

Technical implementation — front-loaded generation, zero-cost runtime, structured output parsing, deterministic scoring with pre-computed consequences.

Creativity — IoT forensics as an interactive investigation with real physical consequence. A water pressure drop in a maternity ward as the first indicator of compromise. Caribbean context as a first-class feature, not an afterthought.

Usability — three preloaded scenarios, open input for any incident, downloadable forensic report with real methodology output that investigators can actually use.

Most Beginners Approach Bug Bounty Completely Wrong

Tariq Davis — Sat, 09 May 2026 01:24:17 +0000

Bug Bounty Isn’t What You Think It Is

By Tariq Davis

I’m not a veteran bug bounty hunter.

I’m a cybersecurity student who got curious about how people legally get paid to break systems. That curiosity pulled me into bug bounty, and the first thing I noticed was how messy the beginner information is.

Most content either:

assumes you already know what you’re doing,
or turns simple ideas into overly technical theory.

So I started building the kind of guide I wish I had when I began.

No hype. No fake “make thousands overnight” promises.

Just the actual framework.

What Bug Bounty Actually Is

Bug bounty programs are simple in concept:

Companies pay independent researchers to find and responsibly disclose vulnerabilities in their systems.

You:

test systems that are in scope,
find a vulnerability,
write a report,
submit it,
and get paid if it’s valid.

That’s the model.

What makes it interesting is the incentive structure behind it.

The company wants weaknesses discovered before malicious actors find them. You get rewarded for helping expose those weaknesses legally and responsibly.

It’s one of the few spaces where the attacker mindset and business incentives genuinely align.

The Severity Ladder Beginners Misunderstand

A lot of beginners enter bug bounty thinking about massive payouts immediately.

That mindset usually kills consistency before it even starts.

Here’s the reality:

P1 — Critical

Remote code execution. Full account takeover. Large-scale compromise.

Huge payouts.
Not beginner territory.

P2 — High

Authentication bypasses, major exposure issues, serious privilege escalation.

Possible later on.
Still difficult.

P3 — Medium

IDORs. Stored XSS. CSRF.

This is where beginners should realistically focus.

Real vulnerabilities. Real learning. Real payouts.

P4 — Low

Information disclosure. Open redirects. Missing security headers.

A lot of first accepted reports land here.

And honestly? That’s fine.

A P4 still proves:

your process worked,
your report was accepted,
and you successfully navigated a real security workflow.

That matters more than chasing criticals on day one.

The Real Skill Isn’t “Finding Bugs”

This is the part most beginner content misses completely.

Bug bounty isn’t just about running tools and hoping something appears.

The real skill is learning how to understand systems.

The best researchers spend huge amounts of time on:

recon,
mapping attack surfaces,
identifying patterns,
and understanding how applications behave.

You’re not just searching for vulnerabilities.

You’re building a map.

And once the map becomes clearer, the weaknesses become easier to notice.

That shift in perspective changes everything.

Why Most Beginners Burn Out

A lot of people approach bug bounty like a lottery system:

random target,
random tools,
random expectations.

Then they quit after finding nothing for weeks.

But bug bounty is closer to pattern recognition than gambling.

The early stage is mostly:

learning systems,
improving observation,
documenting behavior,
and building methodology.

That foundation matters more than flashy payouts.

Final Thoughts

The free preview of the Bug Bounty Starter Kit was designed specifically for beginners who want a grounded introduction without the noise.

It covers:

what bug bounty actually is,
how severity works,
and where beginners realistically belong.

The full guide expands from there into tooling, recon workflows, reporting structure, and practical execution.

Free preview of the Bug Bounty Starter Kit:
https://www.tagzauthor.com/l/bugbounty-preview

More cybersecurity frameworks and beginner-focused guides are coming soon.

Support TagzAuthor: ko-fi.com/tagzauthor
My author page: Amazon Bookstore