Projects / Sebastian Bridge
The AI can propose. It cannot confirm.
My company's CRM is shared by dispatchers, managers and a credit team. There is no sandbox. Here is how an AI assistant gets to help with it without ever being able to hurt it.
The strongest safety control is the one that structurally cannot be bypassed. Every rule below is enforced in code and tested, not written in a prompt. Widening any row requires a plan, an independent audit, a written sign-off, and an amendment to the project's constitution. Withdrawing a permission requires none of that.
Write surface
Exactly one service on the box can send a non-GET request to the company CRM. The CRM app itself (WaterDex) has the write code deleted, not disabled, and a CI test that fails if any of it comes back.
Tables
One: meetings. No company or contact writes exist.
Endpoints
Update for reschedules, outcomes and cancels. Create for new meetings only. Upsert and delete are absent by design.
Fields
Per kind, never one shared pool. A reschedule may touch start, end and a description note. An outcome may touch result, status and notes. No single proposal can reach every field.
Values
Closed picklists where the CRM publishes them, and a one-value allowlist where it doesn't. Five near-miss spellings are named in code as unwritable.
Records per request
One. Every write is its own approval.
Authorization
A tap on a page showing the complete payload. The AI can propose; it has no route it could call to confirm.
Rate
Per kind, per rolling 24 hours: five reschedules, ten outcomes, five cancels, two creates. Never pooled, so a busy day of one kind can't refuse another.
Gates
A master environment switch, a per-kind switch for later-authorized kinds, and an explicit live flag that defaults to false. Clearing the master switch stops everything, no discussion required.
After every write
The record is read back and compared. The result page reports what the CRM now holds, not what the API answered. Mismatches are shown loudly and never auto-corrected. Writes are never retried.
Audit
Every attempt, including refusals, is logged with payload, mode and verification result, and backed up nightly. Writes appear in the CRM as me, so validation is the bridge's job.
Why it's built this way
- A wrong write in a shared CRM dispatches a technician or runs someone's credit. The cost of asking is zero.
- Making inputs more unique can silently disarm a duplicate guard. Adding a field to a safety-critical payload is never a local change.
- A detector nobody looks at is a detector nobody has checked. Every automated decision gets a human-readable surface.
- Granting is gated; withdrawing is not. The kill switch needs no plan.
Built August 2026 as part of the Sebastian Bridge. The CRM's own code retains a three-layer test that fails the build if any write path reappears.