Partner Delegation Matrix v0.2.0

A client-controlled, versioned agreement describing what a partner organisation may do in a client account. Atlas derives individual runtime grants from that agreement; operational approvals and TrustGate continue to govern execution.

1. Purpose and architectural boundary

White-label partners can deliver services through ZAYAZ with substantially less manual work. Once a client delegates a capability, eligible partner actors and explicitly authorised automation can prepare data, maintain workflows and perform permitted operations on the client's behalf. Routine work may run without a partner employee initiating every step. Client approval, platform rules and TrustGate still apply wherever required.

The client delegates to a partner organisation, not permanently to a named employee. The client remains in control of the relationship, the delegated capabilities and the ability to reduce or withdraw access. Product language uses the client's and partner's display names and the configured product brand; white-label presentation does not conceal who receives authority or who performs an action.

This specification defines the capability matrix, preset templates, policy lifecycle, normalized persistence contract, derived grants, approval workflows, audit evidence and client experience. New table structures and fields below are proposed implementation contracts, not claims that migrations already exist. Existing Atlas role and permission mappings must be verified during implementation. No PP-specific dependency is required.

1.1 One responsibility per layer

Layer	Question answered	Responsibility
Partner relationship	Which client and partner are connected, and in what state?	Identity, tenant boundary and relationship lifecycle.
Delegation policy	What has the client delegated to the partner organisation?	Immutable, client-authorised intent expressed as a capability matrix.
Grant reconciler	Which actors should hold which grants now?	Derive and revoke grants using policy, eligible team membership and internal partner roles.
atlas.actor_role	What scoped roles does this actor currently hold?	Canonical runtime authorization-grant ledger.
atlas.authorize_request()	Is this actor authorised for this permission in this scope?	Existing Atlas authorization and persisted decision evidence.
Operational approval	Has the client approved this exact A-level proposal?	Maker–checker decision bound to a specific action and payload.
TrustGate	May this consequential action execute under applicable policies?	Required execution checks and evidence.

Client acceptance or authorised reduction
                  |
                  v
Partner relationship + immutable delegation policy version
                  |
                  v
Grant reconciler <--- eligible partner membership + internal role
                  |
                  v
atlas.actor_role (actor-specific, tenant-scoped grants)
                  |
                  v
atlas.authorize_request() ---> authorization_decision
                  |
                  v
Operational approval where required + TrustGate where required
                  |
                  v
Execution and attributable audit evidence

The matrix is a governed generator of existing Atlas roles and permissions. It is not a second runtime authorization resolver. Neither the settings page nor an acceptance link writes arbitrary grants directly into atlas.actor_role.

2. Delegation levels

Level	Client-facing meaning	Enforcement
P — Partner manages	Partner may act directly.	Eligible actors receive the governed manage permissions in the client tenant. Required TrustGate checks and other execution constraints still apply.
A — Partner proposes, client approves	Partner prepares a proposal; an authorised client actor approves or rejects it.	Partner receives propose permissions, without the corresponding direct execution permission. Approval is bound to the exact proposal.
C — Client only	This capability stays with the client.	No partner manage or propose grant is derived for this capability. Separately delegated read access may still apply.
—	Not applicable.	Display-only value; never stored as an authority level or interpreted as a grant.

For an unchanged action capability and unchanged constraints, authority increases in the order C → A → P. This is a per-capability comparison, not an ordering of presets. Read capabilities support only P and C; A is not a meaningful substitute for authenticated consent to ongoing visibility.

P does not mean unconditional execution, exemption from TrustGate, access to all data, permission to impersonate the client, or permission to extend the partner's own authority. Notifications follow the capability's governed notification rules and user preferences; they are not a mandatory message for every P-level action.

3. Presets are templates

Preset	Intended relationship	Client explanation
full_service	Partner prepares and manages the reporting process.	“Your partner handles routine work. You retain the approvals and decisions shown below.”
advisory	Partner guides and reviews.	“Your partner helps prepare your work and proposes changes where your approval is required.”
data_entry	Partner handles bookkeeping-adjacent data.	“Your partner maintains source data and account mapping, without reporting or methodology authority.”

