Information buried in files
Products, quantities, and specifications arrive across email, PDF, Word, and Excel.
FIELD NOTES / SUPPLY CHAIN & OPERATIONS
Procurement.
Finally connected.
From the first RFQ email to the final invoice. A real procurement platform, engineered by Cosmoxyn to bring documents, decisions, and delivery into one workflow.
CASE STUDY 01
ProcuraFlow
Email-native procurement.
AI-assisted document intelligence.
ProcuraFlow / Connected operationsACTUAL PRODUCT INTERFACE
THE CONNECTING THREADOne RFQ. Its entire story.
Source email, line items, vendor quotes, and bid packets—in context.
Follow the workflow ↗RFQ intakeVendor sourcingPurchase ordersDelivery & invoicing
DOMAIN
Procurement & B2B distribution
WHAT WE BUILT
Web platform + email automation
OUR ROLE
Architecture to cloud & DevOps
01 / THE OPERATIONAL CHALLENGE
The transaction is connected.
The information isn’t.
An RFQ in the inbox. Vendor prices in a spreadsheet. A purchase order in another thread.
For procurement teams, the work continues between every system. Re-entering line items. Comparing supplier responses. Reconstructing what was quoted, awarded, shipped, and invoiced.
ProcuraFlow was built to preserve that continuity across the entire commercial transaction.
Decisions scattered across threads
Vendor replies and pricing need to stay attached to the right sourcing request.
History lost between handoffs
Post-award changes and partial shipments need a record teams can follow.
02 / INSIDE THE PRODUCT
Follow the work.
Keep the context.
Explore three views of the real platform.
Each makes another part of the transaction visible.
From unstructured email to inspectable data.
Extraction diagnostics expose the source content and run details, including tokens, cost, and latency. Teams can inspect what the model received instead of treating extraction as a black box.
THE FULL LIFECYCLE
RFQ→Sourcing→Bid comparison→Customer quote→Purchase order→Delivery→Invoice
03 / INTELLIGENCE WITH BOUNDARIES
AI where it helps.
Control where it matters.
Procurement needs more than a convincing answer. It needs structured records, consistent pricing, and decisions an operator can inspect.
Look under the hood ↘01
Read the incoming signal
Email content + extracted attachment text
Deterministic rules
Known markers and document patterns
AI interpretation
Bounded classification assistance
02
Extract into a defined schema
Structured output, validated before use
03
Keep decisions reviewable
Confidence, diagnostics, and human intervention
04 / THE TECHNOLOGY & THE REASON
The right tools.
A reason for each.
Behind the procurement workflow is a deliberately connected stack. Here is what each part does—and how the documented engineering choices support the operation.
THE WORKSPACE
React + TypeScript
The web interface brings RFQs, vendor bids, orders, and deliveries into one operational workspace.
Why it matters here
Shared types and schema contracts help the interface and backend agree on the shape of procurement data.
BUSINESS LOGIC
Node.js + Express
The API serves the application while a separate worker processes incoming documents and scheduled work.
Why separate the work?
Slow extraction jobs and retries can run without blocking normal user requests. Both processes share one codebase.
RECORDS & RELIABILITY
PostgreSQL + pg-boss
Procurement records and durable background jobs live in PostgreSQL, with Drizzle handling database access.
Why a database-backed queue?
Jobs survive worker restarts and support retries without operating a separate message broker.
DOCUMENT INTELLIGENCE
Bedrock + Claude Haiku
AI converts unstructured procurement documents into schema-constrained data. Rules handle clear classification signals first.
Why bound the AI?
Straightforward decisions remain deterministic and testable. AI is used where document interpretation adds value.
EMAIL & SOURCE FILES
SES + SNS + S3
AWS receives procurement emails and retains original messages and attachments for downstream processing.
Why keep the source?
Structured records remain connected to the documents that produced them, preserving context across handoffs.
SHARED DATA CONTRACTS
TypeScript + Zod
Shared schemas define API inputs, application types, and the expected shape of AI extraction output.
Why one definition?
Validation before operational use reduces contract drift between the interface, API, and extraction pipeline.
Explore the complete documented stack
Supporting libraries and integrations, grouped by their role in the platform. Reporting integrations apply where configured.
- Frontend & application state
- React 18 · TypeScript · Vite · TanStack Query · Redux Toolkit · React Router · Tailwind CSS · Recharts
- API & validation
- Node.js 20 · Express · TypeScript · Zod
- Database & background work
- PostgreSQL 16 · Drizzle ORM · pg_trgm · pg-boss
- AI & observability
- AWS Bedrock · Claude Haiku · Vercel AI SDK · Langfuse integration
- Email & storage
- AWS SES · AWS SNS · mailparser · Amazon S3
- Document processing & generation
- pdf-parse · mammoth · SheetJS · Puppeteer
- Reporting
- Recharts · Google BigQuery integration · Looker Studio integration
Technology names identify the project stack, not partnerships or endorsements.
A CONVERSATION ABOUT YOUR WORKFLOW
Where does your
workflow break?
Bring one operational bottleneck.
Let’s explore what a more connected system could look like.
20 minutes · Your workflow, constraints, and next step