Roles & Capabilities

Every member of a project has exactly one role, and that role determines what they can do. There are three of them: Owner, Editor, Viewer.

• Owner — full control over the project: template fields, members, settings, and everything the Editor can do.
• Editor — does the actual analytical work: upload, analyze, validate, export.
• Viewer — read-only. Sees the matrix and the files, changes nothing.

Owners Make the Rules. Editors Work Within Them.

That's the mental model the product was designed around, and it's the fastest way to think about role assignment.

The Owner defines the project — which template it uses, which fields are active, who's on the team, what the project is even called. They set the guardrails.

The Editor does the analytical work inside those guardrails. They upload contracts, kick off analysis, override extracted values, and ship exports. They don't get to reshape the project itself, and they don't invite other people in.

The Viewer reads results without changing anything. Useful for stakeholders who need to see the matrix but shouldn't be editing it.

The Capability Matrix

These are the exact capability keys the backend checks against. Each key controls one distinct action in the product.

Capability	Owner	Editor	Viewer
manage_templates	✓	—	—
manage_members	✓	—	—
manage_project	✓	—	—
configure_fields	✓	✓	—
upload_contracts	✓	✓	—
run_analysis	✓	✓	—
validate_terms	✓	✓	—
export_results	✓	✓	—
delete_contracts	✓	—	—
view_results	✓	✓	✓
view_files	✓	✓	✓

A few things to notice:

• The Owner-only capabilities all shape the project itself — templates, members, project settings, contract deletion. Structural changes.
• Editors get the full analytical loop — upload through export, plus toggling which template fields are active on the project (configure_fields).
• Viewers get read access to results and source files and nothing else.

TIP

Capability keys are lowercase-underscore on purpose — they're the same strings the backend uses, so if you're comparing against what the app actually allows you, it's a one-to-one map.

Common Scenarios

A few concrete examples of who typically gets which role:

• Partner running the deal → Owner. They set up the project, pick the template, control who's on it.
• Senior associate doing the extraction work → Editor. They upload the stack, run analysis, validate and override terms, ship the export.
• Client-side reviewer checking the output → Viewer. They need to see the matrix and the source files; they don't need to change anything.
• Second Owner → you can have more than one Owner on a project. Useful when two partners are co-leading a deal and either should be able to invite people or change settings without waiting on the other.

TIP

Err toward Editor, not Owner. If someone doesn't need to change the shape of the project or manage the team, Editor is the right call — they can still do all the analytical work.

Changing a Member's Role

An Owner can promote or demote any member at any time from the project's Members tab. Viewer to Editor when someone starts doing review work. Editor to Owner when you want a co-lead. Either direction. No limit on how many Owners a project can have.

Role changes take effect immediately — the member's next request uses the new capability set. No re-invite needed.

---

→ For more detail, see Inviting Members. → For more detail, see Project Settings.