Selecting a preset creates a proposed complete matrix, including explicit visibility constraints. Clients can review and override every configurable row. No preset is a privilege floor or ceiling. Allowed levels and non-delegable capabilities come from the governed registry independently of preset defaults.

Presets are deliberately not monotonic: DATA.ACCOUNT.MAPPING is A in Advisory and P in Data Entry. Switching to Data Entry can therefore increase one permission while reducing others. Acceptance is determined by the actual capability and constraint diff, never by the preset's name, array position or marketing description.

4. Capability matrix

These tables modernize the v0.1.0 catalogue. Defaults become authority only after authenticated client acceptance and grant activation. Every default P row can be reduced unless it is explicitly described as an organisation-level relationship mechanic outside the tenant matrix.

Allowed lists the platform-permitted choices. Preset values are recommended starting points within those choices. All effective policies store a complete resolved matrix, including locked C rows, plus registry and mapping revisions.

4.1 DATA — source data and mapping

Code	Capability	Full service	Advisory	Data entry	Allowed	Conditions
DATA.INTEGRATION	Connect and maintain accounting / ERP integrations	P	P	P	C, A, P	Explicit delegation; credentials and connector data boundaries remain governed. No implied access from possessing credentials.
DATA.UPLOAD	Upload source data: bills, ledgers, travel and fuel	P	P	P	C, A, P	Validation and data-access constraints apply. No automatic relationship floor.
DATA.ACCOUNT.MAPPING	Map accounts or transactions to sustainability categories	P	A	P	C, A, P	Bookkeeping-adjacent classification; does not authorise factor or methodology changes.
DATA.FACTOR.SELECT	Select or override emission factors and calculation methodology	P	A	C	C, A, P	Separate methodological authority; required calculation governance and TrustGate apply.
DATA.SUPPLIER.REQUEST	Request supplier data and chase responses	P	A	C	C, A, P	Requires the applicable supplier communication permission for outbound messages.
DATA.SUPPLIER.APPROVE	Accept or reject supplier submissions	P	A	C	C, A, P	Acceptance of supplier data is distinct from approval of a partner's A-level proposal.

4.2 REPORT — preparation and publication

Code	Capability	Full service	Advisory	Data entry	Allowed	Conditions
REPORT.DRAFT	Prepare and edit reports: VSME, ESRS, GHG inventory	P	P	C	C, A, P	Drafting does not authorise publication or attestation.
REPORT.MATERIALITY	Run materiality assessment and maintain topic list	A	A	C	C, A	Management judgment remains subject to client approval in v0.2.0.
REPORT.CALENDAR	Maintain deadlines, reporting calendar and framework selection	P	A	C	C, A, P	Methodology changes additionally require the relevant capability.
REPORT.PUBLISH	Propose final publication	A	C	C	C, A	Never P. Final approval is an authorised client act.
REPORT.ATTEST	Make management attestations and representations	C	C	C	C	Non-delegable.

4.3 SHARE — visibility and data leaving the tenant

Code	Capability	Full service	Advisory	Data entry	Allowed	Conditions
SHARE.EXTERNAL	Propose sharing with third parties, including banks and customers	A	C	C	C, A	Never P. Client approval binds recipient, data, purpose and duration.
SHARE.GRANT	Create or modify ESGX access grants	C	C	C	C	Client-owned consent; operational sharing approval cannot create this authority.
SHARE.PARTNER.VIEW	View explicitly selected client data	P	P	P	C, P	Opt-in visibility with an explicit data boundary. Never “all data” by default or by relationship existence.

Each preset proposes a visible data boundary for SHARE.PARTNER.VIEW: Full service proposes the data needed for selected reporting and source-data tasks; Advisory proposes the data needed for review; Data entry proposes source records and account/category mappings. These descriptions must resolve to explicit, versioned resource classes, fields or other enforceable filters before acceptance. They are not runtime wildcard rules. New data classes are excluded until explicitly added and accepted.

Capability-specific read dependencies must be shown and accepted. If required visibility is absent, reject the configuration with an explanation or keep the dependent operation unavailable; never silently broaden visibility. Read permission does not include bulk export, external sharing, billing secrets or unrelated tenant records.

