DEV Community: Kavin HBN

Rackwise: A Eurorack Agent That Separates Calculation From Evidence

Kavin HBN — Sun, 04 Oct 2026 03:35:14 +0000

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

What I Built

I started this challenge knowing almost nothing about Sanity.

Eurorack was new to me too. I had seen modular synthesizers before, but I didn't understand what HP meant, why module depth mattered, or how the different power rails were calculated.

After reading the challenge prompt, I started researching how people plan these systems.

That was when the problem became interesting.

A Eurorack module can look compatible but still be too wide, too deep, or draw more power than the case can safely provide. Specifications can also change between product variants. A result based on the wrong module page could look convincing while being completely wrong.

So I built Rackwise.

Rackwise lets someone assemble a rack row, choose a power reserve, and ask a question such as:

Does this row have enough space and power?

It checks:

available HP;
module depth;
+12V, -12V, and +5V power usage;
whether the retrieved sources cover the exact modules selected;
whether the source values agree with the local calculation.

The numerical checks are handled by a small TypeScript calculation engine.

Sanity supplies the source-backed knowledge.

The AI explains the result, but it is not allowed to quietly change the calculation or pretend that an unsupported source verified something.

The Part I Struggled With

Finding good sources was harder than connecting the model.

At first, I thought I could add every useful page I found and let the agent search through everything.

That quickly became messy.

Some pages were product pages. Some were manuals. Some discussed an older version of a module. Some contained a useful specification mixed with a lot of unrelated material.

The Knowledge Base also has a 150-document indexing limit. Instead of trying to fill that entire allowance, I reduced the corpus to a small set of focused manufacturer sources and specification files.

That worked much better.

It forced me to decide what information Rackwise actually needed:

the exact module name and variant;
width in HP;
physical depth;
current usage on each power rail;
case capacity;
the original source for each claim.

This was one of the biggest lessons from the project. More documents did not automatically produce a better answer. A smaller and more intentional corpus gave the agent cleaner evidence.

A Sanity Feature I Didn't Expect

One of the most useful parts of Sanity appeared when it found conflicts in the Knowledge Base.

For example, it found two recording-duration claims. One described Make Noise Morphagene, while another described a different recording mode on Phonogene.

They looked contradictory when placed together, but they were actually talking about different products and different modes.

Sanity surfaced both claims with their sources and asked me to resolve the issue.

The resolution then became a standing instruction for future Knowledge Base builds.

I found this genuinely useful.

It was not just finding text. It was helping me notice where the meaning of the content needed to be clarified.

That experience influenced how Rackwise handles module variants. If the selected rack contains Disting EX but the retrieved source describes Disting NT, Rackwise does not borrow the NT measurements.

It keeps the variants separate and marks the EX as unverified.

Why Structured Content Matters

A normal keyword search can find a page containing the word “Disting.”

That does not mean it found the correct Disting.

Expert Sleepers Disting EX and Disting NT have different dimensions and power requirements. Treating them as the same product would make the answer unreliable.

Rackwise converts retrieved specifications into individual claims containing:

the hardware being described;
the property being checked;
the value and unit;
the Knowledge Base path;
the original source when available.

Width, depth, and every power rail are compared separately.

This also means Rackwise can say that four modules are verified while one still needs a matching source. It does not turn partial coverage into a fully supported answer.

That is the part of Rackwise that would not work properly with keyword search alone.

Demo

Live app: https://eurostack.vercel.app/

No account is required.

Try this:

Open the Playground.
Add or remove modules from the rack.
Choose a power reserve.
Ask whether the row has enough space and power.
Open the Evidence view to inspect the retrieved claims.
Open the Trace view to see how the answer was produced.

The local rack calculation continues to work even if an external service is unavailable.

Code

Repository: https://github.com/Kavinhbn/Eurostack

I did not use an agent framework for the backend.

The workflow was small enough that I wanted the important boundaries to remain visible:

Validate the request
  -> calculate fit and power locally
  -> read the Sanity Knowledge Base through MCP
  -> choose entries for the selected hardware
  -> retrieve the relevant content
  -> extract source-backed claims
  -> reject unsupported sources and wrong variants
  -> compare the claims with the catalog
  -> generate a constrained explanation
  -> return the result, evidence, gaps, and trace

The project currently includes 33 tests covering the planner, MCP responses, claim extraction, source validation, module routing, coverage, and variant separation.

I also added per-device and per-IP request limits so a public demo cannot freely overload the model endpoint.

