TrueSight AI

TrueSight: analytics and automation for EV charging and billing operations.

Comment

Inspiration

EV charging support and billing work breaks down when evidence is scattered. A single charging session can leave traces across OCPP events, CDRs, meter values, charger state, roaming records, payments, and support tickets. When a driver says charging failed, a partner disputes a CDR, or a site creates repeated issues, teams need a defensible answer instead of another pile of logs.

TrueSight is built around a simple idea: every charging session should become explainable evidence.

I also have 7+ years as tech lead in the EV charging space and have seen how an EV backend is implemented, operated, deployed. What breaks and what works. At the moment I am trying to solve a real problem and improve the ecosystem for good.

What existed before H0

  • Working TrueSight ingest of OCPP Protocol
  • In-memory Registries for testing
  • Frontend (but it was improved and changed)
  • The AI Engine layer was just a concept to be build over the data

What we are building for H0

For H0, TrueSight AI becomes a database-backed product layer for EV charging and billing operations.

The hackathon build adds a

  1. Vercel-deployed frontend
  2. AWS database-backed architecture using Amazon Aurora PostgreSQL.
  3. With persistence comes also rework of the domain model, we also use clean code architecture
  4. The goal is to turn AI-assisted explanations into durable, queryable product objects.

Outcomes:

  1. Now the CDR field is stored in the database partially, unlokcing SQL on our evidence
  2. AI sessions are stored in DB and S3, this allows for fast retrieval listing.
  3. Domain feels much cleaner and storage now works really well for messages, ingested data, evidence references (S3), feedbackm confidence, reqests and incidents.
  4. AI has access to data and know some internal SQL strustures and S3 Data formats.

Why Aurora PostgreSQL matters

AI answers should not disappear after a chat window closes. In EV charging, teams need to know what evidence was used, what answer was given, whether it helped, whether it was escalated, and what should improve next. The AI sessions are our datapoint for improvement.

Aurora PostgreSQL fits because the product data is relational: sessions link to messages, messages link to evidence, evidence links to charging transactions, and feedback links back to quality monitoring and future billing/usage.

Also at work I have almost always used a PSQL database. I am very familiar and have good experience with it.

S3 remains the raw evidence store. Aurora becomes the queryable operational memory for TrueSight AI.

How we are building it

The frontend is a Vue 3 / Vite application deployed through Vercel.

The backend remains API-driven and is designed around charging evidence, raw artifact retention, and queryable product state. Implemented in Java 25 using Quarkus, deployed using ECS/Fargate.

We use Terraform for the whole IaC, including adding the database layer within the H0.

The H0 architecture is:

Vercel frontend -> Web3 Energy API/backend -> Aurora PostgreSQL for AI/evidence sessions -> S3 for raw evidence artifacts.

This keeps the demo realistic: Vercel is the public application layer, Aurora stores structured product state, and S3 keeps raw charging evidence.

Challenges

Main challenges include, but are not limited to:

  1. Time - getting the frontend, the backend, deploying and testing everything is time consuming, especially when still working full time.
  2. Designing realistic synth data to test with and using the data to improve our internal engine. Each data ingestion triggers a path (you can see it in the event graph). This whole architecture is the core, which will allow us to do efficient data analysis and inference.
  3. Integrating public AFIR endpoints. Getting MULTIPLE streams and integrating mTLS connection to each one, noticing that they are not complete. AFIR public data remain fragmented and hard to get until a single NAP is implemented.
  4. Becoming a father during the hackathlon :) changing a diaper was more a motivation than a challenge for me. I am so happy!!
  5. Getting sick the last days of the hackathon has not been easy. There were more things I needed to do, but could barely work. Slowly regaining my health and gathering enough strenght to submit our progress - I am very happy that H0 pushed me to improve the persistence layer! This is awesome!
  6. Getting AI Engine is still a work in progress, I feel we continue by build it around customers and their needs, using the evidence and the truth engine we build here.

Final note: TrueSight AI is designed around human approval, evidence-linked answers, audit logs, feedback, and clear separation between facts, inference, missing evidence, and recommended action.

What is next

Next for me and my start-up is building traction, we have planned a couple of things:

  • Submit the hackathon and get some constructive feedback, ideas and hopefully a placing.
  • We have prepared an outreach towards 300+ potential customers, inviting to be design partners and start looking towards an integration.
  • Join Founders For Founders Accelerator (July 6 - Aug 11) and improve and execute on positioning and go-to-market
  • Last but not least, my current view is that the project is real, I see a lot of potential and I am currently building a team around it - sales and outreach, already have a person handling operations and accounting. Looking for an advisor too. The app is real and the problem is also real - competitors already prove there is a market and my goal here was to bring the MVP and the app forward. To have serious DB persistence and I guess that is accomplished. Winning or not this has been a great journey for me.

And finally, if you find the idea interesting or have suggestions - do reach out! I am here :) building.

Built With

Share this project:

Updates