Status correction — 3 October 2026: UNAPPROVED PRELIMINARY MATERIAL. Retained as research input only. Chris has limited the current task to collecting future-planning scope, sources, confirmed decisions and unresolved matters. Actual implementation planning is a separate phase he will initiate. Architecture, sequencing and proposed controls here are not approved or an implementation approval request. Separately recorded owner decisions still apply.
Permission matrix proposal — 3 October 2026¶
For owner approval; documentation only. Capability labels marked NEW below are proposed labels, not existing API identifiers, enum values or grants. No permissions were changed. The owner ledger controls confirmed policy; this document supplies the exact matrix requested by Chris. Approval of this proposal is separate from authorization to implement or grant anything.
Minimum usable delivery and evidence¶
First implementation slice: show existing project groups and project/stage permissions in Membership → Groups → Permissions; enforce existing Review/Reconcile/Design and the approved separate actions at both command and read boundaries. Acceptance: possessing a grant cannot assign it, assignment cannot grant Review/Reconcile, blinded candidate data stays isolated, owner transfer stays owner-only. Add workflow-specific actions as their vertical slices ship; do not expose inert permissions as functioning capabilities.
Read-only check of this PR worktree on 3 October:
- ResourceSecurity.json supplies project Design, EditMemberships, AssignPermissions, ChangeOwner, ExportData, ViewStudies and stage Review/Reconcile/Design/ ViewAnnotationProgressGraph. ChangeOwner, AssignPermissions and Delete inspected defaults are owner-only; ordinary admin defaults must not silently broaden them.
- ProjectController membership group replacement uses EditMemberships; project and stage permission updates use project AssignPermissions. This proves endpoint boundaries for those actions, not a new delegated stage-permission administrator.
- ProjectPermission uses active membership/group/owner authorization (with separate application authorization); StagePermission supports project groups and active stage member grants. Existing enum identifiers must retain ordinals when extended.
- A statistics-progress grant is not verified to authorize the proposed agreement-statistics view. ViewStudies is not proof of unrestricted candidate/gold reads.
Sources: catalogue, controller, stage permissions and enums. These are inspected source facts, not proof of deployed behavior for new workflows.
Proposed grant/default contract¶
P = project; S = one stage. A project group can receive separately configured S grants. “Admin Yes” means recommended ordinary-administrator default for enabled features, not an existing or approved default. Owners retain existing ownership exceptions. All groups are configurable; reviewer/reconciler labels here describe actions, not immutable roles. Read access always intersects dataset access, study population/context, version policy and stage blinding. A grant never bypasses independent-review or allocation eligibility.
| Action | Proposed capability and scope | Mapping / separation recommendation | Admin default proposal |
|---|---|---|---|
| View project, studies, ordinary metadata | Existing View / ViewStudies, P | Reuse; no candidate/gold read expansion | Yes |
| View memberships | Existing ViewMemberships, P | Reuse; independent from permission editing | Yes |
| Invite, enable/disable, assign/remove group members | Existing Invite / EditMemberships, P | Reuse verified membership boundary; status endpoints currently use EditMemberships | Yes |
| Create/rename/archive configurable groups | EditMemberships, P | Proposed extension only after verifying group CRUD; no implicit grant assignment | Yes |
| Delegate project grants | Administer scoped permissions (extend AssignPermissions), P | PM2 confirmed: owner grants permission administration to a project group; propose bounded delegation envelope | Owner-granted group only |
| Delegate stage grants | Administer scoped permissions (extend AssignPermissions), P, bounded stage allow-list | Extend current project-gated AssignPermissions to owner-granted group; stage scope constrained by envelope, never stage Design alone | Owner-granted group only |
| Grant/revoke permission-administration authority and its envelope | Owner administration, P | Recommend owner-reserved; no recursive delegation | Owner only |
| Transfer ownership / delete project | Existing ChangeOwner / Delete, P | Preserve inspected owner-only exceptions; no blanket admin default | Owner only |
| Design ordinary questions/forms and screening profile questions | Existing Design, P | Reuse design infrastructure; profile-local screening ownership stays distinct | Yes |
| Design concepts, classifier relations and project outcome schemas | Existing Design, P | Reuse, versions/evidence retained; no permission merely from being an entity author | Yes |
| Publish question/form/schema version and impact policy | NEW Publish review definitions, P | Separate publication from draft Design; propose explicit gate over version usage/impact choices | Yes |
| Configure stage steps, bindings, blinding, EW1 and auto/manual lifecycle | Existing Design, S | Reuse; form targets remain form-owned, screening rules profile-owned | Yes |
| View own session, autosave, Save, Complete, correct own answer | Existing Review, S plus owner/admission | Reuse; completion history alone gives no new-stage access; Complete validates | Yes, subject to eligibility |
| View own original answer and ancestors across compatible forms | Review plus applicable current context access | Reuse; exact repeated-entity/branch identity; no universal other-candidate read | Yes, own only |
| View pool/held/correction summaries | NEW View review work context, S | Separate limited summaries from answer content; admission cannot be inferred from seeing work | Yes |
| Receive/start/reacquire ordinary reconciliation and publish initial gold | Existing Reconcile, S plus task eligibility | Reuse; one shared study/form task accessible through eligible bound stage | Yes, subject to eligibility |
| View other candidates during reconciliation | Reconcile + claimed eligible task + stage policy | Scoped to task sources, blinded aliases; no standalone bulk candidate viewer proposed | Yes, within task only |
| View accepted/gold answers | Existing answer-view policy + context access | Verify actual read endpoints; grant Review/Reconcile does not override stage visibility toggle | Yes, policy-limited |
| Assign explicit reconciliation study / override its unstarted expiry | NEW Assign reconciliation work, S | One grant for assignment and audited per-assignment expiry override; recipient still eligible | Yes |
| Release started reconciliation assignment | NEW Release reconciliation work, S | Separate from assignment and Reconcile; preserve saved work, require reacquisition | Yes |
| Request independent additional review | NEW Request additional review, S | Confirmed separate capability, never implicit Reconcile or assignment | Yes |
| Receive additional review request | Review + independent eligibility | No auto-grant, no candidate exposure; normal target unchanged | Yes, eligible only |
| Raise accepted-answer query | Existing accepted-answer view access | Confirmed no extra query-creation grant; exact accepted version pinned | Yes, if visible |
| Resolve query / approve replacement gold | NEW Resolve accepted-answer queries, S | Separate from ordinary Reconcile; valid affected children and snapshot publication required | Yes |
| Authorized query self-review | Same query-resolution grant | Permitted, audited; prefer other resolver, no new self-review grant | Yes, if authorized |
| View agreement statistics | NEW View agreement statistics, S | Separate confirmed AG1; reuse progress permission only if actual scope matches after endpoint audit | Yes |
| View project aggregate agreement report | Agreement grant for every included S + project context | No project statistics shortcut to ungranted stage; sanitize aggregate outputs | Yes, permitted stages |
| Manually Complete / reopen stage | NEW Manage stage lifecycle, S | Separate from Design/Reconcile; proposed action label, not an approved new Reopen grant | Yes |
| Confirm change that would reopen Completed stage | NEW Approve completed-stage change, S | Admin-only approval workflow proposal; caller also needs underlying write grant | Yes |
| Calculate automatic stage readiness/status | System transition under configured stage policy | No person grant from automatic status; approval token required for controlled change | Not a user grant |
| Preview schema migration/dry-run mapping | Design, P + authorized data-view access | Read-only mapping design; no data visibility expansion | Yes |
| Approve/run/revert scoped outcome migration | NEW Manage outcome migration, P | Separate from Design, Publish and ExportData; exact approved run/version manifest | Owner/delegated only initially |
| Download current / available historical / as-of answers | Existing ExportData, P + answer visibility | Reuse; authorize at retrieval/delivery; historical rights never expose otherwise hidden candidates | Yes |
| Receive assignment/query/status notification | No new grant | Content filtered by current access; notification/assignment cannot grant an action | Not a grant |
Delegation boundaries and gaps¶
Recommendation: ordinary admin gets Yes rows, preserving owner-only Delete/ChangeOwner defaults; permission administration explicitly granted by owner to a group, and migration execution delegated explicitly until its first approved cutover. This extends Chris's broad ordinary-admin direction with proposed safeguards for owner-only current actions, rather than pretending an exact default set was approved. PM2 confirmed: owner may assign permission administration to a membership group. Members can administer grants within its approved scope; this is an intentional extension of current owner-only AssignPermissions, not merely an unresolved gap.
Recommendation: reserve creation/enlargement/revocation of delegation envelopes and assignment of the permission-administration capability itself to the owner. Delegates cannot recursively delegate that capability or transfer ownership. Permission administrators may only grant actions and stage scopes inside an owner-defined delegation envelope; they cannot enlarge their own envelope, make themselves owner, or escalate through group membership edits. Group management must not let a membership editor add themselves to a privileged group unless they also hold authority for that group's grants. Audit actor, scope, before/after grants and source authority. Revocation applies at command/read boundary and stale-work submission; retained history is not erased.
Gaps to implement after approval: bounded delegation representation; group-CRUD endpoint audit; new capability identifiers and enum append strategy; accepted/candidate visibility policy audit; shared-form reconciliation stage-access routing; permission-aware statistics; migration-run and lifecycle approval gates. No assignment, notification, Reconcile or grant possession implies permission administration. Cross-stage shared sessions must not select a weaker stage to bypass blinding or affected-stage lifecycle approval.
PRISMA action/read boundary integration¶
Stage Reconcile must cover both authorized ordinary and screening reconciliation as FEAT-011 Phase 8 specifies; sharing a workbench never lets ordinary gold update screening outcomes. Existing project ExportData plus visibility governs PRISMA/current/history downloads. A statistics view grant is not a blanket raw-record/candidate export right. System Publication metadata linking does not expose another project's Citations/reviews; project/stage/resource checks still apply. Recommend existing Design/publish authority for configuring report profile/filter mappings, with separate reviewed-dedup/import action mapping validated against existing project ImportSearch/ BulkUpdateStudies authority. Those grants do not imply migration execution or gold approval. Track accepted/reason sources without leaking blinded reviewer identities. Partial-reason/history coverage and unknown report identity remain visible to permitted report users, not bypassed by an admin label. See PRISMA comparison for phase/read contracts.
Group templates — implementer discretion¶
After the complete capability inventory is finalized, implementers may choose intuitive editable bundles; names and bundling are not mandatory owner questions. Examples: Reviewers (Review, limited own/context reads); Reconcilers (Reconcile, eligible task candidates); Designers (Design, optional separate publication); Workflow administrators (assignment/release/lifecycle); Statistics readers (agreement view only); Permission administrators (owner-granted bounded delegation). Ordinary project admin bundles broadly include matrix Yes actions, but never automatically permission administration, ownership transfer or other owner-reserved exceptions. Bundles are editable grants, not code branches keyed to group names. Assignment does not add a person to a group. Avoid one role per study/form/population; use resource scope and task eligibility.
See the RBAC research brief for primary-source guidance and SyRF-specific recommendations, including revocation and cross-project resource checks.
Practical approval checklist¶
- Approve matrix separation: Publish, work-context view, assign/expiry, release, extra review, query resolution, agreement statistics, lifecycle management/approval and migration execution.
- Approve reuse of EditMemberships for groups, with privileged-group escalation protection.
- Approve ordinary-admin Yes defaults; keep transfer/delete owner-only and initially explicit migration delegation. Permission administration is owner-granted to groups under PM2; approve the proposed non-recursive, owner-managed delegation envelope.
- Approve bounded project/stage delegation and task-limited candidate visibility.
- Approve action identifiers only after endpoint/catalogue audit; these labels are proposals.
Suggested implementation checks: Review without extra-review cannot request it; Reconcile without query-resolution cannot approve a query; assigner cannot make an ineligible person eligible; blinded statistics do not disclose candidates; membership editor cannot self-escalate; expired approval or revoked permission cannot commit; owner-only actions stay owner-only. These are acceptance cases for future implementation, not software tests performed in this docs task.