Rackwise: A Eurorack Agent That Separates Calculation From Evidence

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:

1. Open the Playground.
2. Add or remove modules from the rack.
3. Choose a power reserve.
4. Ask whether the row has enough space and power.
5. Open the Evidence view to inspect the retrieved claims.
6. 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