docs: consolidated RBAC docs (accuracy fixes, transition guide, dynamic-auth OAuth)

[jordanc-relevanceai]

This PR consolidates the open RBAC documentation work. Opened as draft for review before the source PRs are closed.

Source PRs (being closed in favor of this one)

• docs(rbac): consolidated RBAC fixes and transition guide #606 — consolidated RBAC fixes + transition guide (already a draft merge of docs(TSP-1150): fix critical RBAC permission inaccuracies #583 + docs(TSP-1152): add RBAC transition guide and legacy permissions note #586)
  • TSP-1150: fix critical RBAC permission inaccuracies
  • TSP-1152: RBAC transition guide and legacy permissions note
• docs(TSP-1169): document member OAuth account access for dynamic auth #593 — TSP-1169: member OAuth account access for dynamic auth

Why consolidated

All three edit enterprise/rbac.mdx. Shipping them separately would mean each merge conflicts with the next and the permissions tables / role descriptions drift. #606 already reconciled the two RBAC-accuracy PRs; folding #593 in here keeps the permissions table and role notes coherent in a single pass.

Changes by source PR

#606 — TSP-1150 + TSP-1152

• admin/project-management/add-members.mdx — adds the Chat role accordion, simplifies the Viewer description (removes the incorrect "can run agents" claim), reframes the Info banner to link both the RBAC docs and the transition guide.
• enterprise/rbac.mdx — Editor/Viewer/asset-visibility clarifying callouts, plus three new sections: Transitioning to RBAC, Permission inheritance and cascading, and Technical implementation notes.

#593 — TSP-1169

• enterprise/rbac.mdx — adds an "Add personal OAuth accounts (dynamic auth)" row to the project-level permissions table (all roles ✅) and a note distinguishing project-level OAuth management (admin-only) from personal OAuth for dynamic auth (all members).
• enterprise/user-level-authentication.mdx — Info callout, updated first-time auth steps, privacy paragraph, and a new FAQ entry documenting that non-admin members can add their own OAuth accounts when dynamic auth is enabled.

Reconciliation note

No conflicts between the two — #593's permissions-table row and note land inside the existing Project-level section, while #606's additions are separate sections. Verified no duplicate headings or table rows in the merged rbac.mdx.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
relevanceai	🟢 Ready	View Preview	Jun 3, 2026, 9:43 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[github-actions]

🎯 Vibe check

Reviewed: 3 files (3 with issues, 0 clean)

Scores

	Dimension	Score	What's holding it back
🟡	Consistency	6/10	4 heading case violations in rbac.mdx; banned word "powerful" used twice; 5 card title case violations in user-level-authentication.mdx; inconsistent product name casing in one heading.
🟡	Technical clarity	8/10	One meaningful contradiction on legacy Viewer capabilities between add-members.mdx and rbac.mdx; a misplaced Warning callout in add-members.mdx that actively misleads readers.
🟡	Non-technical clarity	8/10	Strong overall. The word "seamless" in user-level-authentication.mdx:116 skirts a banned-word concern. The RBAC transition guide is genuinely helpful for a non-technical admin.
🟡	Structure	7/10	Bold labels inside callouts in two files (violates CLAUDE.md); a Warning about region choice appears in the middle of the "Add members to your organization" section with no relation to the surrounding content.

Score key: 🟢 9–10, 🟡 6–8, 🔴 1–5. Scores are a single overall judgment across the whole PR.

✨ Overall vibe: The content itself is solid — comprehensive RBAC reference, a clear transition guide, and a well-structured user auth how-to. What drags the scores down is mechanical: casing errors across all three files, two banned-word uses, and a genuine factual contradiction about whether legacy Viewers could run agents that needs resolving before these pages can be trusted as a source of truth.

🔧 Issues (13)

