Tech stack
Today
| Area | Choice |
|---|---|
| Languages | Python · TypeScript |
| Website | Next.js · React |
| Services | FastAPI |
| Signatures | Ed25519 (offers, slips, approvals) |
| Understanding | Gemini for decisions, text, photos, and voice |
| Connections | Open web API · open connector (MCP) · Telegram |
| Data | SQLite for the demo · Postgres and vector database for production |
| Visibility | OpenTelemetry + readable audit log |
| Proof | Automated tests and scripted demos |
| Live site | aimoassist.com |
Built on Valio’s product catalog (~17,500 items), reliability and carbon data, and a mock price/availability API.
What comes next
Stronger data store
Move from single-machine files to PostgreSQL so many kitchens can share a managed database. Add vector search so finding the right product or dish gets smarter. Diet and allergen rules still load completely every time (search never replaces a safety check).
Clearer operations view
Widen OpenTelemetry so we see the whole path (website, Telegram, Valio door, open connector). Add Langfuse (or similar) so we can see where understanding is slow or expensive and improve it, without letting monitoring tools approve spend or change rules.
| Next step | Why it helps people |
|---|---|
| Postgres + better search | Ready for real multi-kitchen use |
| Better monitoring | Spot problems early; keep demos reliable |
| Hardware-backed keys | Production-grade signing |
| Delivery model with real outcomes | Sharper on-time estimates when history exists |
| Valio “offers to kitchens” | Seasonal deals that still need a human accept |
| Tests on every change | Rules stay proven as we grow |
Numbers still never come from a language model. Valio still re-checks every order. Monitoring watches; it does not sign.
Full list: Future work · Storage · Visibility