Three layers of access

One role per person, set for the whole organization: Org Admin or Org Member. This governs org-wide configuration — managing Users, Units, KPIs, Org Settings, and the shared lists (Categories, Statuses) other features draw from. A separate role per Initiative, Project, Target, Committee, Template, etc. — typically Owner, Editor, or Viewer. This governs what you can do inside that specific thing, independent of your organization-level role. Public or Confidential, set per Initiative, Project, Wiki, etc. This governs who can see it, independent of who can manage it. See Visibility.
The three layers are independent. An Org Member can still be an Owner of a Project; an Org Admin isn't automatically an Owner or Editor of every Initiative — see For Admins for where org-wide admin access does and doesn't substitute for a context role.

Organization-level roles

RoleDescription
Org AdminFull access to organization-wide configuration — Managing Users, Managing Units, Managing Calendars, Managing KPIs, and Managing Org Settings — plus admin-gated capabilities inside features, like managing Initiative Categories and Statuses and managing available Project Statuses.
Org MemberThe default role. No org-wide configuration access — what a Member can see or do inside any given Initiative, Project, Target, etc. comes entirely from their context-level role there.

[TODO] A third role, “Power Member,” came up in dictation and was then walked back to just these two — unconfirmed whether it's a real (possibly upcoming) role or a slip. Needs checking before it's ruled out for good.

Context-level roles

Most contexts — Initiatives, Templates, and others — use the same three-tier pattern. Meetings use a different pair suited to scheduling.

Owner, Editor, Viewer

Full control, including membership and deletion. Every context requires at least one — see e.g. Managing Initiative Members. Can edit content but can't manage membership or delete the context. Read-only. Matters most on a Confidential context, where you want someone to see it without being able to change it — see e.g. Template permissions.

This pattern is confirmed on Initiatives and Meeting Templates. Targets and Projects currently document Owner and Editor only — whether a Viewer tier exists there too isn't confirmed yet.

Organizer and Participant (Meetings)

Meetings use their own pair instead of the Owner/Editor/Viewer pattern: Organizers are a meeting's editors, and Participants are invited attendees without edit rights. See Creating a Meeting.

Approver (Target Houses)

A Target House also has an Approver: the person, or group of people, who can approve it for the Fiscal Year. Approvers default to the Unit's approvers, set in Managing Units, but can be changed on the Target House. Approving is a separate responsibility from managing: Owners and Editors request approval, and Approvers review the request and approve it or send it back with comments. See Requesting Target House Approval.

Responsible person — not a permission role

Fields like Responsible person (on Tasks, Milestones, To-dos) or Owner on a Target's off-track report just record who's driving a specific piece of work. They're assignment fields, not access grants — being the Responsible person on a Task doesn't by itself make you an Editor of the Project it lives in.

Visibility: Public and Confidential

Roles control who can manage something. A separate setting controls who can see it. Most contexts — Initiatives, Projects, Wikis, Templates, and more — are either Public or Confidential, and this works independently of the Owner/Editor/Viewer roles above.

Transparent. Everyone in the organization can see it. Only its members can manage it, according to their context-level role. Restricted. Only the people listed as members can see it. Everyone else in the organization doesn't see it at all.
Visibility answers who can see this. The context-level role (Owner, Editor, Viewer) answers what you can do with it. Making something Public doesn't give anyone edit rights, and a Viewer on a Confidential context can see it without being able to change it.

Where it applies

Visibility is set on the context itself — for example when creating a Project, or from the member management dialog of an Initiative. It also applies to items inside a context: Decisions and To-dos can be Confidential even on a Public context, in which case only members of the context can see them. Meetings are the exception: they're confidential by default, with no Public option.