4.4 ACCESS — users and roles

Code	Capability	Full service	Advisory	Data entry	Allowed	Conditions
ACCESS.CLIENT.USERS	Invite or remove client staff and assign permitted roles	P	A	C	C, A, P	Restricted role allowlist; cannot grant ownership, delegation approval authority or equivalent escalation paths.
ACCESS.PARTNER.TEAM	Assign eligible members of the partner team to this client	P	P	P	C, A, P	Within the accepted delegation and internal team-management rights; never expands the matrix.
ACCESS.OWNER	Change client owner or administrator	C	C	C	C	Non-delegable.

A partner manages its own organisation membership under separate organisation permissions. Removing a member always revokes their derived client grants. Adding a member to the organisation alone does not guarantee client access: an authorised assignment to the client, internal role eligibility and the client's active policy are also required. At C, the client controls those assignments; at A, the partner can propose them. The client can inspect and remove client assignments at any time.

4.5 ACCOUNT — commercial and legal

Code	Capability	Full service	Advisory	Data entry	Allowed	Conditions
ACCOUNT.SUBSCRIPTION	Change subscription tier and add-ons	A	A	C	C, A	Client approves commercial commitments.
ACCOUNT.BILLING	Maintain billing details and payment method	C	C	C	C	Non-delegable in the client tenant. Partner-billed contracts are separate commercial arrangements.
ACCOUNT.ENTITY	Maintain legal entity details and organisation structure	A	A	C	C, A	Requires client approval.
ACCOUNT.RETENTION	Change retention, perform account export or request deletion	C	C	C	C	Non-delegable.

4.6 COMM — communication and activity visibility

Code	Capability	Full service	Advisory	Data entry	Allowed	Conditions
COMM.NOTIFY	Configure recipients for deadline and audit alerts	P	P	P	C, A, P	Recipients must be authorised for the content; subscription is not a data-access grant.
COMM.SUPPLIERS	Contact suppliers on the client's behalf	P	A	C	C, A, P	Explicit sender identity, purpose and applicable communication constraints.
COMM.AUDITLOG	View the selected client activity log	P	P	C	C, P	Explicit audit-data boundary and redaction; does not imply all client activity.

Limited relationship mechanics are separate from tenant-wide access: viewing one's own membership/access status, receiving appropriate relationship notifications and viewing redacted evidence of one's own actions. These mechanics must not reveal unrelated client data. After termination, any retained audit evidence is accessed through a separately authorised audit channel, not residual tenant grants.

5. Platform rules and registry governance

There is no always-P client-data floor. A pending relationship grants zero client tenant authority, including read access, uploads, integrations and automated background access. Invitation metadata can be exposed only through a narrowly scoped invitation workflow.

The following remain locked C: REPORT.ATTEST, SHARE.GRANT, ACCESS.OWNER, ACCOUNT.BILLING and ACCOUNT.RETENTION. REPORT.PUBLISH and SHARE.EXTERNAL can never be P. This revision also conservatively bounds materiality, subscription and legal-entity changes at A, reflecting their existing Full service defaults; future expansion requires an explicit registry decision and client acceptance.

The capability registry defines stable codes, descriptions, permitted levels, permission mappings, read dependencies, constraints, approval requirements and notification behaviour. Role mappings must not bundle unrelated powers. Composite operations require every applicable permission; choosing P for one capability does not override A or C for another.

Registry revisions are immutable. A revision that adds permissions, broadens data visibility or weakens approval constraints must not expand existing grants silently. It requires a new policy version and authenticated acceptance for affected clients. A new restrictive platform rule can block execution immediately, with recorded governance evidence and reconciliation to new restrictive versions. Unknown capabilities or unsupported mappings grant nothing.

6. Immutable versions and change control

6.1 Relationship and policy lifecycle

State or event	Effect on authority
Invited / pending relationship	Zero tenant authority. Partner may prepare a request, without tenant data access.
Submitted policy awaiting acceptance	No new authority. An existing accepted policy continues unchanged unless separately tightened or suspended.
Accepted policy awaiting activation	Client intent is recorded; additional grants are not yet usable.
Active relationship and effective policy	Only reconciled eligible grants are usable.
Suspended relationship	All grants derived from that relationship are disabled; history is retained.
Terminated relationship	Derived grants are revoked, pending work is cancelled or blocked, and history is retained.
Replacement partner	New relationship and fresh acceptance; no inherited Data entry access or transfer of the former partner's consent.

