Organizations & access

On Sangam-Git, repositories belong to an organization, not to a person. This one decision shapes everything about how teams and access work — so it's worth understanding.

Why the org owns the code

If a repository belonged to whoever created it, losing that person would mean scrambling for access. Instead, the organization owns its repositories as an entity. The code belongs to the team. Removing a member never deletes a repo, and the last owner can't be removed — so a project can never be orphaned.

You create your first organization when you sign up, and you become its first owner.

Roles

Members of an organization have one of three roles:

• Owner — full control: billing, members, settings, and every repository. Manage the org itself.
• Admin — manages repositories and members, but not org-level ownership.
• Member — a regular teammate; sees the repositories they're given access to.

Owners and admins manage the org. Add members under the organization page.

Repository access

Beyond org roles, each repository has collaborators with a specific level of access — set under a repo's Settings → Collaborators:

• Write — push and merge.
• Read — view and clone.
• Browse-only — read in the browser, but no clone. Perfect for PMs, QA, or contractors who should see the code but not take a full copy.

Who can see what

Access is scoped by role, and search respects it:

• Owners and admins see all of the organization's repositories.
• Plain members see only the repositories they actually collaborate on.

When you search across an organization (repositories and code), you only get results from repositories you're allowed to see. Access control isn't bolted on to search — it's built into it.

Agreements (NDA / IP assignment)

Some teams must ensure every collaborator has accepted an NDA or IP-assignment agreement before touching the code. Sangam-Git supports this:

1. Under the org's Agreements, add your agreement text (have it drafted by counsel — you provide the wording; use {ORG} for your organization's name).
2. Turn on "require members to accept before accessing code."
3. Now anyone opening the code must read and accept first.

Each acceptance is recorded as evidence: who accepted, which version of which document, when, from which IP, and the SHA-256 hash of the exact text they signed. Editing an agreement bumps its version, so everyone re-accepts the new text. You can view all signed acceptances as a table.

Business identity (KYC) and verification

An organization can fill in a profile — display name, team size, country, billing email — as it grows; none of it is required to start. Business-identity (KYC) fields are there for later, when you need to verify your organization, require verified collaborators, or issue GST invoices. What's stored is kept to the minimum and encrypted. Verification is a manual review today; once complete, your org shows a Verified badge.

The takeaway: the organization is the owner and the unit of trust. Roles and per-repo collaborator levels decide who can do what, agreements gate access with real evidence, and search never shows anyone a repo they shouldn't see.