Built like it has the keys to your business.

Runs, drafts, decisions and mode changes are recorded with timestamps, and administrative changes are written to an audit log with the actor and the before and after state. Server code writes these records. The database does not lock them against change.

Every draft has a state: draft, needs review, approved or rejected. A decision is recorded once, with who made it and when. A system runs in shadow mode first, and it cannot become the primary runtime until a passing shadow comparison is recorded.

Approvals, configuration changes and Results Brief reads go through routes that require an authenticated NigelBuilds operator. Unauthenticated calls and malformed ids are refused.

Row-level security is switched on for the Business System tables with no public policy, so browsers and public API keys cannot read or write them. Only server code holding the service credential can, and that code applies the workspace scope.

Business Systems write drafts. Customer sending is not enabled today. The cloud runtime has no send path for these systems, and approving a draft records a decision but sends nothing. Customer-facing sending or other mutating actions would need to be in the written scope, technically configured and approved first.

One environment switch stops every Business System for every client at its next run. Runs report that the switch was on and do nothing.

Each scheduled run has a unique key per client, system and time window, and each draft is unique per source message and follow-up step. A rerun or a race between two workers does not create duplicates.

A permanently failed job becomes one deduplicated incident with an audit event and a blocker card. Repeat sightings update the same record instead of creating new alerts.

Business Systems for every client run on shared NigelBuilds cloud workers and one managed Supabase database. Each client is a workspace. Every row a system reads or writes carries that workspace id, and every query and write is scoped to it. This is logical separation. NigelBuilds does not run a separate server, virtual machine or container for each client.

Each Business System starts with the narrowest permissions the agreed workflow needs. Moving money, changing amounts, deleting records or email, changing passwords, users or security settings, and giving medical, legal or financial advice are not built into any system and are blocked on every plan.

A client's workspace can be paused at any time. Queued work is held instead of run, each hold and release is recorded once, and the work resumes when the workspace is active again.

Mailbox connections use IMAP in read-only mode. They examine folders and peek at message bodies. They do not mark mail read, move it, label it or delete it. Calendar and document access are not built.

A failed step is retried with growing delays, up to its attempt limit, then marked as a dead letter and held for review. Work stuck mid-step for more than 15 minutes is returned to the queue, or dead-lettered if its attempts are spent.

Mailbox credentials are held as server environment secrets and referenced by name. They are not stored in the database, not shipped in client-side code and not written into run records. A client revokes access by changing the mailbox password or removing the connection at the provider.

Production work uses business API accounts, never personal chat subscriptions. The Business Systems available today do not call a model provider, so this rule has no live traffic to prove it yet.

Where the platform stores an OAuth token, it is encrypted at rest with AES-256-GCM using a key from the server environment. No client connection that stores tokens is live today, so this is built but not yet exercised by a client.

A written policy, covered by automated tests, routes each event to NigelBuilds' operations responder first. The owner is told directly only for confirmed or high security impact, data loss, real-money impact or a multi-customer outage, and otherwise through an action list. Production delivery of these notifications is not yet recorded as proven. This is not a staffed service, and NigelBuilds does not offer 24/7 monitoring by a person.

Documented backup and restore tests for client workspace data do not exist yet. NigelBuilds will not describe backup coverage it cannot show.

On termination NigelBuilds helps export service-generated information that is technically available, and removes the access it controls. This is done by hand. Automated export and deletion tooling is not built, and there is no fixed export format.

Database policies that enforce the client boundary independently of application code are not in place. Today the boundary is enforced in server code and covered by automated tests.