Why these eight
A list of architectural principles is usually a list of things its author admires, and such a list can be agreed to without anything being decided. Two constraints were applied here instead, and between them they produce eight entries instead of fifteen.
The first is that each principle has to name a property a system either has or does not have, settled by evidence somebody outside the system can ask for. That rules out everything a design aspires to. Resilience, scalability, good data hygiene and clean interfaces are all desirable and none of them can be failed on a demonstration, which makes them qualities of engineering rather than requirements of this category.
The second is that each principle has to attach to something structural: a stage of the loop the system runs, or the authority the system was granted. Six of the eight sit on a stage, which is why the same six keep reappearing as the place a system breaks. The remaining two are properties of the authority itself, and authority is not a stage. It is what the loop runs inside. A system can execute all six stages faultlessly while holding no enumerated grant at all, which is the ordinary condition of automation built before anybody expected it to decide anything.
Two stages of the loop carry no principle of their own, which is deliberate rather than an omission. Interpretation is governed by the account it interprets, so its quality is already decided by the first principle. Adaptation is governed by what survives of past decisions, so it is already decided by the fifth. A principle that restated either one would add a line to the list and nothing to the test.
What the eight cost
A requirement that costs nothing is not a requirement, and a list of principles published without its bill is a list nobody has tried to meet. Three of the eight carry most of the price, and it is stated below at its real weight.
Unified context is the expensive one
This is where implementations die, and they die in a recognisable way. The work is not building a query layer. It is settling what a record means when four functions have kept their own version of it for fifteen years, each correct inside its own process, and none of them reconcilable without somebody deciding which one is now authoritative. That decision is organisational, it is contested, and no amount of engineering settles it on behalf of the people who have to live with the answer.
The consequence is a long stretch of a programme during which nothing autonomous is running and nothing visible has shipped. The other seven can each be demonstrated in a narrow slice before the context is complete, which is exactly why so many programmes demonstrate them and stop. A pilot that works on one clean dataset has proved that the loop closes. It has not proved that the account underneath it can be made reliable across the business, and the second is most of the cost.
A grant is a conversation with somebody who can refuse. Every action type the system is to take has to be named, given a ceiling, given conditions, and signed by a person prepared to answer for the total, and that person is usually not in the delivery team. The slow part is not writing the enforcement. The enforcement is a day of work. The slow part is that autonomy now advances at the speed of a controller, a risk committee and an auditor, and those are not resources a schedule can add to.
This cost is permanent, not one-off. Grants are narrowed after incidents, revisited when the business changes, and renewed when the people who signed them leave. A system designed to hold authority carries a standing governance obligation from the day it ships, and a plan that treats the grant register as a launch task has mispriced the whole programme.
Reconstructing a decision years later means keeping more than the decision. It means the evidence as it stood, the policy version in force, the alternatives the system weighed and discarded, and the observed outcome, all retained for as long as anybody may reasonably ask, which for a financial decision is measured in years and set by somebody other than the architect. Storage is the small half of that bill.
The large half is discipline. Policies have to be versioned instead of edited, evidence has to be captured at decision time and not reassembled from whatever remains, and retention has to survive migrations, vendor changes and the ordinary pressure to reclaim space. None of this work is visible while the system is behaving. All of it is the only thing anybody wants on the day the system is questioned, and it cannot be added retrospectively, because the moment it was meant to capture has passed.
The other five are ordinary engineering by comparison, which is why systems meeting five of eight are common and systems meeting eight are rare. That distribution is the whole reason for stating the principles as requirements. A partial implementation is a reasonable thing to build and a reasonable thing to buy. It is only a problem when the three expensive ones are the ones missing and the description does not say so, and the maturity model exists to read that gap per resource class, not in general.