Overview
Existing database write proposals let an agent suggest changes without receiving raw SQL or write credentials. Synapsor reads external rows through governed mappings, records evidence and query audit, creates a Synapsor review branch with a proposed row diff, and waits for approval or policy before a trusted worker applies the change to the external database.
Synapsor does not need direct write access to your application database. The recommended setup is proposal-based: an agent invokes a reviewed capability, Synapsor reads scoped external context, records evidence, stages a Synapsor review branch/proposal, and waits for approval or deterministic settlement.
Two credentials, two phases: Synapsor reads with the least-privilege source credential. It does not use that read-only connector to update Postgres or MySQL.
After approval, your own backend worker uses a separate write credential to apply the approved proposal. That worker owns the database transaction, affected-row checks, idempotency guard, and conflict handling.
A trusted worker running in your app environment polls approved external DB proposals, validates the mapping, builds parameterized SQL, applies the change in a database transaction, and reports applied, conflict, or failed back to Synapsor.
The model never produces SQL. Synapsor produces the proposal, the worker uses allowlisted columns and primary-key/tenant/conflict guards, and your existing Postgres/MySQL database remains the source of truth.
What Synapsor does not do
Synapsor does not create physical branches inside customer Postgres/MySQL databases, perform direct external database merges, give the model write credentials, let the model choose tenant_id or arbitrary rows, or apply public-demo writes to customer data.
What Synapsor does
Synapsor reads external rows through allowed mappings, binds tenant/user/object scope from your backend, records evidence and query audit, stages a proposed row diff, stores a Synapsor review branch/proposal record, approves/rejects/auto-approves by policy, sends approved writeback intent to a trusted worker, and records writeback result, conflict, and replay metadata.
Flow: external DB read-only -> evidence/query audit -> Synapsor review branch -> proposal diff -> approval/policy -> trusted worker -> external DB update or conflict -> replay.
Conflict behavior
If the external row changed after Synapsor recorded evidence, the trusted worker should reject the writeback as a conflict and return the updated row/version for review. Synapsor records the conflict in the proposal and replay record.
External writeback flow
Read-only is the first path. Proposal writeback adds a Synapsor review branch and worker-controlled apply step after review.
Calls a Synapsor proposal capability rather than a raw database update tool.
Synapsor reads allowed rows/columns through trusted SESSION scope, parameterized queries, and a read-only credential.
The capability records the rows, policy chunks, tenant binding, and query fingerprint used.
Synapsor stages the proposed external row diff, idempotency key, approval state, and writeback intent.
A human or deterministic settlement policy marks the proposal approved for writeback.
Your worker applies parameterized SQL to Postgres/MySQL with a separate write credential and reports the terminal result.
Synapsor records external commit metadata so the run remains inspectable later.
Developer notes
- Do not give Synapsor Cloud a write credential for the existing app database in the normal path.
- Display external proposals as Synapsor review branches, not as branches inside Postgres/MySQL.
- Approve proposals before the worker sees them as ready_for_writeback.
- Use primary-key, tenant, and optional version/updated_at guards on every worker update.
- Treat affected_rows = 0 as a conflict, not a success.
- Retry only with proposal idempotency keys so a network failure cannot double-apply.
- Disable the source or mapping to stop future external reads/writeback while preserving audit history.