Overview
Important: branches are real database branches for Synapsor-native hosted data. When a workflow uses an existing external Postgres/MySQL source, Synapsor does not branch that external database.
External source workflows create a Synapsor review branch for proposal state: source row references, evidence, query audit, proposed field changes, approval state, replay metadata, and trusted writeback intent. The external source remains unchanged until a customer-controlled trusted worker applies an approved writeback.
Hosted database-scoped keys are pinned to one runtime branch.
Operator and trusted control-plane flows can create, diff, merge, or drop branches.
Explicit branch names are user-defined. Auto-created proposal branch names are returned by Synapsor in the proposal/capability response and are visible in synapsor_agent_write_proposals.
Agent write proposals use Synapsor-native branches or Synapsor review branches to show the diff before production-visible state changes.
Green-lane proposals can be auto-approved, committed, and merged only when a deterministic settlement policy explicitly allows AUTO COMMIT and AUTO MERGE. Yellow, red, conflicting, or disabled-policy proposals stay staged for review.
Branch review flow
Synapsor-native branches let hosted-data writes stay isolated until a reviewer or deterministic settlement policy decides what can move to Synapsor main. External database workflows use Synapsor review branches instead.
Production-visible Synapsor-native state stays unchanged while the proposal branch is evaluated.
Synapsor creates an isolated branch for the hosted-data proposal or cleanup workflow.
A write proposal records target rows, evidence lookup records, reason codes, and the proposed diff.
Reviewers inspect row-level changes, evidence, and proposal metadata before production-visible state changes.
For Synapsor-native targets, a green settlement policy can auto-approve, auto-commit, and auto-merge.
Yellow, red, ambiguous, or conflicting proposals remain staged for human approval or rejection.
The branch/proposal/evidence history remains inspectable after merge, rejection, or cleanup.
Developer notes
- Run destructive cleanup on a branch first.
- Review diffs before merging to main.
- Allow auto-merge only through deterministic settlement policies with explicit AUTO COMMIT and AUTO MERGE.
- Use Synapsor review branch language for external Postgres/MySQL proposals; do not claim Synapsor branches or merges the external database.
- Keep non-approved proposal branches staged until a reviewer decides.
- Drop abandoned branches to release quota.
- Keep branch switching unavailable to database-scoped app keys.