I sat in my kitchen at 10pm on a Tuesday watching one AI admit it had lost an argument to a different AI. Over a spreadsheet. Claude had given me 38,876 records. ChatGPT said 38,946. I told Claude. It rechecked, found its own error, and conceded.
That is the kind of month May was.
This article was written with Claude’s help — not because I could not write it myself, but because I was too busy running the experiment to stop and document it. If I had waited until I had time to sit down and write this properly it would never have been published. Claude helped me get it out of my head and onto a page, and then I corrected the bits it got wrong. As you will read, that is a pattern that runs through the whole of May.
A bit of background
I spent seventeen years as a police officer, twelve of them investigating fatal road collisions. For the last ten years I have run Harper Shaw Investigation Consultants Ltd, a vehicle systems forensics consultancy working with police forces, insurers and solicitors on serious crime and serious collision cases. My job is to extract data from vehicles and tell courts what it means. When I write a report, someone’s liberty or a family’s understanding of how their person died can depend on whether I have got it right.
I say that not to be dramatic but to make a point: I am not someone who adopts new tools carelessly. I have spent a long time being professionally sceptical. If something does not stand up to scrutiny, it has no place in my work.
So when I tell you I spent an entire month in my spare time building forensic learning tools with an AI, and that I think it is one of the more important things I have done for this business, that comes with full awareness of what I just said above.
How it started
It started with a practical problem, which is how most things start in this work.
Tesla vehicles are increasingly involved in serious collision investigations. Police, insurers and solicitors all need to know where the investigative data is and how to get to it. So I started writing a guide — a straightforward reference for investigators covering the data types available on a Tesla and where to look for them. A community favour as much as anything else.
While writing it I got curious about something. The dashcam video files Tesla produces are not just video. Embedded inside what looks like a standard MP4 file is Supplemental Enhancement Information — SEI data — written directly into the video stream. GPS and telemetry data sitting inside the video container itself, with more forensic detail than we typically see in conventional EDR data. The fact that it was sitting inside an MP4 container was genuinely interesting to me, and I wanted to understand it properly.
So I spent about ninety minutes working through the file format with Claude. That turned into a proper exploration of the MP4 container structure — how the SEI layer sits within it, what the individual data fields mean, how they are encoded. I was not planning to build anything. I was curious, and I wanted to understand what I was looking at.
Somewhere in those conversations it became obvious that the same questions I was asking would make a good learning tool. And Claude kept producing things that looked less like notes and more like interface components.
I had never built a web tool in my life. But the gap between “this would make a good tool” and “this is a tool” turned out to be smaller than I expected.
The Tesla Dashcam SEI Decoder went from a conversation to a deployed tool faster than anything I have produced in twenty years of investigation. Four tabs, an interactive SEI explorer, a 55-term glossary, a hex map. Single file, deployed to the internet, free to use.
By the end of the first week it was live.
What we built in thirty days
This is the actual order it happened, because the sequence matters — nothing here was planned, it just kept growing.
The first published output. A practical walkthrough of the SEI data structure inside Tesla dashcam video files, written for investigators who needed to understand what they were looking at.
We moved from the dashcam files into the airbag control module EDR data. Started pulling apart the hex, decoding channels, making progress. This is also where the overconfidence moment happened — more on that shortly.
Started building tools to present the decoded EDR data in a usable format. Parked for now. Still to launch. Still work to do on completing the decode.
Jumped back and built a proper interactive learning tool explaining the MP4 file structure and walking through the decode of a single frame. This became the foundation for everything that followed. Four tabs, interactive explorer, hex map.
The learning tool needed to explain how values are translated. That grew a glossary and a set of explainers covering binary, hex, bitmasks, IEEE 754 floating point, how encoded values become meaningful numbers.
Those explainers were good enough to stand alone as a general resource for anyone entering vehicle systems forensics. Still building. Not yet published.
CAN bus is the communication network that connects every electronic control unit in a modern vehicle. We built an interactive visualiser to aid learning — animating arbitration, frame structure and decode. Still in development but close.
Started as a simple utility tool and kept growing. That growth became the DAT — the Harper Shaw Data Analysis Tool — which pulled together calculation, conversion, and analysis functions in one place.
Built as a standalone tool, pushed to Netlify as a single HTML file and issued quickly to contacts on our training programme. The feedback came back fast and it was strong.
With positive feedback in hand and a tool that was working, we opened it to the course cohort.
By this point things were moving quickly enough that they needed a home. We registered the domain, built the index, and organised the tools — some free and open, some linked to course students, some still in development and not yet released.
A free tool for visualising crash and EDR data from any vehicle, added to TVN Labs and open to anyone working in this space.
Covering multi-camera analysis, working through how multiple dashcam angles can be used together in an investigation.
Built to verify Tesla’s own GitHub CSV export against our decoded output. A tool that takes the SEI data and decodes it in a way that can be checked against Tesla’s published format.
We packaged TVN Labs tooling into a prototype desktop application for Mac, downloadable and licensable. We are not software developers. Or we were not. That line is becoming harder to draw.
All of it. Spare time. One month. And the more we worked through it the more ideas came — which is either a feature or a problem depending on how much sleep you need.
The honest bit
None of this was smooth.
The most instructive moment of the month came during the Tesla EDR work. We were decoding a real crash file — Block 5817, a confirmed Tesla EDR record. I asked Claude whether it had the steering wheel angle data. It replied yes, cited specific pages of the source PDF, and immediately launched into decoding it. Confident. Detailed. Formatted beautifully.
I had asked that question because something felt off. And the fact that I had to ask it at all was the problem. Claude had been building with incomplete information and had not flagged it. In a forensic context that is not a minor issue — a confident-looking output built on incomplete inputs is more dangerous than an obvious error, because it passes the first glance test.
I posted a screenshot of that exchange on LinkedIn. Nobody picked it up. Which tells you something about how much the industry is currently thinking about this.
The response to catching it was not to patch the decode and move on. It was to build something that demonstrated the correct methodology — a brute-force regression search tool that tests every possible offset and encoding combination across the entire hex block, matches the results against known verified values from Tesla’s own reporting system, and finds the correct encoding mathematically. Sixteen thousand four hundred combinations. Under a second to run. The answer verified against primary source material, not assumed.
That tool is not yet published. When it is, it will have its own post because the story of how it was built is worth telling in full.
The CSV counting incident was a different kind of lesson. I had 18 data files I needed to interrogate. Claude told me there were 38,876 records across all of them. I then put the same question to ChatGPT. ChatGPT said 38,946.
The AI tools were not being lazy — they were each doing something that looked exactly like counting but was not quite counting. Understanding why that happens is now part of how I think about where these tools can and cannot be trusted.
This is the same discipline I apply to vehicle data. Confidence in an output is not the same thing as accuracy of an output. You verify. Always. The difference between a forensic investigator using AI and someone just using AI is that the forensic investigator knows what the answer should look like before they ask the question.
What this means for your organisation
Here is the question worth sitting with: we built tools in days — sometimes hours — that were getting feedback from the community asking why we could deliver what they actually needed when large, expensive software solutions had not managed it.
That is not a small thing.
We have already had people tell us we should be selling this. And they are right — some of what has come out of this month is commercial software, built in a fraction of the time and cost that the established market would suggest is possible. The development model has changed. A small forensic consultancy with the right domain knowledge, the right questions, and the ability to recognise when an answer is wrong can now build tools that compete with products that took large teams and significant budgets to produce.
That has implications in every direction.
For smaller firms — independent collision investigators, boutique forensic consultancies, single-practitioner expert witnesses — the barrier to building your own tailored tools has dropped significantly. You do not need a development team. You need deep knowledge of the problem you are solving, enough technical literacy to interrogate the output, and the discipline to verify everything before it goes anywhere near a case.
For larger organisations the picture is more nuanced. The same capability that lets a small firm build fast also means that internal development becomes a realistic option in a way it perhaps was not before. Whether that leads organisations toward building rather than buying is a decision that depends on far more than the technology — but the technology is no longer the limiting factor it once was.
For the established software market the question is straightforward: if the value was always in the domain knowledge and not the development cost, what happens when the development cost collapses?
We are not saying every organisation should build their own tools. We are saying the landscape has shifted, and the organisations that understand that shift earliest will be best placed to decide what it means for them.
Vehicle systems are getting more complex every year. The data they produce is getting richer, more layered, and more consequential in legal proceedings. The gap between what is in that data and what investigators, insurers and legal professionals can interpret is widening.
That gap is where cases get lost. It is also where expert evidence gets challenged. And it is increasingly where the next generation of forensic tools will be built — not necessarily by the largest companies, but by the people who understand the data best.
AI is here. That is not a debate.
The only constant in life is change. I am on the wrong side of fifty and I know from experience that standing still is not a neutral position — it is how you fall behind.
AI is not coming. It is already here and it is already being used by the people you work alongside, the organisations you compete with, and the courts you present evidence in. The question is not whether to engage with it. The question is whether you engage with it well or badly.
For me that meant approaching it the same way I have approached every new tool in my working life. You learn it. You work with it. You understand what it can and cannot do.
This is not a new interest dressed up as a trend. The difference now is what the tools can actually do. And you never let it replace the judgement you have spent years building — because the moment you do that, you are not using a tool anymore. You are outsourcing your expertise to something that does not carry the consequences when it gets it wrong. You do.
A dashcam did not replace an investigator. CCTV did not replace an investigator. EDR data did not replace an investigator. AI will not replace an investigator. But an investigator who understands AI will have a significant advantage over one who does not.
That is not why May happened in isolation — I have been working with AI for years. But this period felt different. Things are moving quickly, the capability has shifted, and May was the point where I recognised that fast enough to do something about it.
A warning.
There were days in May where getting back to the AI overtook other things it should not have overtaken. It is genuinely addictive in a way I had not anticipated. The feedback loop is immediate — you ask something, something gets built, it works, you want to ask the next thing. Repeat. The problem is that loop does not have a natural stopping point and it does not care what else you had planned for the evening.
If Claude is the dealer, Anthropic is the organised crime group. And at some point in the month I was buying extra credits at 10pm to keep a session going that probably should have stopped two hours earlier.
I am not embarrassed about that. But I am noting it because anyone who goes into this kind of experiment should know it is coming. The smartphone gave us access to everything and we watched an entire generation disappear into it. This is faster, more personalised, and considerably more capable of making you feel like you are being productive while your actual priorities quietly move further down the list.
The experiment is done. We have more than enough to work with. The next phase is slower — take stock, refine what exists, finish what is parked, and make sure everything that goes further forward is properly validated before it does.
Build fast, then stop and check. Which is, as it turns out, exactly the same principle that applies to the AI outputs themselves.
One last thing
Someone will ask whether it is appropriate for a forensic expert witness to be publishing AI-assisted tools and writing AI-assisted articles.
My answer: yes, provided you are the one doing the checking. The tools we have built make no claims we have not verified against primary source material. The article you just read reflects things that actually happened. The mistakes I described were real. The verification discipline is the same one I apply in casework.
We did not stop being forensic investigators when we picked up a new tool. We became forensic investigators who understand the tool well enough to know when it is wrong.
That, ultimately, is the only way to do this properly.