GEP-001 · References GID-001

Engineering principles

The non-negotiable technical standards every Ansai product must meet.

Rendered verbatim from the source document (v1.0). It predates the July 2026 category update: where it reads "institutions," current external language is "organizations." This is a technical document and names specific tools, including AI, plainly.

01 — The data architecture standard

Local-first · Sync-always · Backup-automated · Loss-never

Every Ansai product that handles institutional data must implement this data architecture. No exceptions. This is not a recommendation — it is the minimum standard for any product that calls itself operational infrastructure.

Local-first: Data is written to the device first — immediately, without waiting for a network response. The sync to the server happens in the background.
Sync-always: Continuous background sync when connectivity exists. Maximum 30-second gap for critical data (financial records, attendance). Exponential backoff on failure.
Backup-automated: Server replicates to backup automatically. Three layers minimum: local write → server sync → off-site backup. No manual backup processes.
Loss-never: A user who enters data on a device with no internet connection must never lose that data. It is written locally and synced when connectivity returns.

Implementation standard

Service Workers (Workbox) for background sync and caching. IndexedDB for local structured storage. CRDTs for conflict-free merge logic when a device reconnects after an offline period. These are the required tools. Equivalent alternatives require documented justification and founder approval.

02 — The AI adoption standard

Every engineer on an Ansai product must operate at Level 5 minimum on the AI adoption scale. Level 6 is the target hire profile. The scale is observable and testable — ask any candidate to describe how they built something recently. The answer tells you their level.

Level 1: Writes code by hand. Uses tab completion occasionally. Not an Ansai hire.
Level 2: IDE agent, supervised. Reviews and approves every agent action. Not at standard yet.
Level 3: IDE agent, unsupervised. Permission gates off. Agent runs automatically. Approaching standard.
Level 4: Wide agent, diff mode. Engineer reviews diffs, not code. At minimum standard.
Level 5: CLI single agent, run from the terminal. Reviews output, not generation. Minimum Ansai standard.
Level 6: CLI multi-agent, 3–5 in parallel. Target Ansai hire profile. One engineer produces what five produced in 2022.
Level 7: 10+ agents hand-managed. Senior engineering leadership profile.
Level 8: Builds own orchestrator. Founding CTO profile.

The verification test

In any interview, ask: walk me through the last significant thing you built and how you built it. If the answer does not involve AI agents doing the heavy lifting while the engineer directed and verified — they are below Level 4. If they describe running multiple parallel agents from the terminal — Level 6. Hire accordingly.

03 — Quality non-negotiables

Tests before features

No feature ships to production without tests covering its critical path. AI-generated code accumulates technical debt faster than human-written code and must be tested more rigorously, not less. The faster we ship with AI assistance, the more robust the test suite must be.

Critical path test coverage — minimum

Financial data: Fee payments, balance calculations, duplicate prevention. 100% critical path coverage before any school handles real money.
Authentication: Login, account lockout, token validation. Security tests must pass before any production deployment.
Tenant isolation: Cross-tenant data access prevention. The foundational security guarantee of any multi-tenant Ansai product.
Data sync: Offline write, reconnect sync, conflict resolution. The local-first architecture must be verified under real connectivity conditions.

Code review standard

The first pull request from every new engineer is reviewed in extreme detail by the technical lead. This is the standard-setting moment. After that, code review is continuous, but the initial review sets the bar that all subsequent work is held to.

CI/CD requirement

No code reaches production without passing automated tests. Auto-deploy on push with no quality gate is not acceptable for any Ansai product handling real institutional data. GitHub Actions or equivalent must gate every deployment.

04 — Security baseline

Every Ansai product must meet these security standards as a baseline before any school, farm, clinic, or institutional user is onboarded.

Authentication: JWT with refresh token rotation. Short-lived access tokens (15 min). Long-lived refresh tokens (7 days, httpOnly cookie).
Password hashing: bcrypt, minimum 12 rounds. No MD5, SHA-1, or unsalted hashes anywhere in the codebase.
Rate limiting: Login endpoints: 10 requests/minute. Public-facing endpoints: configurable per endpoint risk level.
Account lockout: 5 consecutive failed login attempts triggers lockout. Counter resets on successful login.
Data isolation: Multi-tenant products: every query scoped to tenant ID, enforced at middleware level, not just application level.
Audit logging: Every data mutation recorded with user ID, timestamp, IP address, and JSON diff. Best-effort — failures do not block operations.
File uploads: MIME type validation. Size limits enforced server-side. UUID-based storage keys. No user-controlled file paths.
Dependencies: Regular security patching. No known critical CVEs in production dependencies. Automated dependency scanning in CI.

05 — The infrastructure-aware engineering standard

Every Ansai product is designed for the connectivity conditions that African institutions actually experience, not the conditions assumed in a developed-market office. This is not a feature — it is the engineering philosophy.

Every feature is designed for 2G connectivity first. Fibre is the upgrade path, not the assumption.
Bundle sizes are minimised. Every kilobyte costs real money for users on mobile data.
Images are compressed, lazy-loaded, and cached aggressively.
API responses are paginated and minimal. Over-fetching is a performance violation.
Failure states are designed. Every screen that loads data must handle the case where that data does not arrive. Spinners that time out silently are unacceptable.

06 — Document control

Document ID: GEP-001
Version: 1.0
Parent doc: GID-001 — Ansai Group Identity Document
Owner: Technical Lead — Ansai Technologies
Review cycle: Every six months — or when a new product vertical is added