Start with the rule
Krill’s most important design choice is not the swarm visualization. It is the sentence underneath the system: consent before compute.
That reverses a familiar order. A lot of technical systems begin with capability — what can we collect, infer, automate or scale? — and bolt explanations on later. Krill is being built around an opposite constraint: a person should be able to see what they are being asked to do, why the work exists and where the result goes before they contribute.
Visible machinery changes the product
The current Krill interface deliberately separates the participant surface from the coordinator at swarm.fabri.cc. It describes missions, accepts explicit judgments and points back toward the backend instead of pretending the backend does not exist.
That separation is not automatically sufficient for public trust, of course. But it makes a useful product requirement possible: if an important part of the system cannot be explained or inspected, the interface should not paper over it.
Public value before extraction
Another Krill covenant line is “public value before extraction.” That is a high bar, and it should stay one. It means the purpose of a mission cannot simply be “because data might be valuable later.” The mission has to name the value people are producing together.
This is also why the project belongs in a public lab. Governance questions get weaker when they are hidden until after launch. Publishing the question early creates a record that future implementation can be judged against.
Power arrives last
The last useful constraint is power arriving last. More compute, more aggregation and more autonomy are not automatically progress. They should arrive only when consent, verification and purpose remain legible at the smaller scale.
That may turn out to be slower. It may also turn out to be a better way to build public systems. Krill exists to find out.