ROSIE V2: proposed
system design
A short walkthrough of where ROSIE is today and what we propose, then open discussion of ISD's questions.
ROSIE, and why we're rewriting it
A companion to EWEB's SAP billing system. It works out how each property should be billed for stormwater and wastewater.
Today's goal: start the workflow redesign
Each step unlocks the next. The request to change EWEB's export waits on the redesign.
ROSIE setup today
Our earlier diagram merged them into one box. The AI prototype only ever touched QA.
ISD provides the environment. We run what's inside.
We recommend a VM with Docker Compose.
Where ROSIE V2 runs, step by step
A self-hosted workspace in the City's cloud runs old and new ROSIE side by side while we build.
ROSIE AI can propose. Only people can change data.
Three safe ways to approve. In each, the AI can only stage or propose. A person commits.
Let's discuss
Decisions to make together, and where each ISD question is answered.
PLATFORM AND HOSTING
REQUIREMENTS AND AI
ONGOING SUPPORT
Phase 2 showed what ROSIE AI can do
It's a search tool that checks every record, so staff find issues in minutes instead of weeks.
Monthly split-report gap between EWEB and the City
After ROSIE AI found the billing-adjustment edge cases
Tracing a $50k misbill across 12k installations
Why build ROSIE V2 on the platform
Shared tools replace custom code, so the build and the upkeep cost less.
Compared with the original quote
Linux or Windows for the VM
ROSIE's containers are Linux containers. On Windows they need an extra Linux layer underneath.
Foundry and Microsoft 365 Copilot reach the same models
The difference is who controls everything around them.
ROSIE's sign-in, now and later
Staff sign in with Microsoft Entra ID at every step.