How I Used Sanity

Rackwise connects to a Sanity Context MCP endpoint backed by a Knowledge Base.

The Knowledge Base contains a focused collection of Eurorack material covering the example case, power supply, and selected modules.

For each request, Rackwise first reads the Knowledge Base outline.

It then chooses semantic entry paths based on the hardware inside the rack. It does not depend only on the wording of the user's question.

For example, Plaits is routed to its main specification entry instead of an unrelated firmware entry.

The retrieved content is then converted into bounded claims. Those claims are compared with the local catalog, and only validated claims are shown as evidence.

Sanity does not replace the numerical calculation.

It gives Rackwise the context needed to check whether its planning data is supported by real sources.

Sanity Project Details

Sanity project ID: 9uwokjoy

Knowledge Base ID: kbkdSiU3cFmU

Keeping the Answer Honest

I kept coming back to three separate layers:

Calculation: Does the rack fit, and does it stay inside the power limits?
Evidence: What do the retrieved manufacturer sources actually support?
Explanation: How can the result be communicated clearly?

Keeping these separate made the failure states easier to handle.

If the model fails, the numerical calculation still exists.

If Sanity cannot be reached, Rackwise labels the result as catalog-only.

If a source describes the wrong product variant, that source is not used to verify the selected module.

If a source-backed claim conflicts with an important planning value, Rackwise asks the user to review it instead of averaging the numbers or choosing one silently.

The Planner, Evidence, and Trace views expose these boundaries in the interface.

What I Learned

Before this challenge, “structured content” sounded abstract to me.

Building Rackwise made it practical.

The difficult part was not asking an AI model a question. The difficult part was deciding what information it could trust, which source belonged to which product, and what should happen when the evidence was incomplete.

Sanity helped me turn a small collection of documentation into something the agent could navigate and compare.

The conflict-resolution workflow was especially helpful because it treated ambiguity as something that should be reviewed, not hidden.

I came into this project without experience in Sanity or Eurorack hardware.

That made the research slower, but it also made the core problem very clear: if I could not understand where an answer came from, I should not expect someone to trust it with their hardware.

That idea became Rackwise.

Screenshots :

Rack planning and agent response

Sanity evidence coverage

Source-backed claims

Agent execution trace

We tried Reducto so our RAG pipeline would stop hallucinating table data

Kavin HBN — Thu, 27 Aug 2026 17:19:56 +0000

If you've ever built a RAG pipeline on top of real-world PDFs — not clean text files, but actual scanned evidence, policy docs, spreadsheets exported as PDFs, forms with checkboxes — you already know the dirty secret: parsing is the hard part, not the retrieval part.

I work on a GRC platform. Think audit evidence, compliance policies, control matrices — the kind of documents where a merged table cell or a checkbox actually matters, because someone downstream is going to make a judgment call based on what your pipeline extracted. "Close enough" text extraction isn't close enough when the output feeds into an AI evaluation step that's supposed to tell an auditor whether a control passed.

The problem we kept hitting

Our first pass used the usual suspects for PDF-to-text. It worked fine for prose. It fell apart the moment a document had:

Tables with merged cells or nested headers
Multi-column layouts that got read left-to-right across columns instead of down each one
Checkboxes and form fields that just vanished
Scanned pages that were "text" in name only

The output would look plausible, which is almost worse than it looking broken — you don't notice the row got scrambled until someone downstream asks why the AI matched evidence to the wrong control.

Where Reducto came in

We started evaluating Reducto as a parsing layer sitting in front of our RAG/matching pipeline instead of trying to keep patching regex and heuristics forever. The pitch is basically: send it the raw document, get back structured, LLM-ready output — markdown or JSON, tables preserved as tables, figures called out, page and bounding-box citations attached to every chunk.

That last part turned out to matter more than I expected. Having citations tied back to a literal region of the source page means when the AI pipeline says "this evidence supports this control," you can actually point at where on the page it's pulling that from, instead of trusting a black box. For anything audit-adjacent, that traceability isn't a nice-to-have, it's basically the whole requirement.

What actually got better

Table fidelity went from "usually fine" to "actually fine," including the annoying merged-header cases
We stopped hand-rolling special cases for scanned vs native PDFs
The chunking we fed into our matching logic got noticeably cleaner, which meant fewer weird false-positive matches
Debugging got easier because we could trace a bad match back to a specific bounding box instead of guessing

What I'd tell someone evaluating it