A policy row represents one immutable version. A mutable editor draft is not yet a policy version. Submission freezes its content; subsequent edits create a new candidate. Declined, expired and superseded candidates remain in history. Every effective matrix or constraint change creates a new version, including reductions. Restoring an old matrix creates a new version rather than reactivating history in place.

Immutable policy content and append-only lifecycle events are authoritative. Fields such as current status, effective interval and active-policy pointer may be maintained as transactionally consistent projections of those events; they do not permit rewriting accepted content or historical evidence.

6.2 Classifying changes

Change	Acceptance and effect
Pure reduction	An authorised client actor may apply immediately, without an additional acceptance ceremony. Create a version and record the actor and reason.
Any increase	Requires authenticated acceptance by a client actor authorised to manage delegation in this tenant. Becomes effective only through controlled activation.
Mixed reduction and increase	Keep the proposed version pending as a whole. Offer a separate “Apply reductions now” action that creates its own version; rebase and reconfirm the remaining increases.
Preset change	Compare resolved rows and constraints. A preset label change alone does not imply increased authority.
Visibility or constraint change	Wider data boundaries, added recipients or weaker approval requirements count as increases even when P/A/C is unchanged.
Partner-requested reduction	May be proposed; the partner can immediately relinquish its own grants or suspend its service. It cannot edit client intent as if it were the client.

For unchanged registry mappings and constraints, a row-level increase exists whenever the proposed level outranks the effective level. All other permission-set and constraint changes also require comparison. If the system cannot prove that a change is purely restrictive, require acceptance.

Acceptance binds the tenant, partner, policy ID, version, canonical hash and base version shown to the client. The server checks the authenticated actor's current permission; a checkbox, email possession or partner assertion of authority is insufficient. Reject stale base versions and require a fresh review rather than silently merging concurrent changes.

6.3 Effective means enforced

Activation and reconciliation must prevent a window in which revoked grants remain usable. Use a transaction where possible; otherwise block affected delegated execution while removing old grants, invalidating authorization caches and installing the new set. Do not report a reduction as effective while obsolete grants can still execute.

For increases, pending or partially generated grants remain unusable until activation completes. Retry reconciliation idempotently. Failures are visible to operators and the client as pending activation or blocked access, never as successful broadening. Suspension, membership removal and termination apply the same immediate invalidation discipline. Recheck authority before queued or long-running work commits consequential effects.

7. Partner actors and runtime grant derivation

7.1 Eligibility and least authority

An actor's derived authority is the intersection of:

1. The active relationship and effective client-approved policy.
2. Active membership in the named partner organisation, or an explicitly governed automation identity bound to that organisation.
3. An authorised assignment to the client and the partner's internal role permissions.
4. Current platform restrictions, data boundaries and grant validity.

Client delegation sets the maximum available authority; it does not require every partner employee to receive all of it. Team additions derive only eligible grants. Internal role reductions, assignment removal and membership departure revoke the affected grants without requiring a client to repeat consent. Client settings show who currently has access, including automation identities where applicable.

7.2 Mapping levels into Atlas

Example capability	Level	Derived grant intent	Scope
COMM.SUPPLIERS	P	Governed manage role/permissions	scope_type = tenant, scope_ref = ECO-CLIENT-A
COMM.SUPPLIERS	A	Governed propose role/permissions; no direct send permission	Same tenant scope
COMM.SUPPLIERS	C	Neither partner manage nor propose grant	No grant for this capability

Concrete role codes are registry-controlled implementation mappings. Capabilities map to roles and permissions within a scope; they are not scope names. Derived partner grants must never be global. Data filters remain additional enforced resource constraints, not a replacement for the tenant boundary.

atlas.authorize_request() evaluates canonical grants. Where a permission has requires_trustgate=true, an RBAC allow is insufficient for execution until TrustGate permits it. P cannot disable that flag. A proposal permission cannot be substituted for the protected operation's execution permission.