• enterprise/rbac.mdx:22 — ## Best Practices → sentence case: ## Best practices
• enterprise/rbac.mdx:26 — ### Organization Level → ### Organization level ("Level" is not a proper noun)
• enterprise/rbac.mdx:43 — ### Project Level → ### Project level
• enterprise/rbac.mdx:155 — Accordion title "More powerful than Viewer" — powerful is a banned word. Describe the actual difference instead: e.g. "Can trigger Chat and run agents (with asset permissions)"
• enterprise/rbac.mdx:158 — Accordion title "Less powerful than Member" — same issue. Try "Cannot create assets or access the web app"
• enterprise/rbac.mdx:202 — ## Workforce Permissions → ## Workforce permissions
• enterprise/user-level-authentication.mdx:37 — Card title "Enhanced Security" → "Enhanced security"
• enterprise/user-level-authentication.mdx:39 — Card title "Privacy Protection" → "Privacy protection"
• enterprise/user-level-authentication.mdx:41 — Card title "Access Control" → "Access control"
• enterprise/user-level-authentication.mdx:45 — Card title "Simplified Management" → "Simplified management"
• enterprise/user-level-authentication.mdx:47 — Card title "Audit Trail" → "Audit trail"
• enterprise/user-level-authentication.mdx:90 — ## Setting up user level authentication has "user level authentication" in lowercase, but every other heading on this page treats it as a proper product name ("User Level Authentication"). Pick one and apply it consistently.
• admin/project-management/add-members.mdx:73 — ## Add members to your Organization capitalizes "Organization" but the parallel heading at line 11 (## Add members to your project) keeps "project" lowercase. Either both are product concepts (capitalize both) or neither is (lowercase both).

🧩 Component suggestions (2)