It's not magic, and it's not free — it's priced per page, so if you're processing huge volumes you'll want to actually run the math against your document mix before committing. It also won't fix a bad retrieval or matching strategy sitting downstream of it; it just gives you a much better foundation to build that strategy on.

If your RAG pipeline is choking on real-world documents rather than clean sample PDFs, and you've already ruled out "just write more regex," it's worth a real trial run against your actual document set rather than a demo PDF. The gap between "looks fine on a demo" and "survives your actual messy corpus" is where most of these tools live or die, and that's true of any parsing layer, not just this one.

Curious if anyone else building compliance/audit-adjacent tooling has landed on something different for this — always interested in comparing notes on what breaks first.

Trying it before committing to it

The free tier is generous enough to actually run a real trial instead of just kicking the tires on a sample PDF — you can throw your own messy documents at it and see how the table/checkbox/scan handling holds up before you touch a credit card. That mattered to us, because a demo PDF always looks great; it's your own weird internal export that tells you the truth.

The API is straightforward — send a document, get back structured output — and webhooks mean you're not stuck polling a job status endpoint for larger files, which is nice when you're parsing in bulk instead of one-off.

Worth noting: Vanta uses it too, which was a decent signal for us since they're solving a similar-shaped problem — compliance evidence, policy docs, the same kind of messy-document-meets-structured-output challenge. Wasn't the deciding factor, but it didn't hurt.

If you're past the free tier and need real volume or specific compliance guarantees (SOC 2, data residency, that kind of thing), that's an enterprise conversation with their team rather than a self-serve toggle — expected for anything handling sensitive documents at scale, but worth knowing going in so it doesn't surprise you mid-eval.

Why I’m Thinking of Switching My Portfolio to Astro.js ..

Kavin HBN — Sat, 04 Jul 2026 08:12:55 +0000

Why I'm Thinking of Switching My Portfolio to Astro.js

Lately I have been spending most of my time building auditing dashboards. Working on data-highly interactive applications changes the way you think. After a while my default workflow became simple: create a new React + Vite project. Start coding.

It's a stack for building web applications.

When I looked at my personal portfolio and blog, I stopped and asked myself:

Why am I using the setup for a website that is mostly static?

A portfolio is not a dashboard. It does not manage state, update data in real time, or require every component to become interactive the moment the page loads.

Yet with my React setup the browser still has to download and execute JavaScript for the entire application before everything becomes interactive.

While browsing through developer blogs and discussions, I kept seeing one framework mentioned again and again: Astro.

The more I read about it, the more it seemed designed for exactly this type of website.

The Problem with Hydrating Everything

A typical React application works by hydrating the page.

For example, a React application starts like this:


import ReactDOM from "dom/client";

import App from "./App";

ReactDOM.createRoot(document.getElementById("root")).render(

<App />

);

Everything inside ``eventually becomes part of one large JavaScript application.

Before users can fully interact with the page, the browser needs to:

Download the JavaScript
Parse it
Execute it
Hydrate the UI

For applications like dashboards admin panels or collaborative tools, this trade-off is completely reasonable.

For a portfolio?

Most visitors just want to

Read about you
View your projects
Open your GitHub
Read your blog

Hydrating the page feels unnecessary.

I mean think about it. My portfolio does not need to be interactive all the time.

Astro Takes an Approach

Astro follows a different philosophy.

Of assuming everything needs JavaScript, it assumes nothing does.

A simple Astro page looks like this:

`astro

const title = "My Portfolio";

{title}

Hello I'm Kavin

Welcome to my portfolio.

When you build the project:

`bash

npm run build

Astro outputs HTML.

That means visitors immediately receive content without waiting for a JavaScript bundle.

I like that.

Islands Architecture

One of Astro's interesting ideas is **island architecture.

By making the whole page interactive, Astro only hydrates the components that actually need JavaScript.

For example:

`astro

import ThemeToggle from "../components/ThemeToggle.jsx";

import ProjectCarousel from "../components/ProjectCarousel.jsx";

My Portfolio

Here the page itself remains static.

Only the components that need interactivity receive JavaScript.

That's really cool.

Client Directives

Astro gives you control over when a component should become interactive.

`client:load`

`astro

What it does

Downloads JavaScript immediately
Hydrates soon as the page loads

Best for

Theme toggles
Navigation menus
Search boxes
buttons

I can see why this is useful.

`client:visible`

