Design posture

The standard specifies the interface between groups and apps, keeps it as small as it can, and aims at the common case.

These principles decide what goes in the standard and what stays out.

An interface, not a governance model

The standard defines the interface between the group and the application. The permissioned data protocol avoids describing application semantics, and this standard likewise avoids describing both group governance and application semantics.

That isn’t because they matter less. They matter too much to fix in place. By not standardizing them, the standard leaves group stewards free to implement them however suits the group.

A group may run arbitrarily complex governance behind the interface, such as votes, holding periods for sensitive actions, or councils. None of that is visible to or required of apps. The group projects the outcome onto the standard’s records: someone gains a role, a rule changes, a member is ejected.

As minimal as possible, but no more

Standards like this are hard to change. Keeping it small gives the best chance for experimentation and growth, and for it to fit many different groups.

In practice this means a short, fixed list of actions, two well-known spaces, and no attempt to model what apps do inside their own spaces.

Aim at the common case

Every group is different, and some have unusual needs. Building all of them into the standard would make it more complex for every implementer. Instead the standard targets the 90% case: most groups should map onto it directly.

A group that needs something more complicated can still do whatever it wants in its own backend. It then projects that state onto the standard’s records, so apps keep working.