A method, stated plainly

This page describes how Karvan intends to build software for its own operations. It does not describe a product, because there is not one, and it does not claim an advantage that no customer has asked for.

Section 01 — The method

Five commitments

Each one is a constraint on what gets built, which is the only kind of technology statement worth publishing before anything ships.

Local first

Operational records stay under the company's own control by default. Sending a driver file, a permit scan or a customer address to a third party should be a decision someone made, not a side effect of choosing a tool.

Human approved

Anything that changes state waits for a person. Automation is allowed to read, correlate, draft and warn without asking. It is not allowed to act without being asked.

Evidence linked

Every consequential assertion points at the document or record it came from. An answer with no source is treated as a question, not an answer.

Deterministic where determinism exists

Most of the work that matters here is a date comparison, a lookup or a reconciliation. Those are solved problems, and using a language model for them adds cost, latency and a failure mode in exchange for nothing.

Model replaceable

Where a model genuinely helps, it sits behind an interface the rest of the system does not know the shape of. Swapping it should be a configuration change, not a migration.

Section 02 — The reasoning

In regulated work, the expensive failure is the missing record

Not the missing insight, and not the missing dashboard.

A permit lapses because a date passed. A vehicle comes off the road because an inspection was not booked. A driver file is incomplete when someone asks to see it. None of these is an analysis problem. Each is a record that should have existed and did not.

The same shape appears in an entirely unrelated regulated market that Karvan has looked at separately: the costly gap is documentation, not data. Two unconnected domains producing the same conclusion is the most interesting thing found so far, and it is the reason this direction is framed around records rather than intelligence.

So the first system is small on purpose: a register of things that expire, a scheduled check, and a notification. No new database, no service, no model. The test it has to pass is that one document expiring in seven days produces exactly one alert — and then that a deliberately broken job is visibly broken, because a monitor that fails silently is worse than no monitor.

Section 03 — The limit

The honest limit of this position

No transport buyer has been shown to want private or local technology. It is a technology preference held by this company, not a demonstrated customer requirement, and this site will not imply otherwise.

Recorded limit · carried forward from internal review

Stating that costs nothing and prevents a specific failure: building a differentiator nobody asked for and then having to defend it. If a buyer ever does ask for it, that will be recorded as evidence when it happens, with a date.

A second limit belongs next to it. An internal system being good does not make it a product. Anything sold to anyone else would need buyer validation first, and that has not been done.

Section 04 — Boundaries

What is not offered

No software product, licence, subscription or hosted service.
No consulting engagement, and no availability being advertised here.
No model benchmark numbers, no capability claims, no comparisons.
No description of the infrastructure this runs on. Naming the hardware would tell a reader nothing useful and an attacker something useful.
No chatbot on this site, and no artificial-intelligence feature added to a public page to look current.

This page is a position, not a pitch. It exists so that the word "technology" on the home page means something specific.