What is VECTOR?
The preface. What the system is as an idea, before any question of how it is implemented — and what it is deliberately not.
Every engineered system embodies assumptions about the world in which it operates. Traditional traffic infrastructure assumes that yesterday's timing schedule is a reasonable approximation of today's conditions. VECTOR begins by rejecting that assumption, and then spends most of its structure dealing with the consequences of having rejected it.
VECTOR — Variable Environment Control Through Observation Response — is a system for operating infrastructure whose conditions change faster than a person can respond to them, without surrendering the accountability that a person operating it would provide.
The idea, stated once
A system that observes an environment and acts on it has been granted authority. That is true whether or not anyone decided to grant it. The moment a mechanism can change the state of the world in response to what it perceives, someone is responsible for what it does, and the question that matters is whether the system is built so that responsibility can actually be exercised.
Most of the difficulty in autonomous infrastructure is not perception and not decision-making. It is that these three requirements pull against each other:
- The system must act well, which pushes toward sophistication.
- The system must be able to account for what it did, which pushes against sophistication, because the most capable methods are frequently the least legible.
- A person must be able to overrule it, which requires the first two to hold — you cannot meaningfully overrule a decision you cannot understand.
VECTOR is an attempt to satisfy all three at once. Everything else in this archive is a consequence of that attempt.
What it is not
It is not a model. A model maps inputs to outputs under conditions resembling those it was trained on. VECTOR contains models. It is not one, and the distinction is the subject of why VECTOR exists.
It is not autonomous in the ordinary sense. Its authority has a boundary, that boundary is written by a person, and the system cannot revise it. A system able to rewrite its own constraints does not have constraints.
It is not a traffic product. Traffic is the first application and remains the one the system is tested against. It is not the subject. The subject is the general problem above, and traffic is where that problem is concrete enough to be worked on.
It is not finished. This archive documents a system under construction, including the parts that were wrong for months at a time. Where something is uncertain, the document says so.
How to read this archive
The five documents of Part I establish what VECTOR is and why: this preface, why VECTOR exists, the philosophy, the name, and the vision. The six that follow them state the principles every component is required to obey. Together they are the Canon, and every later document — architecture, protocol specification, research note, failure report — assumes they have been read and does not repeat them.
Read in order, the archive is an argument rather than a reference manual. It can be used as a reference; it was not written as one.