7.3 Reconciliation and independent grants

Reconciliation consumes policy activation, relationship changes, membership/assignment changes and registry restriction events. It computes the expected grant set, revokes obsolete grants, creates source-attributed replacements and records its result. A stable derivation key prevents duplicate grants on retry.

Do not delete grant history or rewrite an old grant's provenance to point to a new policy. End the old grant and create its successor. Keep independently authorised grants and their provenance separate. Because Atlas may combine grants additively, removing a delegation grant does not necessarily remove an actor's independently granted authority. Prevent alternate partner role paths from defeating the delegation ceiling; expose genuine independent client roles separately in access review rather than claiming that the matrix revoked them.

8. Two distinct approval workflows

Workflow	Object approved	Consequence	UI queue
Delegation change	Exact proposed policy version and hash	Changes future derived authority	Access changes awaiting approval
Operational A-level proposal	Exact action, target and payload	Allows one approved operation under current authority and controls	Partner proposals awaiting approval

Operational approval never increases the delegation matrix. Delegation acceptance never approves future A-level actions in bulk. Both may share infrastructure, but must use distinct types, permissions and evidence.

8.1 Operational maker–checker

1. An authorised partner actor or automation submits a proposal. The system stores its capability, tenant, target, structured diff, payload hash, base resource version, proposing actor, policy/grant evidence and expiry.
2. The proposal creates no live business mutation or external communication. Staged uploads remain isolated until approval when that capability is A.
3. An authenticated client checker with the required tenant permission reviews the precise change. The checker must be distinct from the proposing actor, including where one person has multiple roles.
4. Approval or rejection is recorded immutably with actor, time, reason and the reviewed payload hash. An edited payload requires a new approval. The default proposal expiry is 30 days unless a stricter governed capability rule applies.
5. On execution, revalidate the proposal, expiry, target version, current relationship/policy, current execution authority and applicable TrustGate requirements. A stale or revoked proposal cannot execute on historical authority.
6. Execute through the authorised client action or an explicitly scoped approval-bound executor. Never grant the partner a standing manage role as a side effect of approval. Bind execution to the approved payload and make retries idempotent.
7. Record execution success, failure or cancellation separately from approval. Approval is not evidence that the action ran.

Publication and external sharing retain a client decision even when automation performs the approved delivery. Current C settings, relationship suspension or withdrawn approval block pending partner proposals; client-owned work may be initiated separately under the client's own permissions.

9. Normalized Atlas persistence model

Normalized rows are canonical. JSON is a deterministic export and hash representation; YAML may be offered for readable export but is not an authorization source.

9.1 Core records

Record	Required content and constraints
atlas.partner_relationship	relationship_id, partner_id, tenant scope_type / scope_ref, lifecycle state, effective dates and creation actor. Unique active relationship for a given partner and tenant; each partner relationship is independently governed.
atlas.partner_delegation_policy	delegation_policy_id, relationship_id, monotonically allocated version, base_policy_id, preset code/revision, registry/mapping revision, proposer/time, acceptance evidence reference, canonicalization version and policy_hash. Unique relationship/version. Frozen content after submission. Lifecycle/status and effective dates are event-derived projections.
atlas.partner_delegation_policy_item	policy_item_id, policy ID, capability code/revision, level P/A/C, normalized constraints, mapping revision and source preset, override or platform-rule. Unique policy/capability. Complete resolved matrix, including locked rows.
atlas.partner_delegation_policy_event	Append-only event ID, relationship/policy ID, event type, authenticated actor or system identity, timestamp, reason, request/correlation ID, relevant hashes and structured diff. Includes submission, acceptance, rejection, expiry, activation, supersession, reduction and revocation evidence.
atlas.partner_delegation_capability	Immutable code/revision catalogue: labels, descriptions, supported levels, constraints schema, manage/propose/read permission mappings, dependencies, approval/notification rules and deprecation status. Stable code identity with versioned definitions.

Versioned preset definitions and capability-to-role mappings should be normalized child records of the governed catalogue. A policy pins the revisions it resolves; a later template edit does not alter existing policy content.

