Sharing conversations and variants

The sharing API grants view or edit access to a conversation/variant. Targets can be an individual user, group, organization, unit, or team.

Only the conversation owner can create, change, list, or remove its shares.

Permission boundary

These labels do not automatically grant every downstream action. Artifact download, VM launch, deployment, billing, secrets, and organization administration can have separate owner and entitlement checks. Test each required action with the recipient’s own session.

If the same conversation reaches a user through several shares, the accessible-list response chooses the higher of view and edit.

Target rules

• Direct user shares are resolved against organization membership.
• Groups, units, and teams must belong to the relevant organization.
• Organization shares reach current organization members.
• Membership changes can change effective access without editing the share itself.

Do not use a broad organization share when a user or team share is sufficient.

Safe sharing workflow

1. Confirm the conversation ID and its owner.
2. Confirm the recipient target and current membership.
3. Start with view unless editing is required.
4. Create one share and inspect the returned target and permission.
5. Sign in as the recipient and test allowed and denied operations.
6. Remove or reduce access when the task ends.
7. Refresh the recipient session and repeat the denied-path test.

Do not assume an email or in-app notification was sent. Communicate through your approved channel without including tokens or private artifact URLs.

Collaboration behavior

edit is authorization, not conflict resolution. Before two people change the same conversation, agree on who owns the next recipe revision and compare the normalized output with the full chat. A rebuild should be tied to a specific reviewed recipe rather than whichever edit arrived last.

Review and offboarding

Periodically inventory:

• direct shares;
• broad group, unit, team, and organization shares;
• stale memberships that still confer access;
• resources whose original owner left; and
• recipient access to old builds, downloads, and VMs.

Removing a share does not necessarily delete a copy already downloaded by a recipient. Handle exported artifacts through your data-classification and retention policy.