Decision Hub
A deal desk where AI reads the brief, rules set the price, and a manager signs one exact quote.
- Role
- Solo — requirements, UX, backend, AI integration, testing
- Stack
- FastAPI, PostgreSQL, React + TypeScript, Claude API (optional)
- Timeline
- November 2026
- Status
- Prototype · 101 backend tests + 5 browser journeys
A quote is only as good as the brief behind it.
Sales sends briefs as free text. Details are missing, the analyst re-types the rest into a spreadsheet, prices are worked out by hand, and approval happens in a chat with no record.
Goal: one brief in; out come validated requirements, a policy-priced quote, a human decision on that exact quote, and a traceable proposal. Karsa, built later, takes the problem past approval.
From the product specAI does not decide the price and may not change the rate card; every final decision passes through a person.
The model has no price field.
Anything with money or approval in it is code or a person.
- 01
The model proposes, code decides
The model fills only seven requirement fields; its output schema has no price, discount or approval field. A deterministic engine prices on a versioned rate card.
- 02
Every value must show its source
Each field quotes its source sentence. A quote not found in the brief is downgraded to “verify”; missing information stays missing, never guessed.
- 03
Approval belongs to one revision
A manager approves a specific quote revision. Editing a field or re-pricing voids it, and nobody can approve a request they created.
- 04
Personal data stays on the server
Emails, phone numbers, ID numbers and named contacts are replaced with placeholders before any model call, then restored locally for the analyst.
Who touches a quote.
Five roles. Whoever creates a request can never approve it.
All five roles
| User | What they do in the app |
|---|---|
| Sales | Pastes the brief as received; sees only their own requests. |
| Deal-desk analyst | Checks the extracted fields, fixes gaps, prices the quote, issues the final proposal. |
| Operations | Confirms whether off-catalog work, like explainer videos, can be delivered. |
| Deal-desk manager | Approves or rejects one exact quote revision, with a reason when policy flags apply. |
| Auditor | Reads the full history of every brief and quote. |
Intake to a final, hashed proposal.
Source-quoted extraction, corrections as new revisions, rule-based pricing with policy flags, manager review, and a proposal issued exactly once.
Full feature list and 2 more screens
Intake, AI-assisted extraction with source quotes, validation, analyst corrections as new revisions, deterministic pricing with policy flags, operations and manager review, an exactly-once final proposal, mock email and CRM notifications, a dashboard built from the audit trail, and an evaluation set for the extraction step.
The workspace shows the original brief, extracted fields and the decision inspector side by side. Off-catalog explainer videos go to operations before the manager can approve. The proposal cites its quote, requirement and rate-card versions.
96.7% of fields right, 20.8% of briefs still priced wrong.
Scored on 60 labelled synthetic briefs. A high field score can hide a pricing gap, so the evaluation reports business impact, not just accuracy.
The baseline is a free rule-based extractor, not an LLM. The Claude run is built, not yet measured.
All test and evaluation results
| Check | Result |
|---|---|
| Backend tests (pricing oracle, approvals, concurrency, redaction) | 101 passing |
| Browser journeys with WCAG 2.2 AA scans | 5 / 5, 3 runs |
| Labelled synthetic briefs in the evaluation set | 60 |
| Rule-based baseline: field-level exact match | 96.7% |
| Rule-based baseline: valid briefs that would be priced differently | 20.8% |
| Personal data reaching the extraction provider | 0 of 60 cases |
| Pricing time, p95 over 1,000 quotes | 0.014 ms |
| Lighthouse accessibility, desktop and mobile | 100 |
Six finalize clicks, one proposal.
Prices match hand-calculated values. Self-approval, stale approvals and six simultaneous finalize clicks are tested; breaking a rule on purpose fails its test.
- Not yet: a live Claude evaluation, a hosted interactive demo (the product page is public; the app runs locally with Docker), or real users.
- Name redaction only catches names after cues such as “Contact:”.
More on testing and the evaluation set
Notification retries are fault-injected, and the dashboard is reconciled against raw audit events. CI runs all tests, the browser journeys and the Docker build on every push.
The generated half of the evaluation set shares phrasing patterns, so the 12 hand-written hard cases are what separate good extractors from weak ones.