Sharing and Governance

Sharing in xysq is consent-first: you pick exactly what crosses, who sees it, and at what level. Nothing leaves your context lake without your explicit approval, and everything that does can be revoked.

​

What you can share

Three sizes of grant, from small to large:

• A page. One page from a context graph, for example the page holding your deployment runbook.
• A graph. A whole context graph, for example your team’s product context.
• Everything. Your full lake, for the people you trust completely.

​

Who you share with

• One person, by email. They don’t need to be on your team.
• Your whole team. New members get access when they join; leavers lose it when they leave.

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.

​

Access levels

• Read-only (the default). The recipient sees and recalls your content but cannot change it.
• Editable. The recipient can contribute changes, which flow through the same gates, ledger events, and review queue as your own. No one, including you, gets an ungated write path.

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.

​

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 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.

​

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. Inferred claims are labeled and need multiple citations.
• 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 you can diff any change, see who or what made it, and revert.
• A review queue for judgment calls. New entities, quarantined claims, and conflicts with human-written text wait for a human instead of applying silently. See Corrections.

​

Access control, summarized

• One lake per user or team; graphs inside it are the unit of access.
• Agents read from the graphs you grant them and write only to their own. An agent key can never reach your Personal graph.
• Shares are explicit, previewed, approved by you, and revocable.
• Deleting an item scrubs it end to end: ledger, history, vectors, and archives.

​

Deployment direction

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

​

Where to go next