Architecture, in plain language.
Three structural decisions: schema-driven orchestration, governance at the core layer, on-premises by default. The rest of this page explains what those mean and what they imply for audit and compliance.
Three structural decisions.
Schema-driven orchestration (BIPA)
The data layer is compiled from a declarative schema. Permissions, validation, and audit are properties of the schema itself — not behaviours added later by application code.
Governance at the core layer
Access control happens at the database query level, not at the application level. Users cannot access data they're not authorised to see, regardless of which interface — UI, API, integration — they use.
On-premises by default
Kwerio runs inside your perimeter. Data residency, encryption keys, and infrastructure are yours. The platform vendor cannot read your data — by architecture, not by promise.
"The schema is the contract. The compiler enforces it."
BIPA — Business Information Process Architecture — is the foundation Kwerio sits on. Where REST exposes resources and GraphQL exposes a graph, BIPA exposes a compiled, governed contract. Permissions, validation, and audit hooks are not implemented in handlers; they are derived from the schema.
This is what makes Kwerio's audit posture structural rather than aspirational. An auditor who reads the schema can verify, deterministically, who can do what to which records — and what evidence will be left behind.
# bipa-contract.kw — excerpt
# Approval requires segregation of duties at the data layer
entity Invoice {
amount Money
status Status audit:full
approved_by User? constraint: not(approved_by == created_by)
policy read = role in [finance, audit, treasurer]
policy update = role == treasurer and status == 'pending'
}Four properties auditors can verify.
Immutable audit trail
Every state change is recorded at the data layer with a tamper-evident hash chain. Application bugs cannot suppress entries; database access cannot rewrite them.
Structural segregation of duties
Conflicting roles cannot be granted to the same user, by schema constraint. The constraint is checked on every transaction, not at provisioning time.
Human-in-the-loop by design
Decisions requiring human judgement are encoded as approval gates in the schema. The platform cannot bypass them; nor can the application above it.
Verifiable evidence
Compliance evidence is exportable as signed, timestamped, hash-linked records. Auditors verify the chain without needing access to the running system.
Seven policies, published. Not gated, not theatrical.
Backup & disaster recovery
in placeEncrypted backups taken daily, retained 30 days. Recovery tested yearly with documented RPO/RTO. Restoration evidence available on request. More frequent backups, longer retention, and additional test cycles can be configured on request.
Data residency
in placeOn-premises by default. EU residency confirmed for partner-managed deployments. No data leaves your jurisdiction without explicit, audited authorisation.
Access control & SoD
in placeDatabase-level row and column access control. Segregation of duties enforced as schema constraint, not application logic. Verifiable per-query.
Encryption
in placeAES-256 at rest, TLS 1.3 in transit. Customer-managed keys supported for on-premises deployments. Key rotation documented and operator-controlled.
Multi-tenant isolation
in placeLogical isolation via schema-enforced tenant boundaries. Physical isolation available for deployments that require it. Cross-tenant queries are not constructible.
Audit trail & tamper-evidence
in placeHash-chained, signed log of every data-layer state change. Verification tooling published. Auditor can confirm chain integrity without platform access.
Incident response
in placeDetection via centralised observability stack. Triage within 4 business hours. Customer notification per contractual SLA. Post-incident report within 10 business days.
Deployment topology.
Five layers. The core layer is where governance lives — not the application, not the API.