Architecture and data handling

Repository data flow

• ✓Repository files originate at your code host; index jobs and on-demand reads bring source into Coop.
• ✓We index repository metadata, ownership graphs, and change history — not a full copy of the tree onto every laptop.
• ✓Org admins configure supported integration connections and scopes. Actual access depends on the deployment mode and vendor permissions.

Index jobs use a transient shallow clone on the server to build indexes, then delete the returned clone through the job cleanup path. Process death or early clone failure needs separate cleanup. Persistent storage includes search indexes, graph metadata and source chunks, together with synced chat history — the same zero-clone model described in Introducing CoopAI. Clearing local chat does not guarantee deletion of synced server history or backups. Retention and deletion must be qualified for the deployment.

How inference is routed

• ✓Server-side model router.
• ✓Application request controls; provider retention requires verified account settings and agreements.
• ✓Server operators configure supported provider keys. Customer-key routing per organization is not available.
• ✓Prompts and source excerpts are sent for inference; provider training terms require account-specific verification.

Supported model providers process prompts for inference. Provider-side retention depends on the actual account settings and agreement. More detail: Security architecture docs.

Controls

• ✓SAML SSO (Enterprise)
• ✓Role-based admin vs developer access
• ✓Audit log for integrations, invites, and API keys
• ✓Scoped integration access (channels, projects, repos)

Subprocessors

Exact subprocessors depend on the customer's chosen model providers and connected tools. We will send a current list on request.