This draft describes the intended Arc sharing boundaries. The current source marks shared chats and composers as unfinished. Audience checks and context exclusions need release-build verification before publication.
Organising and sharing have different effects
Adding two chats to one project lets you organise the same task and reuse selected instructions and files. It does not give the reader of one chat access to the other chat.
Project context used in a shared turn must be authorised for that turn’s audience. Access held by one participant cannot make private material available to everyone. The interface identifies excluded context without revealing its contents.
A shared research chat does not expose the project
Suppose your transport project contains a source-research chat, a private planning chat, and a reference file. You share only the source-research chat with a colleague.
The colleague does not gain access to the private planning chat or the project merely by receiving that share. The reference file also requires its own checks before its content can be used in the shared conversation.
If required context is excluded, the shared answer can have less context than your personal conversation. Check the reported exclusion before assuming the answer used the whole brief. Identify material the audience is permitted to receive before adding it to the shared discussion.
Co-writing does not combine permissions
One user submits each turn. Model and tool operations use that person’s current authority, tool eligibility, and limits. Other contributors’ permissions are not combined with theirs.
For example, your colleague can help draft a question about a project file, but their ability to read it cannot authorise a turn submitted by someone who lacks access. The returned content must also be suitable for the receiving audience.
The same rule applies to prior-work search. A participant’s access to an earlier conversation does not make its title, snippets, or content available to a shared chat. Search checks both the source and receiving audience.
Intended audience-change checks
These are required sharing boundaries. The unfinished collaboration controls must be checked against the release build before this page can be treated as a description of available interfaces.
Adding a participant requires the retained conversation context to be checked for the new audience. Private context must remain protected rather than being exposed through earlier messages, previews, or live updates.
Removing a participant blocks subsequent protected reads and writes, including live updates. It cannot recall material already delivered. Changing an audience does not grant review or publication authority.
A chat project is separate from a workspace
A project groups chat context for a user. It does not establish Vantage workspace membership or grant access to workspace data. A workspace’s grants do not automatically expose personal chats or project files either.
Finding earlier work does not change its owner or grant new access. It also does not turn that work into project memory or transfer an Arc artefact into Vantage automatically.
For the sharing procedure, use Share and co-write a chat. To choose what later project conversations can use, follow Use project memory and reference material.
