Try changes separately, review the difference, and merge when ready.
Run a query against the current graph, an earlier commit, or a branch containing a proposed change. Each plan or what-if scenario can have its own branch. Ask the same questions of each version, compare the answers, and decide which changes to adopt.
History remains useful after things change. Plans become queryable before you commit to them.
Create a branch to develop a change separately from shared work. People and agents can update data, documents, rules, or use cases there. Unchanged content is shared, so a branch does not require a complete second copy of the workspace.
Commits record successive versions. Keep related updates together so a transaction publishes them as one change.
Compare a proposed branch with its starting point or target. Review the changes and their authors before merging. When branches have changed the same knowledge, resolve the conflict explicitly.
Pass the branch to the next person or agent to do their part, then hand it on again. Continue through as many steps as the work needs, including returning to an earlier participant for changes. Each contributor builds on the data, documents, and work already gathered there.
For example, an agent drafts a purchase order, the buyer checks quantities, and the supplier adds delivery terms. The branch can return to the supplier if a date needs changing.
Before publication, SHACL validation must pass and every party required by the workflow must sign off. A failed check or missing agreement keeps the proposal open.
There is no central approver bottleneck at every transition. Work passes directly to the next authorized participant; the process determines whose contribution and sign-off are needed. In the order example, the buyer and supplier agree the completed result.
The target branch determines the checks required for publication. Data validation explains how those checks work, including the distinction between exploratory work and shared production data.
See the branching guide for commands and backup and restore for recovery.
Developer reference
Reads pin a branch HEAD or immutable commit ID. Merkle-addressed snapshots share unchanged content.
A three-way merge computes base → source and base → destination, constructs the combined graph, then executes destination validation. Disjoint writes can still violate one SHACL constraint. Commit ancestry and graph validity are separate checks.