Partner Delegation Matrix

Defines what a white-label partner (typically the client's accountant or auditor) may do inside a client tenant, how that authority is granted at onboarding, and which capabilities can never be delegated.

1. Purpose

White-label partners manage ZAYAZ on behalf of their clients through Atlas. Each client relationship needs an explicit, versioned statement of what the partner may do. This document defines:

• the capability catalogue — the atomic things a partner can be allowed to do,
• the delegation levels — how much authority the partner holds per capability,
• the presets — sensible defaults so onboarding is one click for most clients,
• the invariants — capabilities that stay with the client regardless of preset,
• the mechanics — how the answered matrix is stored, enforced and changed.

2. Delegation levels

Level	Meaning	Enforcement
P — Partner manages	Partner acts directly; client is notified.	Direct write, logged.
A — Partner proposes, client approves	Partner action creates a pending change; client approves or rejects.	Maker–checker workflow (§6.1).
C — Client only	Partner has no write access. Read access governed by SHARE.PARTNER.VIEW.	Denied at authorisation layer.
—	Not applicable to the partner role.	—

Levels are strictly ordered C < A < P. A client may always tighten (move toward C); loosening requires re-acceptance (§6.3).

3. Presets

Preset	Intended relationship
full_service	Partner runs the client's sustainability reporting end to end. Client signs off.
advisory	Partner guides and reviews; client owns methodology and content.
data_entry	Partner handles bookkeeping-adjacent data only; no reporting authority.

full_service is the ceiling: the survey can only tighten from there. data_entry is the floor: its P rows are implied by the relationship existing and are not presented as questions.

4. Capability matrix

Legend: P partner manages · A partner proposes, client approves · C client only

4.1 DATA — source data and mapping

Code	Capability	full_service	advisory	data_entry	Notes
DATA.INTEGRATION	Connect and maintain accounting / ERP integrations	P	P	P	Partner usually holds the credentials. Floor.
DATA.UPLOAD	Upload source data (bills, ledgers, travel, fuel)	P	P	P	Floor.
DATA.MAPPING	Map chart of accounts to ESG categories; select emission factors	P	A	P	Advisory clients tend to own methodology.
DATA.SUPPLIER.REQUEST	Send supplier data requests and chase responses	P	A	C	Pairs with COMM.SUPPLIERS.
DATA.SUPPLIER.APPROVE	Approve or reject supplier submissions	P	A	C

4.2 REPORT — preparation and publication

Code	Capability	full_service	advisory	data_entry	Notes
REPORT.DRAFT	Prepare and edit reports (VSME, ESRS, GHG inventory)	P	P	C
REPORT.MATERIALITY	Run materiality assessment; maintain topic list	A	A	C	Management judgment — default to approval.
REPORT.CALENDAR	Reporting calendar, deadlines, framework selection	P	A	C
REPORT.PUBLISH	Final approval and publication	A	C	C	Never P. Publication is a client act.
REPORT.ATTEST	Management attestations and representations	C	C	C	Invariant.

4.3 SHARE — data leaving the tenant

Code	Capability	full_service	advisory	data_entry	Notes
SHARE.EXTERNAL	Share data with third parties (banks, customers, CBAM)	A	C	C	Anything leaving the tenant needs a client act.
SHARE.GRANT	Create or modify ESGX access grants	C	C	C	Invariant. Client-owned consent by design.
SHARE.PARTNER.VIEW	Partner may view all client data	P	P	P	Visibility switch, independent of edit rights. Floor.

4.4 ACCESS — users and roles

Code	Capability	full_service	advisory	data_entry	Notes
ACCESS.CLIENT.USERS	Invite / remove client staff; assign roles	P	A	C	Small clients delegate this readily.
ACCESS.PARTNER.TEAM	Partner's own team access to the tenant	P	P	P	Always partner-side; client sees the list.
ACCESS.OWNER	Change client owner / admin	C	C	C	Invariant.

4.5 ACCOUNT — commercial and legal

Code	Capability	full_service	advisory	data_entry	Notes
ACCOUNT.SUBSCRIPTION	Tier, add-ons, upgrades	A	A	C	Partner often initiates; client pays.
ACCOUNT.BILLING	Billing details, payment method	C	C	C	Invariant. If the partner is the billed party this is a platform-level contract, not a survey question.
ACCOUNT.ENTITY	Legal entity details, organisation structure	A	A	C
ACCOUNT.RETENTION	Data retention, export, deletion	C	C	C	Invariant.

4.6 COMM — notifications and communication

Code	Capability	full_service	advisory	data_entry	Notes
COMM.NOTIFY	Configure recipients for deadline and audit alerts	P	P	P	Both parties may always add themselves. Floor.
COMM.SUPPLIERS	Partner may contact suppliers on the client's behalf	P	A	C	Pairs with DATA.SUPPLIER.*.
COMM.AUDITLOG	Partner may view client activity log	P	P	P	Not switchable off for the partner's own actions. Floor.

5. Invariants and floor

5.1 Invariants — always C

These are platform rules, not survey questions. They are shown greyed-out in the onboarding survey so the client can see what the partner cannot take.

• REPORT.ATTEST
• SHARE.GRANT
• ACCESS.OWNER
• ACCOUNT.BILLING
• ACCOUNT.RETENTION
• REPORT.PUBLISH may never be P (ceiling is A)

5.2 Floor — always P

Implied by the partner relationship existing. Not presented as questions.

• DATA.INTEGRATION
• DATA.UPLOAD
• SHARE.PARTNER.VIEW
• ACCESS.PARTNER.TEAM
• COMM.NOTIFY
• COMM.AUDITLOG

5.3 Survey questions

The onboarding survey asks only about rows that vary between presets, pre-filled from the selected preset:

DATA.MAPPING · DATA.SUPPLIER.REQUEST · DATA.SUPPLIER.APPROVE · REPORT.DRAFT · REPORT.MATERIALITY · REPORT.CALENDAR · REPORT.PUBLISH · SHARE.EXTERNAL · ACCESS.CLIENT.USERS · ACCOUNT.SUBSCRIPTION · ACCOUNT.ENTITY · COMM.SUPPLIERS

Twelve questions, each a three-way choice bounded by the row's ceiling.

6. Mechanics

6.1 Maker–checker for level A

Level A must be a real workflow, not a notification:

1. Partner performs the action; the system records a pending_change with a structured diff, actor, timestamp and capability code.
2. Client approver is notified in-app and by email.
3. Client approves or rejects, optionally with a comment.
4. Both the proposal and the decision are written to the audit log.
5. Pending changes expire after a configurable period (default 30 days) and are recorded as expired, never silently dropped.

6.2 Storage

The answered matrix is stored as a versioned delegation_policy document on the client tenant.

delegation_policy:
  tenant_id: t_01HXYZ...
  partner_id: p_01HABC...
  version: 3
  preset: full_service
  answered_by: { actor_id: u_..., role: partner_admin, at: 2026-09-18T10:12:00Z }
  accepted_by: { actor_id: u_..., role: client_owner,  at: 2026-09-18T14:03:00Z }
  effective_from: 2026-09-18T14:03:00Z
  effective_to: null
  levels:
    DATA.MAPPING: P
    DATA.SUPPLIER.REQUEST: P
    DATA.SUPPLIER.APPROVE: P
    REPORT.DRAFT: P
    REPORT.MATERIALITY: A
    REPORT.CALENDAR: P
    REPORT.PUBLISH: A
    SHARE.EXTERNAL: A
    ACCESS.CLIENT.USERS: P
    ACCOUNT.SUBSCRIPTION: A
    ACCOUNT.ENTITY: A
    COMM.SUPPLIERS: P

Invariant and floor rows are not stored; they are resolved from the platform policy at authorisation time. Every generated report, publication and external share stamps the delegation_policy.version in force.

6.3 Change control

• Tighten (toward C): client may change at any time from tenant settings. Takes effect immediately. Logged.
• Loosen (toward P): either party may propose; requires acceptance by the client owner. Creates a new policy version.
• Preset change: treated as a full re-survey with re-acceptance.
• Partner change: a new partner relationship starts from data_entry and runs the survey from scratch; the previous policy is closed with effective_to set.
• If the partner completes the survey on the client's behalf, accepted_by must be a client actor before the policy becomes effective. Until then the tenant operates at data_entry.

6.4 Partner-side views

• Per client: the effective matrix, read-only, with pending changes.
• Rollup across the partner's book: counts per preset and per non-default row (e.g. "14 clients on full_service, 3 with REPORT.PUBLISH at C").
• Filterable work queue of pending A items awaiting client decision.

6.5 Authorisation integration

Each capability code maps to one or more Atlas scopes. The authorisation layer resolves effective_level(tenant, partner, capability) as:

invariant(capability)            → C
floor(capability)                → P
else delegation_policy.levels[capability]

and applies:

• P → grant write scope to partner actors.
• A → grant propose scope; direct write denied.
• C → deny write; read governed by SHARE.PARTNER.VIEW.

Mapping of capability codes to concrete scope names is out of scope for this document and belongs in the Atlas authorisation spec.

7. Open questions

• Should REPORT.MATERIALITY be allowed at P for full_service clients who explicitly opt in, given some accounting firms run it as a service?
• Is a fourth preset (audit_only: view-everything, write-nothing) needed for assurance providers who are not the bookkeeping partner?
• Should pending-change expiry be per capability rather than global?

8. Change log

Version	Date	Change
0.1.0	2026-09-18	Initial draft from brainstorming session.