Prototype planning
Permissions Matrix
This planning page documents who should be allowed to do what in the future real-account version of the product.
Planning only. This does not create WordPress users, change WordPress roles, or change current prototype behavior.
Future roles
Roles Covered
In the prototype, Demo Identity simulates account behavior. In production, these rules should be enforced by logged-in account ownership and server-side permissions.
Profile Owner
Owns and maintains a profile, approves public answers, receives requests, and invites reviewers.
Interested Party
Browses Discovery, learns through profile guides, saves profiles, sends requests, and views request status.
Friend / Family Reviewer
Uses an invite to rate representation accuracy and provide confidential feedback.
Admin / Moderator
Handles support, safety, policy issues, prototype data tools, and future moderation workflows.
Permissions matrix
Actions and Restrictions
| Action | Allowed role | Notes / restrictions | Future implementation note |
|---|---|---|---|
| Create profile | Profile Owner, Admin / Moderator | A profile owner can create their own profile after account setup. Admins may create demo or support profiles. | Require a logged-in account and assign owner_user_id when the profile is created. |
| Edit own profile | Profile Owner | Owners should edit only profiles they own. | Check profile ownership on every save, not just in the browser UI. |
| Upload own images | Profile Owner | Images should be owner-approved and profile-specific. | Use WordPress media permissions plus owner checks and future image validation. |
| Approve public answers | Profile Owner | Only approved third-person public answers should enter the public profile brain. | Store approval status, approver user ID, and timestamp. |
| View own owner dashboard | Profile Owner | Dashboard access should be limited to the owner and admins. | Gate dashboard routes by account ownership and capability checks. |
| Ask questions on another profile | Interested Party, Profile Owner, Guest if allowed | Public approved-answer questions can be open during prototype testing. | Decide whether guests can ask or whether asking requires an account. |
| Ask questions on own profile for preview | Profile Owner | Owners can preview how their guide answers without sending requests to themselves. | Keep a preview mode that blocks self-connection requests. |
| Send connection request | Interested Party | Should be blocked for the profile owner viewing their own profile. | Require interested party account, duplicate-request checks, and safety controls. |
| Withdraw pending request | Interested Party | Only pending requests should be editable or withdrawable. | Check sender user ID and request status server-side. |
| View request status | Interested Party | Interested parties should see only their own sent requests. | Filter by sender user ID and hide owner-only notes or drafts. |
| Save profiles for later | Interested Party | Current prototype saves locally in the browser. | Move saved profiles to account storage tied to the interested party. |
| Submit accuracy review | Friend / Family Reviewer | Reviewers should use a valid invite and submit once. | Use invite tokens, optional reviewer accounts, duplicate protection, and privacy choice. |
| Invite reviewers | Profile Owner | Owners can invite people who know them, but reviews remain confidential by default. | Generate invite tokens and track acceptance without exposing private feedback by default. |
| View aggregate accuracy score | Profile Owner, Interested Party, Admin / Moderator | Public guide can show aggregate score/count only when enough reviews exist. | Never expose reviewer names or notes publicly. |
| View confidential reviewer feedback | Profile Owner, Admin / Moderator | Owner views anonymous/private feedback summaries. Named feedback shows only when reviewer opted in. | Separate invite tracking identity from confidential review details. |
| Handle support review removal requests | Admin / Moderator | Customers should not be able to remove low reviews just because they dislike them. | Use moderation workflows and keep flagged reviews counted unless removed by policy. |
| Manage Discovery visibility | Profile Owner, Admin / Moderator | Owners can request/choose visibility settings; admins may manage launch rules. | Combine owner settings, launch checklist, and admin safety controls. |
| Export/import prototype data | Admin / Moderator | Prototype data tools should stay admin-only. | Production export/import should be restricted, audited, and privacy reviewed. |
Launch reminder
Server-Side Enforcement Later
The current prototype is useful for testing product flows, but the real product should enforce these rules on the server. Browser controls, hidden fields, and Demo Identity values should never be trusted as production permissions.