`astro

What it does

Waits until the component appears on the screen
Downloads JavaScript only when needed

Imagine your portfolio contains an interactive project carousel near the bottom of the page.

If a visitor never scrolls far, Astro never downloads its JavaScript.

That's bandwidth saved without writing any optimization code.

Why This Matters

Instead of sending JavaScript for everything upfront, Astro sends JavaScript only where it's actually needed.

That means:

Smaller JavaScript bundles
Faster page loads
Lower memory usage
Better Core Web Vitals
Less work for the browser

For content websites, this approach makes a lot of sense.

I think it's a fit for my portfolio.

SEO Benefits

Another thing I like is how Astro handles SEO.

Since pages are rendered as HTML by default, search engines can immediately read the following:

Page title
Meta description
Headings
Content
links

They don't have to wait for a large JavaScript application to finish executing before indexing the page.

For blogs and portfolios, that's an advantage.

Where Astro Makes the Sense

After reading more about Astro, I realized it fits perfectly for websites where content's the main focus.

Some examples include:

Developer portfolios
Personal blogs
Documentation websites
Company landing pages
Marketing websites
E-commerce storefronts where fast loading improves user experience

That does not mean React is obsolete.

If I were building another auditing dashboard with forms, charts, filters, and live updates, I'd still reach for React without hesitation.

The tool simply matches the problem.

I like that.

Final Thoughts

This was not really about finding a "framework.

It was about choosing the one for the job.

For years my mindset was

"I'll just use React."

Now it's becoming:

"What does this project actually need?"

For interactive web applications, React is still one of the best choices available.

For a portfolio or blog Astro's approach of shipping static HTML first and loading JavaScript only when it's needed feels much more appropriate.

I'm seriously considering rebuilding my portfolio with Astro—not because React is not good enough. Because Astro seems like the better fit for the kind of website I'm trying to build.

Sometimes the biggest performance improvement does not come from writing code.

It comes from choosing the tool before writing any code at all.

Git for New Devs: Your Code's Grand Adventure !

Kavin HBN — Mon, 23 Jun 2025 10:39:13 +0000

Git for Beginners: A Simple Guide to Your Git Workflow

When you are learning Git, the number of commands can feel overwhelming.

The good news is that most of your day-to-day work follows the simple Git workflow.

Once you understand that Git workflow, handling problems like merge conflicts or rejected Git pushes becomes much easier.

Git for beginners can be easy to learn.

Think of Git as a journal for your project.

Every meaningful change is recorded so you can track your progress collaborate with others using Git and even travel back in time if something goes wrong with Git.

The Normal Git Workflow

Most of the time you will follow these steps in your Git workflow.

Step 1: Initialize Your Git Repository

When starting a project initialize Git inside your project folder using Git.

If you are using GitHub connect your Git repository to the remote Git repository using Git.


git init

If you are using GitHub you can connect your Git repository to the remote Git repository using Git.


git remote add origin https://github.com/your-username/your-repository.git

Now your local project knows where it should push and pull changes using Git.

Step 2: Stage Your Changes in Git

After writing or modifying code tell Git which files should be included in the next Git commit.

Stage every changed file in Git:


git add.

Or stage a file in Git:


git add app.js

Step 3: Create a Commit in Git

A commit in Git is a snapshot of your project at a specific point in time using Git.

Write meaningful commit messages that explain what changed in your Git project not that something changed in your Git project.


git commit -m " project setup"

Good examples of commit messages in Git are:


git commit -m "Add user authentication"

git commit -m "Fix login validation bug"

git commit -m "Update portfolio homepage"

Step 4: Push Your Changes in Git

Upload your commits to GitHub using Git.

The first push using Git:


git push -u origin main

Future pushes using Git:


git push

At this point your work is safely stored both locally and on GitHub using Git.

When Things Do Not Go as Planned in Git

Working is simple in Git.

Working with developers introduces a few common situations you will eventually encounter in Git.

Fortunately they are easy to fix once you understand what is happening in Git.

Problem 1: Push Rejected in Git

Sometimes Git refuses your push. Shows a message similar to this in Git:


Updates were rejected because the remote contains work that you do not have locally.

This means someone has already pushed commits to GitHub that you do not have on your computer using Git.

Git blocks your push to prevent overwriting their work in Git.

Solution: Pull First in Git

Download the changes from GitHub using Git.


git pull origin main

If your changes and the remote changes do not overlap Git merges everything automatically using Git.

Then simply push again using Git.


git push

Problem 2: Merge Conflict in Git

Sometimes both you and another developer edit the part of the same file in Git.

Git does not know which version should be kept in Git.

Of guessing it asks you to decide in Git.

You will see something to this in Git:


<<<<<<< HEAD

My version

=======

Their version

>>>>>>> origin/main

How to Resolve It in Git

Open the file and decide which code should remain in Git.

You can keep your version keep their version or combine both versions in Git.

After editing the file remove all the conflict markers in Git.

Then stage the file in Git.


git add filename

Create a commit in Git.


git commit -m "Resolve merge conflict"

Finally push your updated code in Git.


git push

Working Safely with Branches in Git

Branches let you develop features without affecting the main project in Git.

Create a new branch in Git.


git checkout -b feature/login

Work in Git.


git add.

git commit -m "Add login page"

Switch to the main branch in Git.


git checkout main

Merge your feature in Git.


git merge feature/login

Once merged your new feature becomes part of the project in Git.

Undoing Commits in Git

Everyone makes mistakes in Git.

Git provides ways to undo changes in Git.

View your commit history in Git.


git log --oneline

Undo the commit but keep your code in Git.


git reset --soft HEAD~1

Undo the commit and permanently remove those changes in Git.


git reset --hard HEAD~1

Use --hard carefully because the discarded changes cannot be recovered easily in Git.

Understanding `git status` in Git

One of the useful commands is in Git:


git status

It tells you exactly what is happening inside your repository in Git.

Common status indicators include:

| Symbol | Meaning

| ------ | ------------------------------ |

M` | Modified file |