Partner membership and client assignment references use Atlas's established identity model where available. The exact physical membership schema is not prescribed here. Operational proposals are separate records from delegation policy events; store their payload, approval and execution evidence under the operational workflow.

9.2 Grant provenance

Every derived atlas.actor_role row must have an immutable source reference, directly or through a dedicated normalized provenance record, containing:

Evidence	Purpose
actor_role_id	Exact runtime grant identity; retained after revocation.
Relationship, partner and tenant identifiers	Establish whose delegation and which tenant produced the grant.
Policy ID, version and hash	Identify the exact accepted or restrictively superseding policy.
Policy item ID, capability and mapping revision	Explain why this role was derived.
Membership and client-assignment references, internal role revision	Explain actor eligibility.
Acceptance/reduction event and reconciliation event	Connect client intent to grant materialization.
Validity and revocation evidence	Explain when the grant could be used and why it ended.

Do not collapse independently sourced grants into an unattributable shared row. If one role requires multiple source items, retain their explicit provenance links and revoke/recompute it when any required source ceases to apply.

atlas.authorization_decision must preserve the actor_role_id for each matched grant. The existing effective-permission view exposes that identifier; authorize_request() must carry it into persisted decision evidence rather than retaining only a role name. A conceptual matched-grant entry is:

{
  "actor_role_id": "grant-example-001",
  "role_code": "registry-defined-partner-role",
  "scope_type": "tenant",
  "scope_ref": "ECO-CLIENT-A"
}

The decision also records the requested permission, actor, tenant, target and correlation identifiers under the Atlas decision contract. Multiple matching grants remain distinguishable. A denial may have no matching grant. Historical decisions must remain understandable after membership removal or policy supersession.

Authenticated client acceptance / authorised restrictive change
  -> relationship + policy ID + version + hash
  -> policy item + mapping + eligible membership / assignment
  -> actor_role_id
  -> authorization_decision
  -> operational proposal / approval, where applicable
  -> TrustGate evaluation, where required
  -> executed action and result

Reports, publications and external shares retain their execution decision references and the applicable delegation policy evidence. A-level execution preserves both the partner proposal's grant evidence and the client/executor's authorization evidence; do not misattribute a client grant to the partner.

9.3 Canonical export and hashing

Use a versioned canonical JSON contract and SHA-256 over its UTF-8 bytes. The canonical payload includes schema version, relationship/partner/tenant IDs, policy ID/version, base policy ID, preset revision, catalogue/mapping revisions, proposer and the complete resolved item list with constraints and sources.

Sort items by capability code and explicitly set-like arrays by their documented stable keys. Preserve order where semantically meaningful. Use a specified JSON canonicalization algorithm, such as RFC 8785, with schema validation, normalized identifiers and UTC timestamps. Reject duplicate capability codes and ambiguous or unsupported values. Represent missing optional values consistently as specified by the export schema.

Exclude the hash itself and lifecycle fields that occur after content freezing—acceptance time, activation time, status and effective interval—from the hashed payload. Store these as event evidence bound to that hash. This avoids changing the approved hash when recording acceptance. Hashes demonstrate content identity, not the identity or authority of the person accepting.

Illustrative payload shape below shows one item only; production exports contain every registry-required item and fully resolved constraints. Example identifiers are descriptive placeholders.

{
  "schema_version": "atlas.partner-delegation/0.2.0",
  "canonicalization_version": "jcs-1",
  "delegation_policy_id": "policy-example-v4",
  "relationship_id": "relationship-example",
  "partner_id": "partner-example",
  "scope_type": "tenant",
  "scope_ref": "ECO-CLIENT-A",
  "version": 4,
  "base_policy_id": "policy-example-v3",
  "preset": { "code": "full_service", "revision": "0.2.0" },
  "registry_revision": "0.2.0",
  "mapping_revision": "mapping-example-1",
  "proposed_by": "actor-example",
  "proposed_at": "2026-09-18T10:12:00Z",
  "items": [
    {
      "capability_code": "COMM.SUPPLIERS",
      "capability_revision": "0.2.0",
      "delegation_level": "A",
      "source": "override",
      "constraints": {}
    }
  ]
}

