Appearance
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.
This is the mental model the product was designed around, and the fastest way to think about role assignment.
The Owner defines the project: which template it uses, which fields are active, who is on the team, and the project name. 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 do not reshape the project itself, and they do not 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 | ✓ | ✓ | ✓ |
use_chat | ✓ | ✓ | ✓ |
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.
use_chatis granted to all three roles. Anyone who can see a project's data can ask questions about it via the Ask feature.
TIP
Capability keys are lowercase-underscore on purpose. They are the same strings the backend uses, so if you are comparing against what the app actually allows you, it is 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 does not 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 Settings → Members. Viewer to Editor when someone starts doing review work. Editor to Owner when you want a co-lead. Either direction. There is no upper limit on how many Owners a project can have, but the project cannot drop to zero Owners: demoting or removing the last Owner returns a 409 error.
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.