Vision
Where this is going over five, ten and twenty years — as engineering direction rather than ambition, and with the uncertainty left in.
A vision document is usually a description of a desired outcome. This one is a description of a direction, which is a weaker and more useful thing: it states what the work is converging on without claiming to know where it arrives.
Everything here should be read as a current best estimate that later documents are permitted to contradict. When one does, the contradiction stays visible.
Five years — one domain, properly
The nearest goal is unglamorous: VECTOR operating real traffic infrastructure, in one place, continuously, with its failures documented rather than smoothed over.
That requires things the system does not yet have. Numbers produced under simulation and adversarial testing describe a laboratory; until a system has met an environment that did not read its assumptions, its measurements are provisional. It requires a defence against sensor inputs that are wrong on purpose rather than by accident, which is a category the current design acknowledges and does not fully address. And it requires the governance layer to be exercised by real incidents, because an escalation chain that has never escalated under genuine pressure is a hypothesis.
The measure of success at five years is not performance. It is whether the accountability structure held when something went wrong, and whether the record it produced was sufficient to explain the event to someone who was not there.
Ten years — the domain stops mattering
The architecture is arranged so that the domain is a component rather than an assumption. If that arrangement is correct, VECTOR should apply to any environment with the same shape: continuously changing, partially observable, consequential to get wrong, and currently run either by a fixed schedule or by a person who cannot watch it constantly.
Energy distribution, water systems, and industrial process control all have that shape. Whether the abstraction genuinely holds is an open question — this is exactly the kind of claim that is easy to make and expensive to test, and the honest position is that a single second domain would tell us more than a decade of reasoning about it.
The failure mode to watch for is a generality that exists only in the documentation. If moving to a second domain requires changing the governance layer, the layer was never general, and this archive should say so plainly when it happens.
Twenty years — the part that is not software
The long-term question is not technical. Systems that act on the physical world with partial autonomy are going to become ordinary, and the practices for holding them accountable are currently improvised per project.
What would be worth building over that horizon is a set of conventions rather than a product: what an autonomous system owes its operator, what a decision record has to contain to be worth keeping, what it means for a termination path to be genuinely reachable, and what evidence a system should have to produce before being trusted with a wider envelope.
VECTOR is one attempt at answering those questions in a specific case. The attempt is more likely to be useful than the artefact.
What this vision deliberately excludes
No claim about scale, adoption or organisational form appears here, because none of those are engineering direction and including them would date this document within a year.
No timeline appears beyond the three horizons above, and those are approximate. A dated roadmap belongs in the changelog, where being superseded is the expected outcome rather than an embarrassment.