01 — CONTEXT
The context
A national events company records its activity in its own time-tracking system on MySQL: hours, projects, phases, expenses, travel and changes. Seven years of operational data. The data already existed. The missing piece was a reliable intelligence layer: a daily reading management could trust, without touching the existing system.
02 — PROBLEM
The problem
Having data is not the same as being able to decide with it. This data had to be read carefully: hours logged late, expenses that can overlap between types, a public-holiday calendar that has not existed since 2022. A naive dashboard would have shown the wrong numbers with complete confidence.
03 — CONSTRAINTS
The constraints
- 01Do not modify the existing system or migrate its data.
- 02Read-only access, enforced on every database connection.
- 03People’s names hidden unless explicitly enabled.
- 04Do not calculate what the database does not contain: budgets, revenue, progress or margin.
04 — SYSTEM
What I decided to build
A read-only intelligence layer on top of the existing database: a daily and weekly briefing, a prioritized action plan, alerts with their evidence and an assistant to ask questions about the briefing.
05 — ARCHITECTURE
System architecture
SOFTWARE
Software
- A home view with a «three lines» summary, prioritized actions (15 at most, no filler) and alerts.
- An alerts panel with detail, recommended action and paginated evidence.
- Authenticated access with an encrypted session.
DATA
Data
- A data contract: what each table contains, with what verified meaning and with what caveats.
- Comparisons at the same logging delay, so a half-logged day is never compared with a complete one.
- Periods in Madrid time, tested against the 23- and 25-hour days.
- Independent reconciliation with hand-written SQL: hours, costs and findings match.
- Explicit coverage: labour cost always states how much of it has a rate.
AI / AUTOMATION
AI and automation
- «Ask about this briefing» assistant with a closed catalogue of tools.
- The model chooses the operation; the server validates the parameters and runs fixed, parameterized SQL.
- The model does not write SQL, and never sees credentials or tables outside the catalogue.
- Only the question, the text history and aggregated results reach the provider, which does not store the conversations.
- The assistant is evaluated against the real database and the real model.
06 — DECISIONS
Key decisions, and why
Read, do not migrate
The existing system works and the team uses it. The intelligence is built on top, with a read-only user that the database server itself enforces.
Deterministic rules before AI
Findings come from seven explicit, documented rules, each with its evidence. The AI answers questions; it does not decide what counts as an alert.
Exclude what cannot be stated
Budget, margin, profitability and forecasts are out by design, because the database does not contain the data to calculate them.
Compare fairly
Each day is compared with the previous day of the same type and at the same logging delay. Without that, the system would report drops that do not exist.
07 — RESULT
Result
- A daily and weekly briefing on the real data from the existing system.
- Findings reconciled independently with hand-written SQL.
- An operational assistant over the same data catalogue as the briefing.
No invented business figures: what is shown exists and is documented.
08 — STACK
Tech stack
- Nuxt 4
- Vue 3
- MySQL (read-only)
- ApexCharts
- Tailwind CSS
- OpenAI
09 — SIMILAR PROBLEMS
Similar problems I can solve
- →Your company has years of data in an ERP or in-house system that nobody uses.
- →Management needs a reliable daily reading without building reports by hand.
- →You want alerts about what needs attention, with the evidence behind them.
- →You want to ask your data questions without exposing it or putting the original system at risk.
This project is an example of data intelligence, ai & automation and custom software.