The export envelope pairs this payload and hash with acceptance/lifecycle evidence. Re-exporting unchanged frozen content must reproduce the same hash. Reconciliation must consume the exact pinned content, not reinterpret old policies using current defaults.

10. Mass requests and onboarding

10.1 Partner-initiated mass requests

1. An authorised partner administrator selects eligible client relationships, a preset and proposed overrides. The system previews the resolved changes without exposing client data unavailable to that administrator.
2. Create an independent pending policy/request for each tenant. A campaign ID groups delivery and reporting only; it grants no cross-client authority. For 300 clients, there are 300 independently accepted or declined requests.
3. Send each client a request-specific link with partner identity, purpose, requested changes and expiry. Link tokens identify and constrain the request; they are not consent or tenant credentials.
4. Require sign-in and server-side verification of the client's permission to accept delegation for the exact tenant. Show the current and requested matrix, visibility boundaries and retained client-only decisions.
5. The client accepts, declines or adjusts configurable rows. Adjustments produce a new frozen candidate/hash, reviewed and accepted as that exact candidate. Preserve the original request and resulting decision.
6. Activate accepted policies and reconcile grants. Declined, expired or unanswered requests grant nothing new. Existing accepted access remains unless independently reduced or ended.
7. Show per-client status: sent, awaiting review, declined, expired, accepted awaiting activation, active or activation failed. Delivery/open events are never treated as acceptance.

Support cancellation, bounded reminders and idempotent delivery/reconciliation. A resubmitted request cannot reuse an acceptance for different content. A stale request must be rebased against current policy before confirmation. Request delivery metadata can live in a generic request/campaign subsystem; it does not duplicate the canonical policy or grant ledger.

10.2 Client onboarding

Use the same policy lifecycle during onboarding. The partner may suggest answers, and the client may select a preset or customise the matrix. Display partner identity and delegation separately from general account creation. Before activation, authenticate the client actor and verify their authority over the newly established tenant.

Until acceptance and successful activation, the relationship remains pending and the partner has zero tenant authority. Never fall back to Data entry. If the client skips delegation, onboarding can continue without delegated partner service where the product permits it. A new partner must obtain fresh acceptance; prior consent to another organisation cannot be copied.

11. Automated partner operations

Automation is a primary benefit: clients can delegate routine work once, and the service can then carry out that work consistently within the approved boundary. Examples include permitted data ingestion, account mapping, report preparation and supplier follow-up. A-level automation prepares proposals and waits for client approval; C-level actions remain unavailable to the partner service.

Automation must use an attributable, explicitly authorised execution identity. Do not impersonate a partner employee, borrow their session or use a broad service credential to bypass delegation. Bind the automation identity and job to the partner, client assignment and policy provenance using the platform's governed identity mechanism.

Every run and consequential retry checks current Atlas authorization, applicable operational approval and TrustGate. Scheduled work stops or is cancelled when access is reduced, membership/assignment becomes invalid or the relationship ends. Job records preserve the initiating identity, executing identity, target, policy/grant evidence, approvals and outcome. Delegated authority is not itself an instruction to schedule every possible operation: service configuration, purpose, timing and communication limits must also authorise the job.

12. Client and partner experience

Preserve the supplied settings prototype's grouped matrix, three preset cards, P/A/C legend, visible platform locks, per-row change indicators, sticky confirmation bar and version history. The prototype is an interaction reference; its local JavaScript constants and checkbox are not security controls.

12.1 Updated language and behaviour

Element	Required language or behaviour
Page title	Partner access
Intro	“Choose what [Partner firm name] may do in your [Product name] account. Every change is versioned. You can reduce partner access immediately. Increasing partner access requires your confirmation.”
P legend	“Partner may act directly.” Supporting text: “Required checks and platform rules still apply.”
A legend	“Partner proposes, you approve.”
C legend	“Client only.” Explain that separately selected visibility may still apply.
Visibility row	“Choose which data your partner can view.” Show the actual data boundary before confirmation.
History	Partner access history with version, effective time, author, accepting actor where required, summary and downloadable evidence.
Approval areas	Separate Access changes awaiting approval from Partner proposals awaiting approval.
Change badges	“Reduced access” and “Increased access,” including visibility and constraint changes.
Reduction action	Apply reduced access; show the resulting version and enforcement status.
Increase action	Confirm increased access; bind the server-verified acceptance to the displayed version/hash.
Mixed changes	Offer Apply reductions now separately; explain that remaining increases await confirmation.
Locked rows	Explain the specific platform rule. Remove “Part of the relationship” locks that implied always-P data authority.
Automation explanation	“Your partner's service can perform permitted routine work automatically. Actions requiring your approval will wait for you.”

