The philosophy
The six commitments encoded in the name — observation, response, variable environments, cognition, documentation, provenance — and why each one is there.
A name that is an acronym usually means nothing beyond its expansion. This one was chosen after the fact to describe commitments the system had already made, and each term answers a question that had to be settled before anything could be built.
Why observation
Because the alternative is assumption. A system that acts on a schedule has assumed a world; a system that acts on observation has looked at one.
The commitment is stronger than "read sensors". An observation carries how reliable it is, alongside what it says. A measurement stripped of its uncertainty is a number pretending to be a fact, and every downstream safety property depends on knowing the difference. This is developed in observation before action.
Why response
Because "control" would have been the wrong word. Control implies the system determines the state of the environment. It does not. It responds to an environment that has its own causes, most of which the system cannot see and none of which it commands.
The distinction matters in failure. A system that believes it controls its environment interprets an unexpected state as an error to be corrected harder. A system that knows it is responding interprets the same state as evidence that its model is wrong — and the second interpretation is the one that does not escalate.
Why variable environments
Because stationarity is the assumption that quietly invalidates everything else. Most engineering methods assume the distribution generating your data is the distribution you will meet. Real environments — traffic, weather, human behaviour — are not stationary. They drift, they have regimes, and they occasionally do something with no precedent.
Building for a variable environment means the system must treat "conditions have left the range I understand" as an expected event with a defined response, rather than as an anomaly to be handled later.
Why cognition
Because the system must hold a representation of the environment rather than merely react to it. Reaction is stateless: an input arrives, an output is produced, nothing is retained. That is sufficient for a thermostat and insufficient here, because the right action frequently depends on what has been happening rather than on what is happening.
Cognition in this archive is a precise and modest claim. The system maintains a model of its environment, predicts forward from it, and evaluates its own predictions against what occurred. It is not a claim about understanding, and nothing in this archive should be read as one.
Why documentation
Because a decision whose reasoning was never recorded is re-litigated every six months by someone with less context, usually the person who made it.
The stronger version, and the one actually practised: writing the argument for a component before building it is the cheapest way to discover that it should not exist. Documentation is not a description produced after the engineering. It is where a meaningful fraction of the engineering happens. See documentation is part of engineering.
Why provenance
Because "where did this come from" is a question that gets asked exactly when it can no longer be answered.
Every value moving through the system has an origin, a confidence, and a path. A decision that cannot say which observations it rested on cannot be audited after an incident, and a model whose training provenance is unrecorded cannot be reasoned about when it starts behaving oddly. Provenance is expensive, unglamorous, and the thing that makes an incident investigable rather than merely regrettable.
The same principle governs this archive. Documents record whether they were AI-assisted and whether a human reviewed them, and publication is refused when the answer is unsatisfactory — because a claim about provenance that nothing enforces is a claim, not a property. How that is enforced in the software you are reading is described in provenance belongs in the schema.