Platform, Security & Governance
Deployment, ownership, security and approval boundaries are part of the architecture, not a retrofit. Everything below is stated with the evidence behind it.
The architecture
Seven layers, in order. Each one answers a question a technical reviewer will ask.
Where does the data begin?
Nothing is replaced to make AI possible. We read from where the truth already lives.
How does it become trustworthy?
Ingested, normalized and reconciled until the figures agree across systems. Client data sits in dedicated, access-controlled databases; where the engagement requires it, sensitive workloads run behind your firewall with full data-residency control.
Where is business meaning added?
What an entity is, how entities relate, which rules apply — and what the organization knows that is written down nowhere.
Where does the model operate?
Models operate on context, not raw data. Model choice is an engagement decision. Models are replaceable; the context around them is the asset.
Model operates here
Where is automated action bounded, and where does a human approve?
Agents act only inside defined boundaries. Consequential actions route to a named approver, and both the boundary and the approval are logged.
Human approval happens here
How do people actually use it?
Interfaces built for the decision being made, not a chat window bolted to the side of the business.
Where is performance measured?
If a capability cannot be measured against the baseline it was built to move, it is not finished.
Performance measured here
What exists, what is configured, what is engineered
Nothing here is entirely turnkey and nothing is entirely custom. This is the split.
Reusable experience, engineering patterns and capabilities AWALI already brings.
Elements adapted to your organization during the engagement.
Client-specific capability that has to be engineered because nobody sells it.
Deployment models
Three patterns, compared on the four boundaries a reviewer asks about: data, application, identity, responsibility.
For organizations seeking managed cloud infrastructure, scalability and streamlined access.
Topology: Client systems, then Secured integration, then Isolated AWS account.
For organizations requiring the solution to operate within their own cloud account, network boundaries or security policies.
Topology: Client cloud account, containing Database, containing Containers, containing Identity, containing Logging.
For environments requiring client-controlled infrastructure, local data handling or more restrictive network boundaries.
Topology: Client firewall, containing Database, containing AWALI containers, containing Authorized users.
Final architecture, hosting responsibility, support requirements and security controls are confirmed during technical discovery. Not every deployment option is available in every engagement.
Security controls
A logo cannot tell you who holds the encryption keys. What we operate, what you decide, what we can show you.
| Control area | Current capability | Engagement-specific decisions | Evidence available |
|---|---|---|---|
| Identity and access |
|
|
|
| Encryption |
|
|
|
| Network and infrastructure |
|
|
|
| Application security |
|
|
|
| Data governance |
|
|
|
| Resiliency and monitoring |
|
|
|
| Engineering lifecycle |
|
|
|
Controls and evidence are monitored continuously through Vanta. Specific controls, responsibilities and service levels are documented for each deployment, and security documentation can be reviewed during diligence and, where appropriate, under NDA.
Compliance and assurance status
An explicit status, and the evidence behind it. What AWALI cannot evidence is not listed — including as a logo.
Engagement-specific
The platform is built and operated to meet HIPAA safeguard requirements for the protection of PHI — technical, administrative and physical controls, monitored continuously through Vanta. Deployment can be structured to keep protected information within client-controlled boundaries, and AWALI executes Business Associate Agreements. Hosting responsibility and the exact compliance scope are confirmed for each engagement.
Controls aligned
The platform is built to the SOC 2 Trust Services Criteria covering Security, Availability and Confidentiality. Controls and evidence are monitored continuously through Vanta, and AWALI is actively pursuing SOC 2 attestation. No attestation report exists yet.
Controls aligned
Continuous automated dependency scanning and cloud-posture monitoring, with remediation tracked to defined internal SLAs. Penetration testing follows OWASP methodology on a periodic basis. Independent third-party assessment is available where an engagement requires it.
Supported deployment
Cloud-native on AWS, run as a multi-account Organization with production, staging, security and management accounts isolated from one another. Self-hosted and on-premises deployment runs from the same container images. Final architecture, hosting responsibility, support requirements and security controls are confirmed during technical discovery.
Controls aligned
Beyond the SOC 2 and HIPAA control sets, AWALI’s controls are additionally mapped to CIS Controls benchmarks.
PHI is a data type, not a certification. AWALI displays no “PHI” badge, and does not present a hosting provider’s certifications as its own.
AI governance lifecycle
Eight stages. Each has an owner, a control, and an artefact. If a stage produces no evidence, it is not a control.
| Stage | Owner | Control | Evidence |
|---|---|---|---|
| Define the business decision | Executive sponsor | Decision and outcome stated before technology | Decision definition |
| Establish authorized data sources | Data / IT owner | Authorized sources only | Source inventory |
| Ground the model in business context | Data / IT owner | Context layer defines entities and rules | Ontology and rule set |
| Define model and agent boundaries | Business owner | Defined action boundary | Action policy |
| Route consequential actions for approval | Functional leader | Approval threshold | Approval record |
| Log sources, decisions and actions | Data / IT owner | Immutable activity logging | Audit log |
| Measure the result against baseline | Executive sponsor | Baseline comparison | Performance report |
| Review, refine or roll back | Executive sponsor | Defined review gate with a rollback path | Review decision record |
Define the business decision
Establish authorized data sources
Ground the model in business context
Define model and agent boundaries
Route consequential actions for approval
Log sources, decisions and actions
Measure the result against baseline
Review, refine or roll back
Solution surfaces
Three interface patterns. Conceptual layouts, not client screenshots.
Illustrative solution pattern
Baseline, current position and the movement between them — for the handful of measures leadership is accountable for.
Illustrative solution pattern
The queue of things that fell outside the rule, with the context needed to resolve them and a record of how they were resolved.
Illustrative solution pattern
Actions an agent proposes, the evidence behind each, and the named human who approves, edits or declines.
Integration and portability
Listed only where used or formally supported. No logo wall.
Architecture, data boundaries, source integrations, client-specific business logic, export rights and transition requirements are defined in the engagement. The goal is capability you can operate — not dependency hidden inside the implementation.
Ownership is not one thing. These distinctions are set in the commercial agreement.
Diligence should start before a solution is sold, not after it is designed. Bring your data, security and architecture people to the first conversation.
