The boundary between a proposal and an action
AI can prepare a strategy, message, creative variant, segment or explanation. Before an external action, deterministic code verifies the user, project, permission, approval policy, budget and idempotency. The action receives its own lifecycle and an auditable result.
When a proposal changes after approval, the earlier permission does not silently apply to the new version. The user approves the exact variant that will be executed, and the system preserves the connection between proposal, decision and the external platform’s actual response.
Money is calculated by code
Advertising spend, external AI and API service expenditure, and the SintaSix subscription remain separate. An estimate is not presented as a final charge. Retries, fallback attempts and refunds are recorded independently so the cost can be reconciled.
Data belongs to a project
Server-side authorisation applies to every protected read and write. One project’s context must not enter another through the interface, search or AI. Connection credentials are not sent to the browser and are excluded from model context unless strictly required.
The audit trail records consequential changes and execution attempts without becoming a new source of exposure. Technical identifiers, time, operation class and a safe error description are usually sufficient; credentials and unnecessary personal content do not belong in operational logs.
A stop control must actually stop work
The emergency stop blocks new public and spend-bearing jobs and attempts to pause supported external processes. The interface reports the outcome for each channel; resuming requires a separate confirmation.
An internal block and an external platform acknowledgement are distinct states. If a channel has not confirmed the pause, SintaSix should say so plainly and continue bounded verification rather than create a false sense of safety.
Control should be visible
Safety must not exist only in administrative documentation. Before a consequential action, the user sees the goal, project, material, amount and implications; afterwards, they see either the verified outcome or a clear reason the work did not complete. Rigorous architecture can support trust without making the simple interface feel technical.