RFQ intake, step by step
Pick one of six prepared requests and walk it through eleven stages. The logic is real and runs in your browser; the data is invented. Nothing you do here is sent anywhere or stored.
Interactive workflow demonstration
Choose a prepared request
Step 1 of 11
Clean email RFQ
Intake
What arrived, recorded before anything runs
The message is recorded exactly as received and given a reference before any rule runs, so every later step can be traced back to a specific arrival.
- Reference
- DEMO-CLEANE
- Channel
- Received
- 2026-03-09T08:14:00Z
- Sender
- Dana Whitfield <dana.whitfield@northlineprecision.example>
- Subject
- RFQ — NP-5514 Rev B, two quantities
- Attachments
- None
Message body
Morning, Please quote NP-5514 Rev B. We need pricing at 25 and 100 pieces. Material is 6061-T6, clear anodize after machining. Delivery needed by 04/17. Drawing is unchanged from what you have on file. Let me know if you need anything else. Thanks, Dana Whitfield Purchasing, Northline Precision
Stage 1 of 11: Intake. Example: Clean email RFQ.
Read this before drawing conclusions
What this demonstration does not prove
Not proven here
- That fields can be extracted from arbitrary real documents. The fixtures are clean text; real requests are forwarded threads, scans and screenshots.
- Any production accuracy figure. No accuracy percentage is published anywhere on this site, because none has been measured on real data.
- Compatibility with your ERP, CRM or quoting system. Nothing here connects to any system.
- Any ability to interpret a technical drawing. Attachment text is supplied with the fixture, not read from a PDF or a model.
- Any ability to price a job. No pricing logic exists here and none is proposed.
- Client results, savings or reliability at volume. There are no client projects.
Genuinely demonstrated
- Workflow design: the order of operations, and where the process is designed to stop
- Review interface design: what a reviewer sees before deciding
- How uncertainty is presented — per field, with source and certainty, rather than one opaque score
- Routing logic with the full rule evaluation exposed, including rules that did not match
- Exception handling: gaps, conflicts and duplicates each have a defined destination
- Structured output that carries its own uncertainty into the next system
- Audit-trail design covering both automated steps and human decisions
Teardown
How it is built, and how a production version would differ
Problem
A shared inbox receives quote requests in incompatible shapes. A person reads each one, decides what it is, extracts the details, checks whether it is already open, and routes it. That work is repetitive, invisible, and it stops when that person is busy.
The naive automation is to extract fields and create records. That fails in production for a predictable reason: the interesting cases are the ones where the request is incomplete, contradictory or a repeat, and a system that quietly picks a value in those cases is worse than the manual process it replaced.
Architecture
- Execution
- Pure TypeScript functions with no side effects, running client-side in this page. Same input, same output, every time.
- Stages
- classify → extract → find gaps → detect conflicts → check duplicates → score → route. Each stage takes the previous stage’s output and adds to it; none of them mutates the message.
- Rules
- Classification (CL-1 to CL-5) and routing (RT-1 to RT-7) are ordered lists evaluated first-match-wins. Every rule keeps its identifier so a decision can be explained after the fact.
- Extraction
- Pattern matching plus dictionary lookup for materials and finishes, with a register check on part-number prefixes so a pattern match alone never counts as confirmation.
- Scoring
- Arithmetic: 100 minus penalties for unestablished fields, conflicts, unmatched customers and unconfirmed parts. It is deliberately not a probability, because presenting an arithmetic score as a model confidence would be a lie a buyer cannot check.
- Testing
- The logic is covered by unit tests for the matchers, per-fixture pipeline behaviour, determinism, immutability of the result on human decision, and the requirement that nothing is ever marked as written.
Data flow and state transitions
received ──▶ classified ──▶ extracted ──▶ evaluated
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
awaiting_human_review (gaps present) (conflicts present)
│ │ │
└─────────────────────┴─────────────────────┘
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
approved_for_write held_for_information rerouted_by_human
│
▼
(production only) written to system of record, idempotency key appliedEvery path leads to awaiting_human_review. There is no transition from an automated stage directly to a write. In this demonstration the final transition does not exist at all — no system is connected.
Human approval
The review step is the product. It shows the reviewer four things at once: what was read, how certain each field is and where it came from, what is missing, and what the rules propose to do about it.
An override is treated as information rather than as a correction to be swallowed. When a reviewer reroutes an item, the audit trail records the override and flags the rule that produced the original proposal, because a rule that is regularly overridden is a rule that is wrong.
Failure modes
- Wrong classification
- Mitigated by requiring both quoting vocabulary and structural evidence — a part number and a quantity — before something is treated as an RFQ. Anything short of that becomes "unclear" and goes to a person.
- Confident wrong extraction
- The most dangerous failure. Mitigated by certainty and source on every field, register validation on part numbers, and refusing to fill a field the text does not state.
- Silent conflict resolution
- Prevented by design: when two sources disagree, neither value is selected and the item is routed to review with both shown.
- Duplicate records
- Detected against the open-request register here. In production the same protection is enforced at the write with an idempotency key, so a retried delivery cannot create a second record.
- Upstream outage
- In production, a mailbox or API failure sends work to an error queue with backoff, and an empty run still reports, so silence is never mistaken for success.
- Rule drift
- Rules stop matching as customers change how they write. Mitigated by tracking override rates and reviewing the rules that are overridden most.
Security boundary
- In this demonstration
- Everything runs in your browser. There is no upload, no free-text input, no network request, no persistence and no analytics on this page. Nothing you click is recorded.
- Data
- All companies, people, part numbers and documents are invented for this page. No client data, no real request and no real project appears anywhere on this site.
- In production
- Mailbox access uses least-privilege scopes and credentials the client creates and owns. Message bodies and attachment contents are not written to application logs. Retention is agreed in writing and implemented.
- Restricted data
- Export-controlled technical data, controlled unclassified information and CMMC-scoped material are not accepted through this demonstration or the contact form.
What a production integration would add
- Real mailbox ingestion with delivery notifications or scheduled polling, and deduplication on message identifiers
- Genuine document handling for attachments, scoped narrowly to the formats a specific client actually receives, with accuracy measured on their real mail before anyone relies on it
- A durable queue and datastore for items awaiting review, with agreed retention
- Writes into the system of record through whichever integration path is available, with idempotency keys and reconciliation
- Alerting into a channel the team already reads, and a report that is sent even when it is empty
- Shadow-mode operation for an agreed period, comparing proposed routing against what people actually did
Request a workflow review
Compare this to your actual intake
Bring three real requests from last week — ideally the awkward ones. Thirty minutes is enough to say whether intake automation is worth investigating for your shop, or whether the honest answer is no.
30-minute review. You receive a concise written recap. No obligation.
Engagement capacity is intentionally limited so discovery, implementation and handover remain founder-led.