| A | Newly added file |

| D | Deleted file |

| U | Unmerged file (merge conflict) |

| ?? | Untracked file |

Running git status frequently helps you understand what Git is tracking before committing in Git.

Common Git Workflow Cheat Sheet in Git

Initialize a repository in Git:

`bash

git init

Stage files in Git:

`bash

git add.

Create a commit in Git:

`bash

git commit -m "Your message"

Push to GitHub in Git:

`bash

git push

Download changes in Git:

`bash

git pull

Create a new branch in Git:

`bash

git checkout -b feature-name

Switch branches in Git:

`bash

git checkout main

Merge a branch in Git:

`bash

git merge feature-name

View commit history in Git:

`bash

git log --oneline

Check repository status in Git:

`bash

git status

Final Thoughts on Git

Git can seem intimidating at first but most developers use the same handful of commands every day in Git.

The basic Git workflow is simple:

Make changes in Git.
Stage them with git add in Git.
Save them with git commit in Git.
Share them using git push in Git.

As you collaborate with others you will occasionally encounter pull requests merge conflicts and branches in Git.

These are not signs that something's wrong. They are simply part of working with version control in Git.

The more you practice the more Git starts to feel less like a list of commands and like a reliable safety net for your code, in Git.

DEV Community: Kavin HBN

Rackwise: A Eurorack Agent That Separates Calculation From Evidence

What I Built

The Part I Struggled With

A Sanity Feature I Didn't Expect

Why Structured Content Matters

Demo

Code

How I Used Sanity

Sanity Project Details

Keeping the Answer Honest

What I Learned

Screenshots :

Rack planning and agent response

Sanity evidence coverage

Source-backed claims

Agent execution trace

We tried Reducto so our RAG pipeline would stop hallucinating table data

The problem we kept hitting

Where Reducto came in

What actually got better

What I'd tell someone evaluating it

Trying it before committing to it

Why I’m Thinking of Switching My Portfolio to Astro.js ..

Why I'm Thinking of Switching My Portfolio to Astro.js

Why am I using the setup for a website that is mostly static?

The Problem with Hydrating Everything

Astro Takes an Approach

Hello I'm Kavin

Islands Architecture

My Portfolio

Client Directives

client:load

client:visible

Why This Matters

SEO Benefits

Where Astro Makes the Sense

Final Thoughts

Git for New Devs: Your Code's Grand Adventure !

Git for Beginners: A Simple Guide to Your Git Workflow

The Normal Git Workflow

Step 1: Initialize Your Git Repository

Step 2: Stage Your Changes in Git

Step 3: Create a Commit in Git

Step 4: Push Your Changes in Git

When Things Do Not Go as Planned in Git

Problem 1: Push Rejected in Git

Solution: Pull First in Git

Problem 2: Merge Conflict in Git

How to Resolve It in Git

Working Safely with Branches in Git

Undoing Commits in Git

Understanding git status in Git

Common Git Workflow Cheat Sheet in Git

Final Thoughts on Git

`client:load`

`client:visible`

Understanding `git status` in Git