Governance isn't a disclaimer here. It's the roadmap - and we label it honestly.
Every claim below is labelled with its real current status: available now, manual control, planned, pilot-only, or required before activation. Nothing here is overstated as a live automated capability unless it genuinely is one.
Client separation Planned
The intent is that every client receives a separate workspace identity and segregated data environment, so no client can access another client's data. This structural separation is planned and required before any paying client is onboarded - it is not yet independently verified as implemented.
Access controls Manual control
Permissions are intended to be granted per client, system, workflow and action type - never globally - following the permission ladder (Observe, Analyse, Recommend, Draft, Request approval, Execute, Verify, Report, Escalate). Today, enforcement of this ladder is a manual, human-supervised control, not an automated platform gate.
Data retention Planned
Client data retention terms will be agreed at onboarding and enforced per engagement. The formal retention and deletion process is planned and required before any paying client engagement begins.
Encryption Required before activation
Encryption in transit and at rest across storage and communication layers is a requirement we intend to meet before handling any real client data - it is not yet independently verified as implemented in this staging build.
Model-provider handling Required before activation
Routing model calls through approved providers under standard data-processing terms, with client data never used to train third-party models, is a requirement that must be contractually and technically confirmed before any paying client engagement - not yet independently verified as implemented.
Audit logs Planned
The intent is that every execution records an initiating user or agent, a timestamp, a scope, and a result, in a log that standard users cannot edit. Immutable, tamper-evident audit logging is planned and required before activation - it is not yet built or independently verified in this staging build.
Human approval Manual control
High-risk actions - publishing, spend changes, mass communications, pricing changes, regulated copy - are intended to always require explicit pre-approval, never autonomous execution. Today this is enforced as a manual, human-supervised process rather than an automated platform gate.
Independent verification Planned
The design principle is that agent-claimed completion is never accepted as proof - a separate verification step should check the actual target-system state before anything is marked "Verified." An automated, independent verifier is planned; today any verification that occurs is manual and human-performed, not yet an automated compliance gate.
Incident response Planned
A defined escalation-owner process and documented incident-response procedure are planned and required before any paying client engagement - not yet formally documented or tested in this staging build.
Kill switch Required before activation
An independent kill switch - allowing designated Salvation kill-switch keyholders to disable client-agent execution at any time without needing anyone else's sign-off - is a required control before any paying client engagement goes live. It is not yet built or independently verified as implemented in this staging build.
Cross-border data issues Required before activation
Cross-border data handling considerations are tracked as an open item for legal review, required before any paying client engagement - not glossed over, and not yet resolved.
Regulated vertical controls Planned
AHPRA, TGA, National Law, and NDIS-aware compliance gates are planned as productised features for relevant clients, not generic boilerplate - they are not yet built or independently verified as implemented.