013 — Project Relationship Defaults (v1.0)
WST • PRIVATE • AUDITABLE • HUMAN-FIRST
Purpose
Define the default permission templates for project relationships so that project association assignments are:
consistent
understandable
enforceable
safe by default
Relationship names describe participation.
Default permissions make that participation operational.
Core Doctrine
Relationships are project-scoped, not charter-scoped
Defaults are templates, not permanent truth
Explicit permissions still win
Sensitive rights should default closed
Approval and execution rights must be granted deliberately
No relationship should silently inherit treasury or global governance power
Default Permission Set
Canonical project permission fields:
{
"view": false,
"comment": false,
"contribute": false,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
Relationship Defaults
- OWNER
Primary accountable participant for the project.
Default intent
The person or seat holding the core project responsibility.
Default permissions
{
"view": true,
"comment": true,
"contribute": true,
"manage": true,
"approve": true,
"queue_execution": true,
"see_financials": true,
"edit_public_summary": true
}
Notes
Should usually exist on every project
May be a Trustee, Charter Admin, or designated Lead
Does not imply treasury control
- LEAD
Primary working lead for day-to-day execution.
Default permissions
{
"view": true,
"comment": true,
"contribute": true,
"manage": true,
"approve": false,
"queue_execution": true,
"see_financials": false,
"edit_public_summary": false
}
Notes
Strong operational role
Can move work forward
Approval remains closed by default
- TRUSTEE_SPONSOR
Governance-level sponsor attached to the project.
Default permissions
{
"view": true,
"comment": true,
"contribute": false,
"manage": true,
"approve": true,
"queue_execution": true,
"see_financials": true,
"edit_public_summary": true
}
Notes
Used for host charter oversight
Good for Jonesboro trustee-style sponsorship
Contribute defaults off because this is more governance than labor
- CHARTER_ADMIN
Local charter operator supporting project structure.
Default permissions
{
"view": true,
"comment": true,
"contribute": true,
"manage": true,
"approve": false,
"queue_execution": true,
"see_financials": false,
"edit_public_summary": true
}
Notes
Good for local operations
Approval closed unless explicitly granted
- OPERATOR
Active working operator in project flow.
Default permissions
{
"view": true,
"comment": true,
"contribute": true,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
Notes
Default “do the work” role
Cannot manage or approve by default
- CONTRIBUTOR
Participant adding labor, knowledge, or materials.
Default permissions
{
"view": true,
"comment": true,
"contribute": true,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
Notes
Similar to Operator but less structural implication
Good general-purpose project participant default
- PARTNER
Cross-charter or external collaborating participant.
Default permissions
{
"view": true,
"comment": true,
"contribute": true,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
Notes
Important for your multi-charter / partnership model
Participation without host governance inflation
- ADVISOR
Guidance-oriented participant.
Default permissions
{
"view": true,
"comment": true,
"contribute": false,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
Notes
Can see and advise
No direct work or structural power by default
- OBSERVER
Read-only participant.
Default permissions
{
"view": true,
"comment": false,
"contribute": false,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
Notes
Best for visibility without operational access
- FUNDER
Funding participant or sponsor with limited project access.
Default permissions
{
"view": true,
"comment": true,
"contribute": false,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": true,
"edit_public_summary": false
}
Notes
Can see financial/project status
Does not gain management automatically
- VENDOR
Service or goods provider.
Default permissions
{
"view": true,
"comment": true,
"contribute": true,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
Notes
Can work within scope
No structure-level control by default
Summary Table
Relationship View Comment Contribute Manage Approve Queue Exec Financials Edit Public
OWNER ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
LEAD ✓ ✓ ✓ ✓ ✓
TRUSTEE_SPONSOR ✓ ✓ ✓ ✓ ✓ ✓ ✓
CHARTER_ADMIN ✓ ✓ ✓ ✓ ✓ ✓
OPERATOR ✓ ✓ ✓
CONTRIBUTOR ✓ ✓ ✓
PARTNER ✓ ✓ ✓
ADVISOR ✓ ✓
OBSERVER ✓
FUNDER ✓ ✓ ✓
VENDOR ✓ ✓ ✓
Assignment Rules
- Defaults apply at assignment time
When a project association is created, the relationship default may prefill permissions.
Example:
{
"relationship": "PARTNER",
"permissions": {
"view": true,
"comment": true,
"contribute": true,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
}
- Explicit permission overrides are allowed
A specific project may adjust defaults, but only explicitly.
Example:
a Lead may get approve = true
a Partner may get queue_execution = true
This must be recorded, not implied.
- Sensitive rights should be rare
These should default closed unless clearly intentional:
approve
queue_execution
see_financials
edit_public_summary
- Relationship name does not override explicit permissions
If a record says:
{
"relationship": "OWNER",
"permissions": {
"approve": false
}
}
Then approve is false.
Rule:
explicit permissions win over defaults
Recommended Canonical Defaults Store
Suggested file:
/portal/_data/projects/relationship_defaults.json
Example structure:
{
"v": "wst.project.relationship.defaults.v1",
"defaults": {
"OWNER": {
"view": true,
"comment": true,
"contribute": true,
"manage": true,
"approve": true,
"queue_execution": true,
"see_financials": true,
"edit_public_summary": true
},
"PARTNER": {
"view": true,
"comment": true,
"contribute": true,
"manage": false,
"approve": false,
"queue_execution": false,
"see_financials": false,
"edit_public_summary": false
}
}
}
Resolver Interaction
The Project Access Resolver should:
load relationship default
merge explicit association permissions
return effective permission set
Recommended rule:
effective permissions =
relationship defaults
overlaid by explicit association permissions
Host Authority Interaction
These defaults apply to project association path.
They do not replace:
charter binding authority
trustee/admin host authority
If a user enters through host authority path, route-level charter authority may still provide stronger permissions than their association record.
Recommended doctrine:
host authority governs structure
association defaults govern participation
Assignment Guidance
Best default combinations:
host trustee who owns project → OWNER or TRUSTEE_SPONSOR
day-to-day working leader → LEAD
local worker → OPERATOR or CONTRIBUTOR
other-charter collaborator → PARTNER
outside consultant → ADVISOR
visibility-only guest → OBSERVER
financing participant → FUNDER
service supplier → VENDOR
Anti-Drift Rules
Do not infer permissions from relationship label alone at runtime
Do not grant approval/financial access casually
Do not use defaults to bypass explicit permission review
Do not make partners local charter admins through project defaults
Do not let relationship defaults leak into treasury or global authority
Example for Your Jonesboro Project
Trustee owner
{
"relationship": "OWNER"
}
Defaults to:
full project operational control
no treasury control implied
External partner
{
"relationship": "PARTNER"
}
Defaults to:
participate
no manage
no approve
That’s clean and exactly what you were trying to preserve.
Final Principle
Relationship defaults should make common assignments easy, but never make sensitive authority accidental.