One decision, followed all the way through.

Before anyone can act, the cooperative has to be able to say who counts as a member here — and be able to show why.

In ICN's vocabulary this step is about your recognized status (standing) .

A shop steward at Brightworks Collective is recognized in the workplace-safety area of the cooperative. That recognition is not a setting an administrator toggled. It exists because the members adopted a rule that says who holds this role, and because a decision under that rule assigned it.

The cooperative can check this for itself at any time. It does not have to ask a software vendor whether the person is really a member.

A piece of work appears that somebody has to decide on — with a deadline, and with a note about how consequential it is.

In ICN's vocabulary this step is about how group decisions are made (governance) .

The extraction fan in the finishing room is failing. Replacing it is not a small purchase and it affects everyone who works that room, so it is not something one person quietly handles.

It arrives as a specific item of work with a stated deadline, not as a message in a thread that somebody may or may not read.

Instead of a permission an administrator granted, there is a rule the members adopted — and the system can point at it.

In ICN's vocabulary this step is about what you are allowed to do (authority) .

The steward may act on this because the cooperative adopted a rule placing workplace-safety decisions with the safety stewards, and because a decision under that rule assigned them the role. Both of those are records, and both can be read back.

This is the part most software gets structurally wrong. Elsewhere, "who is allowed to do this" is an access-control setting held by whoever administers the tool. Here it is a consequence of decisions the members actually made.

The system shows what record would be created, whether it can be undone, and what proof it would leave — before anyone confirms.

In ICN's vocabulary this step is about what actually happens (execution) .

Reading this screen changes nothing. That is the point: an institution should be able to look at a consequential action in full detail without the act of looking being the act of doing.

The three things shown before any confirmation are always the same three: what authorizes this, whether it can be reversed, and what record it will leave behind.

Once the work is done, there is a durable record of what happened, who recorded it, and when — one that can be verified later without trusting whoever is telling you about it.

In ICN's vocabulary this step is about history and proof (provenance) .

The fan gets replaced and the completion is recorded. The record is not a line in an activity feed that an administrator can quietly edit; it is content-addressed, so any later change to it produces a different hash and stops matching.

A receipt says an act occurred. It does not make the act legitimate — the authority for that came from step 03, before anything happened.

Each record points back at the one that led to it, so a year later the cooperative can reconstruct not just what it did but why it was allowed to.

In ICN's vocabulary this step is about how resources and obligations are tracked (accounting) .

Every record in the chain carries the previous record’s hash. Follow them backwards and you arrive at the decision that authorized the work, and then at the rule that made the decision binding.

This is what an institution loses when its history lives across a chat archive, a spreadsheet, and a shared drive: not the individual facts, but the links between them. Reconstructing "why were we allowed to do this" becomes an archaeology project instead of a query.