• enterprise/rbac.mdx:221–223 — <Info> callout opens with **Note:** in bold. CLAUDE.md prohibits bold labels inside callouts. Either drop the label entirely (the <Info> icon already signals it's a note) or switch the component to <Note> and remove the bold prefix.

• enterprise/user-level-authentication.mdx:86–88 — <Warning> starts with **Embedded chat is NOT currently supported.** in bold — same bold-label-in-callout issue. Remove the bold formatting; the Warning styling carries the emphasis on its own.

🏗️ Page structure (2)

• admin/project-management/add-members.mdx:75 — There's a <Warning> about organization region choice ("Your region choice is permanent and cannot be changed after your organization is created…") sitting in the middle of the "Add members to your Organization" section. It has nothing to do with adding members. This looks like a stale copy-paste. Remove it from this page (or move it to wherever region selection is documented — /admin/project-management/ids already covers organization regions per the link it contains).

• enterprise/rbac.mdx:122–124 and 196–198 — The <Info> callout about Viewer read-only access to full asset configurations is nearly identical in both the "Project level controls" section (line 122) and the "Asset level controls" section (line 196), differing only in "Project Viewer" vs "Asset Viewer." This is duplicated content. Consolidate into one callout at whichever level it's most relevant, and link to it from the other location.

⚠️ Contradictions (1)

• admin/project-management/add-members.mdx:52 says the legacy Viewer role "Cannot run agents." But enterprise/rbac.mdx:247 (the legacy role card) says the legacy Viewer "Could run agents," and rbac.mdx:266 reinforces this: "Legacy Viewers could run agents — RBAC Viewers cannot." The two pages directly contradict each other on a behavior that affects how admins handle the Viewer → Chat/Member reassignment during migration. Decide which is correct and align both pages.

🔋 Credit usage

Item	Count
Files reviewed	3
Context pages read	3
Total lines processed	~1,123

Files read: admin/project-management/add-members.mdx (109 lines), enterprise/rbac.mdx (365 lines), enterprise/user-level-authentication.mdx (219 lines), admin/project-management/remove-members.mdx (58 lines), enterprise/rbac-groups.mdx (328 lines), enterprise/asset-controls.mdx (44 lines)

[github-actions]

🎯 Vibe check

Reviewed: 3 files (3 with issues, 0 clean)

Scores

	Dimension	Score	What's holding it back
🔴	Consistency	5/10	6 heading case errors in rbac.mdx (Best Practices, Organization Level, Project Level, Asset Level, Chat Role Details, Workforce Permissions); 5 card title case errors in user-level-authentication.mdx; 2 banned-word instances in rbac.mdx accordion titles; inconsistent capitalization of "User Level Authentication" within user-level-authentication.mdx (capped in 4 headings, lowercase in a fifth).
🟡	Technical clarity	7/10	Ambiguous anchor link in user-level-authentication.mdx (#permissions matches the first of three same-named headings in rbac.mdx); "Setting integration defaults" steps end mid-action; misplaced region warning in add-members.mdx confuses the add-members flow.
🟡	Non-technical clarity	7/10	rbac.mdx opens with Best Practices that reference roles the reader hasn't met yet; user-level-authentication.mdx setup instructions use informal verbs ("Head into your Agent", "Head to the Tool"); one instance of marketing-adjacent language ("seamless and intuitive").
🟡	Structure	7/10	rbac.mdx Best Practices section precedes the role definitions that give it meaning — prescriptions land before the reader has context. "Setting integration defaults" in user-level-authentication.mdx cuts off without completing the flow.

Score key: 🟢 9–10, 🟡 6–8, 🔴 1–5. Scores are a single overall judgment about the whole PR — not per file.

✨ Overall vibe: The content itself is solid — the RBAC page is the most comprehensive treatment this topic has had, the ULA page explains a tricky feature clearly, and the add-members page adds useful detail about the invitation flow. The main damage is cosmetic (heading and card title casing is inconsistent throughout rbac.mdx and user-level-authentication.mdx) but two genuine factual contradictions between add-members.mdx and rbac.mdx on legacy role definitions need resolving before merge.

🔧 Issues (19)

Heading and title case

• enterprise/rbac.mdx:22 — ## Best Practices → ## Best practices
• enterprise/rbac.mdx:26 — ### Organization Level → ### Organization level
• enterprise/rbac.mdx:35 — ### Project Level → ### Project level
• enterprise/rbac.mdx:43 — ### Asset Level → ### Asset level
• enterprise/rbac.mdx:130 — ### Chat Role Details → ### Chat role details
• enterprise/rbac.mdx:202 — ## Workforce Permissions → ## Workforce permissions ("Workforce" is a product name; "Permissions" is not)
• enterprise/user-level-authentication.mdx:37 — <Card title="Enhanced Security"> → "Enhanced security"
• enterprise/user-level-authentication.mdx:40 — <Card title="Privacy Protection"> → "Privacy protection"
• enterprise/user-level-authentication.mdx:43 — <Card title="Access Control"> → "Access control"
• enterprise/user-level-authentication.mdx:46 — <Card title="Simplified Management"> → "Simplified management"
• enterprise/user-level-authentication.mdx:49 — <Card title="Audit Trail"> → "Audit trail"
• enterprise/user-level-authentication.mdx:13,32,53,69 — Headings capitalize "User Level Authentication" ("Level" and "Authentication" are not proper nouns), but line 90 uses all-lowercase ## Setting up user level authentication. Pick one form and apply consistently across all five headings; all-lowercase (## How user level authentication works) is the sentence-case-correct choice.
• admin/project-management/add-members.mdx:73 — ## Add members to your Organization — "Organization" is not listed as a Relevance AI product name in CLAUDE.md → ## Add members to your organization

Banned words

• enterprise/rbac.mdx:155 — Accordion title "More powerful than Viewer" — "powerful" is banned. The body already states the actual behavior; retitle to something like "Can trigger Chat and run agents (with asset permissions)"
• enterprise/rbac.mdx:159 — Accordion title "Less powerful than Member" — same banned word. Retitle to "Cannot create assets or access the web app"

Callout / markup

• enterprise/rbac.mdx:221 — <Info> opens with **Note:** — CLAUDE.md bans bold labels inside callouts. Drop the **Note:** prefix; the <Info> component already signals it's a note.

Tone / style

• admin/project-management/add-members.mdx:20 — "Send invite!" — exclamation mark is informal; replace with "Send invite." or rephrase as "4. Send the invite."
• enterprise/user-level-authentication.mdx:116 — "the authentication flow is seamless and intuitive" — "seamless" is the adjective form of the banned "seamlessly" and reads as marketing copy. Describe the actual behavior: e.g., "users see a connect-account prompt once and the agent continues automatically."

Misplaced content

• admin/project-management/add-members.mdx:75 — The Warning about organization region choice ("Your region choice is permanent…") sits inside ## Add members to your organization but has nothing to do with adding members. It appears to have been copied from an organization-creation page. Remove it from here or move it to the org creation / setup documentation.

🧩 Component suggestions (3)

• enterprise/rbac.mdx:221 — <Info>**Note:**…</Info> — the **Note:** bold label is redundant and violates CLAUDE.md. Strip it; the sentence reads fine without it: <Info>If a user has run access to a workforce but lacks permissions on one or more agents, they will see a "Cannot run agent" warning…</Info>

• enterprise/user-level-authentication.mdx:107 — <Note> links to /enterprise/rbac#permissions. There are three headings named ### Permissions in rbac.mdx (org level, project level, asset level), so this anchor resolves to the first one (org-level), which is the wrong table. Link to a more specific anchor, e.g. /enterprise/rbac#project-level-controls, or point directly to the relevant sub-heading if Mintlify generates a unique slug for it.

• enterprise/user-level-authentication.mdx:159–168 — "Setting integration defaults" has two steps that stop mid-action: step 1 clicks "Integrations & API Keys", step 2 clicks the integration — and then the section ends without saying what to do next (how does the user actually set or change the default account?). Add the remaining steps, or if the UI makes it self-explanatory after clicking in, say so explicitly before the <Tip>.

🏗️ Page structure (1)

• enterprise/rbac.mdx:22–49 — The "Best Practices" section appears immediately after the intro paragraph, before any role definitions or permission tables. It references specific roles (Owner, Admin, Member, Viewer, Chat) that the reader hasn't encountered yet, which makes the advice hard to act on. For a concept page, move Best Practices to after the org/project/asset level control sections — once readers know what the roles are, the prescriptions land.

⚠️ Contradictions (2)

• admin/project-management/add-members.mdx:22–24 lists 4 legacy roles: Admin, Editor, Chat, and Viewer. enterprise/rbac.mdx:237 says "The legacy permission system had three roles — Admin, Editor, and Viewer." The "Before RBAC" CardGroup at rbac.mdx:239–249 also shows only 3 cards. Decide whether Chat is a legacy role or an RBAC-only role and align both pages.

• admin/project-management/add-members.mdx:52 says the legacy Viewer role "Cannot run agents." enterprise/rbac.mdx:248 says legacy Viewers "Could run agents." The rbac.mdx Warning at line 265–267 also calls out this as a Viewer behavior that changes under RBAC ("Legacy Viewers could run agents — RBAC Viewers cannot"). One of these files is wrong about what legacy Viewers can do — resolve before the RBAC transition guidance misleads admins about who to reassign.

🔋 Credit usage

Item	Count
Files reviewed	3
Context pages read	2
Total lines processed	~1081

Files read: admin/project-management/add-members.mdx (109 lines), enterprise/rbac.mdx (365 lines), enterprise/user-level-authentication.mdx (220 lines), admin/project-management/remove-members.mdx (59 lines), enterprise/rbac-groups.mdx (328 lines)

[NiamhRelevance]

Why two checks are red

1. Documentation Lint Checks — Supademo embeds

Reverted the Supademo embed normalization (390b126).

The structure-check lint rule requires the standard 16:9 wrapper (paddingTop: '56.25%', purple border, rounded corners). But applying that standard snippet to these User Level Authentication demos doesn't fit — the embed crops the content and key parts of the walkthrough get cut off. This is what happens when the standard rules/test are applied:

These embeds are pre-existing (not added in this PR) and render correctly with their original wrapper, so I've left them as-is rather than forcing the standard snippet. The lint rule may need to allow a taller aspect ratio for demos like these.

2. afdocs check — unrelated

This failure is on get-started/pricing (markdown/HTML content parity), which is not touched by this PR. It was failing before this branch and is not caused by these changes.

[github-actions]

🎯 Vibe check

Reviewed: 3 files (3 with issues, 0 clean)

Scores

	Dimension	Score	What's holding it back
🔴	Consistency	5/10	6 heading sentence-case violations in rbac.mdx, 5 Card title violations in user-level-authentication.mdx, and a widespread pattern of lowercase "agents", "tools", "knowledge" throughout both files when referring to Relevance AI product features.
🟡	Technical clarity	7/10	One anchor link likely resolves to the wrong section; one misplaced <Warning> block that has no relation to its surrounding content; two factual contradictions between add-members.mdx and rbac.mdx about the legacy permission system.
🟢	Non-technical clarity	8/10	Definitions come before instructions, analogies are present, jargon is introduced in context. The Best Practices section in rbac.mdx appears before readers know what the roles are, which is a minor ordering friction.
🟡	Structure	7/10	Best practices precede role definitions in rbac.mdx (logic is inverted for a reference page); no closing CTA on user-level-authentication.mdx; misplaced region warning in add-members.mdx.

Score key: 🟢 9–10, 🟡 6–8, 🔴 1–5. Scores are a single overall judgment about the whole PR.

✨ Overall vibe: The content is genuinely solid — the RBAC tables are comprehensive, the transition guide is well-structured, and user-level authentication is explained with good depth. The PR is held back by two direct factual contradictions between add-members.mdx and rbac.mdx (one around Chat being a legacy role and one around what legacy Viewers could do) that need to be resolved before this ships, plus a high volume of sentence-case violations that are mechanical to fix.

🔧 Issues (15)

Heading sentence case — enterprise/rbac.mdx

• enterprise/rbac.mdx:22 — ## Best Practices → ## Best practices
• enterprise/rbac.mdx:26 — ### Organization Level → ### Organization level
• enterprise/rbac.mdx:33 — ### Project Level → ### Project level
• enterprise/rbac.mdx:43 — ### Asset Level → ### Asset level
• enterprise/rbac.mdx:130 — ### Chat Role Details → ### Chat role details
• enterprise/rbac.mdx:202 — ## Workforce Permissions → ## Workforce permissions

Card title sentence case — enterprise/user-level-authentication.mdx

• enterprise/user-level-authentication.mdx:37 — title="Enhanced Security" → "Enhanced security"
• enterprise/user-level-authentication.mdx:39 — title="Privacy Protection" → "Privacy protection"
• enterprise/user-level-authentication.mdx:41 — title="Access Control" → "Access control"
• enterprise/user-level-authentication.mdx:43 — title="Simplified Management" → "Simplified management"
• enterprise/user-level-authentication.mdx:45 — title="Audit Trail" → "Audit trail"

Bold label inside callout — enterprise/rbac.mdx

• enterprise/rbac.mdx:221–224 — <Info> wraps **Note:** If a user has run access to a workforce.... CLAUDE.md prohibits bold labels inside callouts. Change <Info> to <Note> and drop the **Note:** prefix entirely.

Misplaced content — admin/project-management/add-members.mdx

• admin/project-management/add-members.mdx:75 — The <Warning> about permanent region choice sits inside the "Add members to your Organization" section, which is about inviting users — not about creating an org or choosing a region. This appears to be a stray copy-paste from an org-creation page. The warning has no logical connection to the surrounding content and should be removed or moved to the correct page.

Potentially wrong anchor — enterprise/user-level-authentication.mdx

• enterprise/user-level-authentication.mdx:107 — [asset-level authentication controls](/enterprise/rbac#permissions) — rbac.mdx has three ### Permissions headings (org-level, project-level, asset-level). The first one, #permissions, resolves to the org-level permissions table. The link text says "asset-level" but the anchor would hit org-level. Consider linking to /enterprise/rbac#asset-level-controls instead, or verify in a preview that this anchor resolves where intended.

Product term capitalization (pattern across files)

• enterprise/rbac.mdx:92,94,140,142,148 and admin/project-management/add-members.mdx:33,35,37,46,52 — "agents", "tools", "knowledge" are used in lowercase throughout both files when referring to the Relevance AI product features. Per CLAUDE.md, Agent, Tool, and Knowledge are proper nouns and must be capitalized. Examples: "Manage users, agents, tools, knowledge…" (rbac.mdx:92) → "Manage users, Agents, Tools, Knowledge…"; "View agents, tools, and knowledge outputs only. Cannot run agents" (add-members.mdx:52) → "View Agents, Tools, and Knowledge outputs only. Cannot run Agents". This is a widespread pattern — fix systematically rather than one-by-one.

🧩 Component suggestions (2)

• admin/project-management/add-members.mdx:31–47 — The Editor <Accordion> contains three bolded section headers (**Has read permissions for:**, **Has write permissions for:**, **Other permissions:**) each followed by bullet lists. CLAUDE.md says accordion content should use flowing sentences, not bullet lists. Consider rewriting as prose: "Editors can read and write all datasets, knowledge sets, and agents, and can view users. They cannot manage users. They can run Agents and Tools."

• enterprise/rbac.mdx:221–224 — As noted in Issues: <Info> with a **Note:** label. Replace with a plain <Note> block and drop the label. The callout type already communicates "note."

🏗️ Page structure (2)

• enterprise/rbac.mdx — The ## Best practices section (line 22) appears before any role or permission tables, so readers encounter prescriptive guidance ("assign Owners to 1–2 people") before understanding what Owner means. For a reference page this is backwards. Move Best Practices after the three control-level sections (org → project → asset), or at minimum after the opening summary paragraph explains what each role tier is.

• enterprise/user-level-authentication.mdx — No closing CTA. This is a concept+how-to page for an Enterprise feature. Round it off with a ## What's next? linking to at least two related enterprise pages — natural candidates are /enterprise/rbac (for understanding which project roles apply to users authenticating individually) and /enterprise/rbac-groups (for bulk managing those users).

⚠️ Contradictions (2)

• admin/project-management/add-members.mdx:7–9 says the page describes the standard (legacy, pre-RBAC) permission system. add-members.mdx:24 then lists Chat as one of the four standard roles. But enterprise/rbac.mdx:237 explicitly states the legacy system had exactly three roles — Admin, Editor, and Viewer — and rbac.mdx:132–133 marks Chat as a new Enterprise-only feature being gradually rolled out. The same Chat role cannot be both a standard pre-RBAC role and a new Enterprise-only RBAC feature. One of these pages is wrong; align them.

• admin/project-management/add-members.mdx:52 says legacy Viewers "Cannot run agents, create assets, or edit anything." enterprise/rbac.mdx:266 says "Legacy Viewers could run agents — RBAC Viewers cannot." These two files directly contradict each other on the key behavioral difference the transition guide is warning about. If the Viewer role description in add-members.mdx was silently updated to reflect RBAC behavior, the info banner on that page (line 7–9) needs to be updated too, or the Viewer description needs to be corrected back to the legacy behavior.

🔋 Credit usage

Item	Count
Files reviewed	3
Context pages read	2
Total lines processed	~1,080

Files read: admin/project-management/add-members.mdx (109 lines), enterprise/rbac.mdx (365 lines), enterprise/user-level-authentication.mdx (219 lines), admin/project-management/remove-members.mdx (59 lines), enterprise/rbac-groups.mdx (328 lines)

[github-actions]

🎯 Vibe check

Reviewed: 3 files (3 with issues, 0 clean)

Scores

	Dimension	Score	What's holding it back
🔴	Consistency	5/10	Five wrong-case headings in rbac.mdx (## Best Practices, ### Organization Level, ### Project Level, ### Asset Level, ## Workforce Permissions); five card titles in user-level-authentication.mdx with title case; two banned-word hits (powerful) in rbac.mdx accordion titles; two bold labels inside callouts; feature name oscillates between "User Level Authentication" and "dynamic authentication" across files.
🟡	Technical clarity	7/10	Misplaced <Warning> about regions in add-members.mdx (copy-paste error, wrong section). add-members.mdx contradicts rbac.mdx on whether legacy Viewers can run agents. The anchor /enterprise/rbac#permissions in user-level-authentication.mdx resolves to the first ### Permissions heading it finds (project level), which may not be the intended target.
🟡	Non-technical clarity	7/10	Generally approachable. "Seamless and intuitive" on line 116 of user-level-authentication.mdx is the only real marketing slip. Both enterprise pages define terms before using them. The ## Technical implementation notes section in rbac.mdx is correctly gated as developer content.
🟡	Structure	7/10	The misplaced Warning in add-members.mdx is the main structural problem. The Editor accordion in add-members.mdx uses bold section headers and bullet lists instead of flowing prose (CLAUDE.md: "Accordion content: use flowing sentences, not bullet lists"). Otherwise page architecture is logical.

Score key: 🟢 9–10, 🟡 6–8, 🔴 1–5.

✨ Overall vibe: The RBAC and ULA pages are substantively good — comprehensive, well-organized, with tables and steps where they belong. The main drag is a cluster of mechanical consistency failures (heading case, card titles, banned words) that are quick to fix, plus one genuine content bug (a misplaced Warning that talks about region lock-in in the middle of the "Add members to your organization" section). The Viewer-role contradiction between the legacy permissions page and the RBAC migration guide also needs a decision: one of them is wrong about whether legacy Viewers can run agents.

🔧 Issues (18)

Heading capitalization — enterprise/rbac.mdx

• rbac.mdx:22 — ## Best Practices → ## Best practices
• rbac.mdx:26 — ### Organization Level → ### Organization level
• rbac.mdx:33 — ### Project Level → ### Project level
• rbac.mdx:45 — ### Asset Level → ### Asset level
• rbac.mdx:204 — ## Workforce Permissions → ## Workforce permissions

Card title capitalization — enterprise/user-level-authentication.mdx

• user-level-authentication.mdx:36 — title="Enhanced Security" → "Enhanced security"
• user-level-authentication.mdx:39 — title="Privacy Protection" → "Privacy protection"
• user-level-authentication.mdx:42 — title="Access Control" → "Access control"
• user-level-authentication.mdx:45 — title="Simplified Management" → "Simplified management"
• user-level-authentication.mdx:48 — title="Audit Trail" → "Audit trail"

Banned words — enterprise/rbac.mdx

• rbac.mdx:157 — Accordion title "More powerful than Viewer" — powerful is a banned word. Rephrase: "Outranks Viewer" or "Can run agents; Viewer cannot"
• rbac.mdx:161 — Accordion title "Less powerful than Member" — same issue. Rephrase: "Below Member" or "Cannot create assets or access the web app"

Bold labels inside callouts

• rbac.mdx:223 — **Note:** bold label inside <Info>. CLAUDE.md prohibits bold labels inside callouts — the label adds no information, the callout type already signals it. Drop **Note:** and start directly with the sentence.
• user-level-authentication.mdx:86 — **Embedded chat is NOT currently supported.** bold label inside <Warning>. Same issue. Drop the bold label; the Warning callout makes the severity clear. Alternatively, put the bold statement as the opening sentence and leave the detail as the second sentence (still one paragraph, no bold label).

Misplaced content — admin/project-management/add-members.mdx

• add-members.mdx:75 — The <Warning> about region choice being permanent ("Your region choice is permanent and cannot be changed after your organization is created…") is inside the ## Add members to your Organization section. This warning has nothing to do with adding members — it appears to have been copy-pasted from the IDs or organization setup page. Remove it from this file entirely, or move it to the correct page.

Inconsistent capitalization of feature name — enterprise/user-level-authentication.mdx

• user-level-authentication.mdx:90 — ## Setting up user level authentication uses lowercase, but every other heading on the same page treats this as a proper noun: ## How User Level Authentication works, ## Why use User Level Authentication, etc. Either capitalize consistently throughout (## Setting up User Level Authentication) or make a deliberate choice and apply it everywhere.

Terminology mismatch across files

• rbac.mdx:113,129 / user-level-authentication.mdx throughout — rbac.mdx calls the feature "dynamic authentication" (in the permissions table row label and the inline Note), while the actual feature page is titled "User Level Authentication." Even within user-level-authentication.mdx, line 124 says "using an agent with dynamic authentication enabled" and line 172 says "dynamic authentication is enabled on an agent." Pick one canonical term and use it throughout both files. The page title "User Level Authentication" is the authoritative name.

🧩 Component suggestions (2)

• add-members.mdx:30–47 — The Editor Accordion contains three bold section headers (**Has read permissions for:**, **Has write permissions for:**, **Other permissions:**) each followed by a bullet list. CLAUDE.md says accordion content should use "flowing sentences, not bullet lists." Rewrite as prose: "Editors can read and write all datasets, knowledge sets, and agents, and can view the user list. They can also run agents and tools but cannot manage users."

• add-members.mdx:73 — The "Organization" in ## Add members to your Organization is capitalized inconsistently with rbac.mdx, which uses lowercase "organization" throughout. If this is being treated as a product-feature proper noun, every mention needs to be consistent. If it's not a proper noun, lowercase it everywhere in the file (lines 73, 79, 81 all have the same issue).

⚠️ Contradictions (1)

• add-members.mdx:52 describes the legacy Viewer role as: "Cannot run agents, create assets, or edit anything."
• rbac.mdx:249 describes the legacy Viewer role (in the "Before RBAC" section) as: "Read access to all datasets, knowledge sets, and agents. Could run agents."
• rbac.mdx:268 reinforces this: "Legacy Viewers could run agents — RBAC Viewers cannot run anything."

These two files directly contradict each other on whether legacy Viewers can run agents. One of them is factually wrong. Decide which is correct and update the other accordingly. If legacy Viewers genuinely could run agents, add-members.mdx:52 needs to be updated to reflect that. If they couldn't, then rbac.mdx:249 and :268 need to be corrected.

🔋 Credit usage

Item	Count
Files reviewed	3
Context pages read	2
Total lines processed	~1081

Files read: admin/project-management/add-members.mdx (109 lines), enterprise/rbac.mdx (367 lines), enterprise/user-level-authentication.mdx (220 lines), admin/project-management/remove-members.mdx (58 lines), enterprise/rbac-groups.mdx (327 lines)