Methods

Most of what makes a piece of research usable is decided before anyone writes code or opens a dataset. It is decided when the question is framed, when someone chooses what will count as evidence, and when someone decides who has to be able to read the result. These pages describe those decisions, because they are the part of the work that is easiest to skip and hardest to repair later.

Software, data, policy, and accessibility are treated here as one practice rather than four. A dashboard that no one can maintain is a data problem that became a software problem. An analysis that cannot say who it affects is a statistics problem that became a policy problem. A chart that only works in color is a design problem that became an exclusion problem. In each case the failure was introduced early and only became visible at the end.

Method affects project quality in a specific and unglamorous way: it determines what happens when something is uncertain. A project with explicit methods reports the uncertainty and narrows the claim. A project without them tends to drop the uncertainty, because nothing in the process required anyone to record it. The difference rarely shows up in the first deliverable and almost always shows up in the second.

These are working standards, not credentials. rhizae is an emerging practice, and several of the approaches described here have been applied to demonstration projects and independent research rather than to delivered client engagements. Where that is the case, the page says so. Each method below is written to be expanded as it gets used on real work, and to be corrected where the work shows it was wrong.