Build the means to move forward.

The architecture answers one question: if communities need software they can understand, govern, and leave, what must the architecture make possible?

The commitments

• The architectural thesis: the community's operating record must be hard to lose and hard to privately capture.

• Beliefs to architecture: each principle translated into architectural pressure.

• The durable community layer: the part of the system that must survive product churn.

• System shape: shared foundations, a coherent operating environment, a substrate that stays a substrate, governed reactions, replaceable interfaces, disciplined federation.

The structure

• The layered model: six layers, four concerns that cross all of them, and why every boundary is a contract.

• The composition model: small parts, declared assemblies, and the same pattern repeated at every scale.

• Contract governance: how a convention becomes a rule, a check, and a promise with a deprecation path.

• A self-describing system: every part accounts for itself, so legibility survives growth.

• Delegation and agency: the structure required before software may act on a community's behalf.

What the architecture makes possible is described at /capabilities, what it looks like in ordinary use at /use-cases, and the products that implement this shape live at /products.