Spak rebuilds a 2018 intent-classification tax chatbot as a modern retrieval-grounded system. The hard part was never the model — it was making every answer verifiable. This is the product story: the problem, how Spak solves it, and where it's headed.
A general chatbot will answer a tax question instantly — and just as instantly invent a deduction limit or a bracket threshold that's plausible but wrong. For tax, "plausible but wrong" isn't a UX wrinkle; it's a filing error. The trust gap isn't fluency. It's that you can't see where the answer came from.
The product question wasn't "can it answer?" It was "can the user verify the answer without trusting us?"
Want a straight answer to a real situation — a Roth conversion, an RSU vest, a side business — without parsing a 40-page publication.
Need speed, but can't act on an unsourced claim. A citation they can click is the difference between useful and unusable.
Federal-only tools quietly mislead. State conformity differences are exactly where generic answers break — and where grounding pays off.
The unifying need: all three will forgive "let me check," but none will forgive a wrong number stated with confidence. That's why Spak is built around sourcing, not fluency.
Spak over-invests in the one thing that creates trust, and keeps everything else at "good enough" until the core promise is proven:
Hybrid dense + sparse search with cross-encoder reranking, so the answer cites the right passage — not a passage that merely sounds related.
Every number comes from real code behind a tool boundary, never the model. A bracket calc is reproducible and auditable.
Each answer carries clickable sources. The proof of trust is in the UI, not buried in a system prompt.
State rules treated as first-class, not an afterthought — the place generic tools fail is the place to win.
A good product is defined as much by what it leaves out. Each of these is a real, defensible feature, deliberately deferred so the core promise ships sharp instead of the whole thing shipping blurry.
Every decision in Spak traces back to one rule: the product never claims more than a user can verify. Tying the core promise — traceable answers — to something visible and clickable keeps every choice honest. If a feature doesn't make answers more verifiable, it waits. In a domain where a confident wrong number is a real cost, that discipline is the product.
Try the grounded demo, or read the architecture behind it.