Sharing and Governance

Sharing in xysq is consent-first: you pick exactly what crosses and who sees it. Nothing leaves your context lake unless you send it or approve it, and everything that does can be revoked.

​

What you can share

Two units, both out of your personal graph:

• A page. One distilled page, for example the one holding your deployment runbook.
• A source. One captured item, byte for byte, as you pushed or uploaded it.

Sharing a whole graph is not a share. If a group of people needs the same context, give them a team graph instead: membership does the authorizing, new members get everything the team holds, and leavers lose it.

​

Who you share with

One person, by email. They don’t need to be on your team, and they don’t need an xysq account yet; the share attaches to their address and resolves to them when they sign in. Each share names exactly one recipient, so sharing one page with three people is three shares, revocable one at a time. A share feeds the recipient’s AI tools too, not just the human. Once a share is active, their agents recall your shared context through pull_context like any other context, with the grantor attached to each item so it is always clear where it came from.

​

What a share can do

Every share is view-only. There is one access level, not a menu: the recipient reads and recalls what you shared, and cannot change it, tag it, or delete it. Contributing back is what a team graph is for. Shares are live, not snapshots. The recipient sees the current version of what you shared until you revoke, the same way a shared doc works. Nothing is copied into their lake, which is also why revocation is instant.

​

Agent-proposed shares

Your AI tools can propose a share on your behalf with the share_context MCP tool, giving a page slug, a captured source id, or a free-text query (the engine resolves the query to at most five of the most relevant pages). Proposing is all a tool can do. The call creates pending proposals, and nothing crosses until you approve them in the app under Vault > Sharing. You see a preview of exactly what would be shared before you decide. A share you create yourself in the app is active immediately: the click is the consent. Only the proposals a tool made wait for approval.

​

Revocation

Any share can be revoked at any time, by you, in the app. Revocation cuts off both the human and their agents. Because shares are live rather than copied, there is no stale duplicate of your content left behind in their lake.

​

Every change is auditable

Governance here is not a policy document; it is how the engine writes:

• Provenance on every fact. Quote, source, timestamp, lineage. Every fact is labelled stated or inferred, and a stated fact that cannot quote its source verbatim never becomes a fact at all.
• Code-owned history. Changelogs are composed by the server and byte-checked. The model cannot edit its own trail.
• Every change is a commit. Each graph lives in a version-controlled vault, so a page’s earlier wording is still on disk and every change is a diff.
• An activity trail per graph. Every push, pull, distill, share, and membership change on an agent or team graph lands as a row anyone with reader on it can read, stamped with who acted and which surface they came through (the app, MCP, the SDK, the background worker, or a channel like WhatsApp).

​

Access control, summarized

• One lake per user or team; graphs inside it are the unit of access.
• Agents reach only the agent graphs their key was granted, at the level it was granted. An agent key can never reach your Personal graph, and your personal key can never reach an agent graph.
• Shares are explicit, previewed, approved by you, and revocable.
• Deleting a source stops it being served end to end: the source, the retrieval index, the facts it grounded, their quoted evidence, and the lines those facts put on your pages. Your vault’s version history still holds what a page used to say; see Ownership for exactly where that line falls.

​

Deployment direction

For teams that need context inside their own boundary, bring-your-own-drive storage (your graphs mirrored to a drive you control) and private deployment are what we are building next. Direction, not shipped; talk to us if this is a requirement for you.

​

Where to go next