How Bluetext makes reviewing a system easy
What you review is what the system is made from. Normally the thing you inspect is a description of the system, kept separately from it — an architecture diagram, a record of processing, a control matrix — and nothing forces the two to agree. Here the description is the source: the system is generated from it, so it cannot be silent about something that was built, and it cannot drift from what is running. That is what auditability amounts to in practice: not that records exist, but that the answer can be got from the system itself.
Each kind of decision has one home. A review of a topic reads one kind of place: all authorization is in gates, all exposure is in interfaces and routes, every credential is a bundle, every piece of the system's own data is a state variable. There is no second place a decision of that kind could be hiding, so a review that finishes is a review that is complete.
Each instance of a kind is declared the same way. Reviewing the tenth component costs what reviewing the first did, because it has the same shape — and a checker can read all of them at once, which is not possible when the same fact is expressed in five languages across five tools.
The sets are enumerable. "List every way into this system", "list every credential", "list every store we own" are answers rather than investigations. Review becomes enumeration, and enumeration is the only kind of review that can honestly claim to have covered everything.
And some questions the code answers about itself. "Which service did this write go to?" is normally a runtime question, answered by tracing calls, adding instrumentation, or reading logs after the fact. Here every operation carries its component and its link by where it sits in the code, so it is a question about text: the answer is read rather than reconstructed, and data-flow evidence stops being an investigation.
And a few arrangements do not build at all. That moves part of the review to the platform's boundary: instead of judging whether something that looks right actually is, you check whether it came from the platform — a question with a mechanical answer, where one control covers every such case at once.
Where each kind of decision lives, and that is all of it
| To review | Read |
|---|---|
| Who may do what | The gates — one per operation, and nothing outside the model reaches past one |
| What is reachable from outside | The published interfaces, and the routes a gateway forwards |
| What credential each connection presents | The credential bundles, one per way of consuming a surface |
| Which data the system owns | The state variables — the fields that hold it |
| What the system is made of | The component declarations; the directory listing is the registry |
| What each part offers, and on what terms | Its interfaces and their profiles |
| What talks to what | The links, for what code calls, and the routes, for what a gateway forwards |
| How a part differs between environments | Its variants, and which one each environment binds |
| Where each part runs | The targets and the deploy configs |
| Business decisions | The model — controllers carry none of them and drivers carry none of them |
| What is running right now | The deploy records, which name every artifact the deploy owns |
What cannot be built, and the review question that disappears with it
| Refused | Question you no longer have to ask |
|---|---|
| A component fronted by the gateway that is also published directly | Is there a second way in that skips the exchange? |
| Two surfaces fronted at the same path | Does one origin's route shadow another's? |
| An operation with no declared error type | Can a caller meet a failure it was never told about? |
| A variant of a kind its component does not admit | Is this environment's binding legal for this part? |
| A variant carrying another kind's keys — a built artifact naming an image, an external one naming either | Is this declaration internally consistent? |
| Two clients bound to the same link inside one part | Can two code paths reach one peer under different assumptions? |
| An unknown key in a driver's configuration | Is this setting read by anything at all? |
| A gateway configuration the gateway itself rejects | Will the router come up with what we rendered? |
| A deploy from a dirty working tree | Is what is deployed what is in the repository? |
What still needs a human
| Judgment | Why the platform cannot make it |
|---|---|
| Whether a gate decides correctly | It has one home and nothing bypasses it, but the logic inside it is ordinary code |
| Whether the privilege design is right | Separate credentials are cheap; what each one may do is still a decision |
| Which stored data is personal, and how long it may be kept | The declaration records structure, not classification |
| Whether the business logic is correct | One home makes it findable; nothing makes it right |
| Whether a bought-in product is configured well | Its configuration is carried and rendered, not judged |
| Whether anything arrived from outside the platform | The deploy records what it owns and deliberately ignores a stranger's (§9) |
What this looks like in practice
A credential shared by five things. Two components need the same database. Giving the second its own account means creating a role, granting privileges, generating and storing a password and wiring it into that component's configuration — per store, per environment. So the existing account gets reused. Then a batch job, then an analytics reader. Now one credential carrying the union of everyone's privileges is held by five things, compromising the least-protected yields the access of the most-trusted, and rotating it would need five coordinated deploys, so it never happens. Here a second consumer is a profile and a bundle.
A second door nobody notices. An API sits behind a gateway that handles authentication, and then something needs to reach it directly, so somebody publishes the service. Both paths work, the direct one skips the gateway's whole plugin chain, both objects applied cleanly, both hosts answer, and the request looks identical downstream. It is never noticed, because it is not a failure — it is extra capability, and it survives for years. Here an interface is either routed or published, and the build refuses both.
A caller that assumed somebody else checked. Authorization accretes in layers: a session check in middleware, a role check in the controller, an ownership check in the service. Then a second entry point arrives — an internal RPC, a background job, a new resolver — and calls the service method directly. The service assumed the controller had checked. It had, for the one caller that existed when it was written. Here the work sits in a command that nothing outside the model can call, so the decision cannot be skipped.