Governance you can inspect.
This page separates what the platform is designed to enforce from what is validated today. Where a fact is unconfirmed, it is marked rather than implied.
Review status: facts on this page carry [VALIDATE] markers until they are confirmed with dated evidence.
A governance model, stated honestly.
The design principle is simple: every action in a governed workflow has an actor, an authority and an evidence trail. AI employees prepare within bounded roles; people decide what is consequential; the platform records what happened.
Design principles are not proof. This page distinguishes the controls the platform is architected around from specific technical facts — hosting, encryption, certifications — that require validation before we state them as fact.
Anything marked [VALIDATE] is a commitment we intend to confirm with dated evidence, not a claim we are asking you to accept today.
What the platform is designed to enforce.
The first column is design intent built into the architecture. The second is what we deliberately do not claim. [VALIDATE] Each enforcement point is being confirmed against the current product before it is stated as shipped capability.
Within its role
- Bounded roles: every actor — human or AI — operates inside configured permissions
- Approval gates: consequential actions wait for a person with authority
- Escalation by default: uncertainty routes to people rather than improvising
- A retained trail: sources, decisions and approvers kept inspectable
Always with people
- Claim certifications, attestations or compliance status not yet earned [VALIDATE]
- Claim specific encryption, logging or resilience mechanisms before validation [VALIDATE]
- Claim immutable audit trails — a strong claim we will not make until it is proven [VALIDATE]
- Operate autonomously: no consequential action executes without its configured human gate
How your data is intended to be handled.
Our commitments, pending legal and technical validation: your operational data remains yours; it is used to run your workflows, not to train shared models; and access is scoped to the roles that need it. [VALIDATE]
The specifics — hosting locations, retention periods, subprocessors, model providers, backup and deletion practices — are being documented with evidence before they are published here as fact. [VALIDATE]
This website itself is informational. Its contact form opens your own email application with a prefilled message; the page does not transmit or store your entries on our servers. [VALIDATE]
Cloud workspace or private deployment — the honest trade-offs.
Two deployment shapes are offered. Until the underlying facts are validated, this table states considerations, not specifications.
| Consideration | Cloud workspace | Private deployment |
|---|---|---|
| Who operates it | Amani Asili-managed environment [VALIDATE] | Client-controlled environment, jointly agreed [VALIDATE] |
| Best fit | Organisations that want a governed start without owning every infrastructure decision | Organisations with strict data-boundary or regulatory requirements |
| Data location | To be confirmed and published with evidence [VALIDATE] | Defined with the client during design [VALIDATE] |
| Your responsibilities | Role definitions, approvals and adoption | Infrastructure prerequisites, plus role definitions, approvals and adoption |
| What we will not promise | Uptime or security specifics before validation [VALIDATE] | A private deployment before its prerequisites are validated [VALIDATE] |
Deployment facts are published here only when validated. Bring specific requirements to a discovery call.
Security questions are welcome — and answered specifically.
Evaluating Amani Asili? Bring your architecture, data-handling and access questions to a discovery call. We would rather answer precisely in conversation than publish broad reassurances here.
Bring us your diligence questions.
Include your security or governance questions when you book — they shape the conversation, not the other way round.