Load rows, presets, allowed levels and constraints from the governed Atlas API. Do not compute ceilings from Full service defaults or decide acceptance using preset ordering. Reset confirmation whenever proposed content changes. Provide keyboard-accessible controls, full text labels alongside P/A/C and non-colour-only change indicators.

Summary cards distinguish the effective policy from a pending proposal and show activation failure or suspension explicitly. A reducing version identifies the client who applied it rather than inventing a new acceptance ceremony. History must not contain impossible examples such as a formerly P publication permission under rules that have never allowed P.

12.2 Partner views

Provide a read-only effective matrix per client, separate pending access requests, a client assignment list, an operational proposal queue and automation status. Portfolio rollups can show preset usage, explicit overrides and blocked work; they must respect each viewer's partner role and client assignment. Counts and campaign status do not themselves confer tenant data access.

13. Migration and implementation acceptance

13.1 Moving from v0.1.0

• Preserve the original document and historical decisions. This revision replaces the specification, not historical evidence.
• Replace DATA.MAPPING with DATA.ACCOUNT.MAPPING and DATA.FACTOR.SELECT. Do not silently grant methodological P authority based on an old Data entry default. Present the split explicitly; obtain acceptance wherever a new mapping broadens authority or old intent cannot be established.
• Replace implicit P floors with explicit reviewed items. Do not treat a pre-existing relationship or old UI default as evidence of consent to all client data.
• Resolve actual historical permissions and consent before migrating grants. Where authority cannot be established, suspend the unsupported derived access and request authenticated confirmation.
• Store all resolved rows and pinned rule revisions. Reconcile into source-attributed grants without overwriting unrelated grant history.
• Update authorization decision evidence to preserve actor_role_id; historical records missing this field must be marked as incomplete rather than assigned invented provenance.

13.2 Required verification scenarios

Scenario	Expected result
Pending invitation or unsigned onboarding matrix	No tenant reads, writes or automation authority.
Same role requested in a different tenant	Delegation-derived grant does not authorise it.
P permission requiring TrustGate	Execution blocked until required checks pass.
A proposal without client approval	No live mutation or external side effect.
Proposer attempts self-approval	Rejected, even with a second role.
Payload or target version changes after approval	Old approval cannot execute the changed action.
Advisory changes to Data entry	Account-mapping increase is detected despite other reductions.
Visibility widens without a P/A/C change	Client acceptance required.
Client immediately tightens or suspends access	New version/event evidence retained; stale grants, caches and queued work cannot execute.
Partner member leaves or changes internal role	Affected derived grants revoked; unrelated grants preserved and identified.
Concurrent policy edit or reused acceptance token	Stale candidate rejected; exact current content must be reviewed.
Reconciler retry or partial failure	No duplicate grants or premature activation.
Registry adds a permission	Existing policies do not gain authority silently.
Audit follows an executed action	Exact grant, policy hash, client decision and required TrustGate evidence remain traceable.
Export is repeated	Identical frozen content produces the same canonical bytes and hash.

Before implementation, confirm actual Atlas role mappings, membership/automation identity contracts and supported resource filters. A future assurance-oriented preset can be considered separately; it must not mean unavoidable view-everything access.

14. Change log

Version	Date	Change
0.2.0	2026-09-18	Separates client intent from canonical Atlas grants; introduces normalized versioned policy records, authenticated acceptance, exact grant provenance, membership-based reconciliation and governed automation. Removes data-access floors, separates mapping from methodology, treats presets as templates, distinguishes access and operational approvals, and modernizes settings language and workflows.
0.1.0	2026-09-18	Initial capability matrix, presets, onboarding, maker–checker and audit concept.