B1 · Coding: third-order scheme

Build a shared set of categories

B1 asks which kinds of organizing recur across communities. It turns many local descriptions into one coding scheme and keeps the differences between communities that the comparison needs.

Where this stage starts

A1 has read the communities and recorded their context. Each community has second-order themes, the groups of first-order codes its community coder made. B1 compares these themes across cases. The common categories it builds are the third-order themes, one level above the themes made within communities.

What the aggregator does

The aggregator writes its expectations and stopping rules before it builds categories, then works through the communities in a recorded order. A category names one kind of action or pattern. It has a name, examples, a rule for what belongs and a rule for what does not. Where two categories look alike, the scheme says how to choose between them.

A label as broad as "coordination" would leave a later reader guessing which acts it includes. Readers apply the scheme's distinctions to the participant evidence beneath a theme, and the words in the theme's title do not decide its placement.

The aggregator records when new kinds appear, rereads selected uncertain material, and checks whether further reading still changes the scheme. Rare patterns stay visible as their own categories. Categories with support across communities are marked apart from those with little support. Two communities that describe the same joint episode are linked as two accounts of one episode.

This stage organizes description; the model of how the parts fit together comes in C2. The category boundaries stay provisional until B2 tests whether other readers can use them.

What the next stage receives

B2 receives a written scheme, its membership rules, examples and known trouble spots. With these it can test whether another reader understands the distinctions the author intended.