How to read these docs

These docs explain what WilsonOS is and how it works. They are written for two readers at once: someone deciding whether the system fits their business, and a developer or agent who needs to understand the shape of the system before building on it. Three conventions keep that honest.

1. Status labels

Every claim about what is built carries one of three labels. If a page describes a mechanism without a label, read it as the agreed design, not as a certification that the capability is live.

Label	Meaning
live	Deployed and verified. The required behaviour is running and has been checked against the criteria that define it.
direction	Agreed design. The team has decided this is how it works or will work; implementation may be partial.
proposed	Under discussion or not yet scheduled. Nothing on this page commissions it.

2. The source boundary

These pages are the explanatory layer. Underneath them sit the system’s architecture contracts — one document per station of the work loop and one per foundation, plus a generated data-model appendix. The contracts define runtime behaviour: what writes where, who may act, what a record is called. When a page here and a contract disagree, the contract wins and the page is wrong.

Each page lists, in its footer, the contracts and source documents it was written from, and the date it was last verified against them. If you are building on WilsonOS, follow those references before relying on a page’s description.

Layer	Purpose	Where
These docs	What the system is, how it fits together, why it is shaped this way	this site
Architecture contracts	Runtime rules per station and plane	the repository’s architecture documents
Decision records	Why a shape was chosen over the alternatives	the repository’s decision ledger
Task ledger	What is being built, by whom, and whether it shipped	the repository’s task documents

3. Names used in examples

Examples use a small set of real names so that they read as a real system rather than a hypothetical one:

Mia — the cross-brand agent: accountability coach for the owner and steward of the system itself.
Scout — the brand agent for Code Pineapple, a children’s book imprint.
Prime — the brand agent for RiseBlox, a technology and education brand.

Other brands and agents exist in the running system; the docs refer to them generically (“another brand agent”) rather than by name. Nothing in these pages describes the owner’s personal details, business figures, infrastructure addresses, or credentials, and a check runs on every build to keep it that way.

4. Vocabulary

The docs use a shared vocabulary for business records — product, offer, customer account, campaign, funnel event, goal, task, run, artifact, version, calendar entry. Those terms are defined once in Shared business records and gathered with the system’s other terms in the glossary. When a page uses one of those words, it means exactly that.