Share policy rulesets with colleagues, without asking anyone for access

How to create a team, invite colleagues by email, and have one shared ruleset library — set up by asking your assistant, with nobody at Jaxon involved.

You have used DSAIL to turn a written policy into rules a program can check, and now a colleague needs the same rules. Two people at the same company sign in and each gets a workspace of their own — the right default for strangers and the wrong one for colleagues: the second person cannot see the first one's work. A team fixes that, and you set one up yourself by asking.

Everyone in the team checks against the same compiled rules, so they all get the same answer every time — which is the point of sharing the library rather than each person rewriting the policy.

Ask for a team

"Create a team called compliance."

You administer it. It starts empty — your own rulesets stay in your own workspace, and nothing of yours is shared by creating it.

Invite the people who should see it

"Invite bob@acme.example to the team."

You get a single-use link back. Pass it on however you like — email, chat, in person. The service sends no mail of its own, which is deliberate: there is one less thing to configure and one less place your colleagues' addresses are kept.

The person you invited opens the link and signs in as that address. A page then names the team and who invited them, and nothing changes until they choose Join. Anyone else opening the link is refused, so a forwarded link is worth nothing. It works once, and only in the browser it was opened in.

Joining puts them in the team: their assistant works in it from then on, so they can list, load, save and approve everything in it straight away. The page they land on says so, and their own workspace stays where it was, one switch away (see below).

Put your existing work into it

"Copy cap-policy into the compliance team."

That is how a new team gets its first library. It is a copy: the original stays exactly where it was, so nothing is lost if you change your mind.

Two details worth knowing. The revisions your ruleset cites come with it, so you can still diff it against its parent. Recorded approvals do not — an approval is one person's sign-off inside one workspace, and reproducing it elsewhere would put their name against a decision they were not asked to make. A copy arrives unapproved, on purpose.

Work in one place at a time

"What workspaces am I in?" · "Work in the compliance team." · "Go back to my own workspace."

The workspace you are in decides what you see and where new work is saved. Your choice sticks between sessions.

It does not decide who pays. Every check you run is billed to you, whichever workspace you run it in.

Who pays

A team is for sharing, not billing. It has no allowance or subscription of its own, and creating one adds nothing to yours. Each member's checks are billed to that member: the same allowance, and the same upgrade, in a team's workspace as in their own. An API key bills the person who issued it. There is no per-seat charge, so adding people to a team adds nothing to anyone's bill.

When somebody leaves

"Remove Bob from the team."

Their access ends on their next call, including through any API key they issued for that team. What they saved stays with the team — removing a person does not remove their work.

Only an administrator can invite, remove or promote. You can make somebody else an administrator at any time, and a team can never be left without one.

From a terminal

Everything above works the same from a coding agent, with one extra step the first time:

dsail login          # sign in, so what you do can be attributed to you
dsail team create compliance
dsail team invite team-abc123 bob@acme.example
dsail copy cap-policy --to compliance --from personal
dsail workspaces

dsail login exists because membership is about people, and an API key names a workspace rather than somebody who can be asked. Your key is untouched by signing in and keeps working — it is what the programs you write should carry, since those run with nobody behind them.

What a team is not

It is membership plus one administrator role, and that is the whole of it. There is no per-ruleset sharing, no read-only member, and no groups inside groups: if a ruleset is in the team, every member can read it, save over it and approve it. If you need a narrower boundary, make a second team.