AfricanComplex — Platform Operations Policy

INTERNAL DOCUMENT — NOT CUSTOMER-FACING This policy governs internal platform operations, data lifecycle, and administrative procedures. It is the source of truth for developers and operations staff on retention, storage, security, and incident handling.

Last Updated: [DATE] Owner: Engineering / Operations

1. Purpose

This document defines internal operational rules for the AfricanComplex platform and OrbitApex delivery service. It ensures that development, deployment, and operational practices align with the commitments made in our legal documents (Privacy Policy, Terms of Service, Merchant Agreement, Driver Agreement).

2. Data Retention Schedule

All retention periods must match the Privacy Policy. If a conflict exists, the Privacy Policy governs and this document must be updated.

2.1 User Data

2.2 Financial Data

2.3 Compliance Data

2.4 Operational Data

3. Cloudflare R2 Storage Lifecycle

3.1 Buckets

3.2 Signed URL Policy

• All private files accessed via signed URLs only
• Signed URL expiry: 15 minutes (900 seconds)
• Signed URLs generated server-side, never exposed in client code
• No direct public access to private prefixes

3.3 Upload Limits

3.4 Retention and Cleanup

R2 cleanup cron runs weekly. Deletes files whose associated database records have exceeded retention:

4. Encryption Standards

4.1 In Transit

• All API traffic: TLS 1.2+ (enforced by Cloudflare and Railway)
• All database connections: SSL required (Neon enforces this)
• Mobile app API calls: HTTPS only (certificate pinning recommended post-MVP)

4.2 At Rest

• Database: Neon provides encryption at rest by default
• SSN field: Application-level AES-256-GCM encryption before database storage
• R2: Cloudflare provides encryption at rest by default
• Encryption key stored in environment variable ENCRYPTION_KEY, never in code

4.3 Key Management

• ENCRYPTION_KEY: 32-byte key, base64 encoded, generated via openssl rand -base64 32
• Stored in Railway environment variables (not in repo, not in .env files committed to git)
• Key rotation procedure: [TO BE DEFINED — requires re-encryption migration]

5. Admin Access Controls

5.1 Role Hierarchy

SUPER_ADMIN → full system access
  └── ADMIN → platform management, approvals, refunds
        └── SUPPORT_AGENT → tickets, basic dispute resolution

5.2 Access Rules

5.3 Audit Logging

Every admin action is logged to audit_logs with:

• Admin user ID
• Action type (enum)
• Target type and ID
• JSON details (before/after state where applicable)
• Timestamp

Audit logs are immutable. No admin can delete or modify audit log entries.

5.4 Admin Access Review

• Quarterly: Review all ADMIN and SUPER_ADMIN accounts
• Remove access for inactive admins (no login in 90 days)
• Verify 2FA is enabled for all elevated roles
• Document review in internal records

6. Incident Response

6.1 Severity Levels

6.2 Data Breach Response

If a data breach is suspected or confirmed:

1. Contain — Identify and isolate the affected system
2. Assess — Determine what data was exposed and how many users affected
3. Notify — Alert SUPER_ADMIN and legal counsel immediately
4. Remediate — Fix the vulnerability
5. Communicate — Notify affected users within 72 hours (or as required by applicable law)
6. Document — Create incident report with timeline, impact, and remediation
7. Review — Post-incident review within 7 days

[ATTORNEY NOTE: State-specific breach notification timelines vary. California requires notification "in the most expedient time possible." Other states have specific day counts. Verify requirements.]

6.3 Payment Incident Response

If Stripe payout discrepancies are detected:

1. Pause affected transfers
2. Run reconciliation check (see docs/finance-reconciliation.md)
3. Contact Stripe support if platform-side reconciliation doesn't resolve
4. Document resolution in audit log

7. Backup and Recovery

7.1 Database Backups

• Provider: Neon handles automated backups
• Frequency: Continuous (point-in-time recovery)
• Retention: Per Neon plan (Pro: 7 days point-in-time, 30 days history)
• Recovery: Restore to any point within retention window via Neon dashboard

7.2 R2 Storage

• Backups: Cloudflare R2 provides 99.999999999% durability (11 nines)
• No separate backup required for R2 objects at MVP scale
• Critical files (driver documents, delivery proofs): consider cross-region replication post-MVP

7.3 Application Code

• Source: GitHub repository (main branch protected)
• Deployment: Railway auto-deploys from main
• Rollback: Railway supports instant rollback to previous deployment

8. Environment Management

8.1 Environments

8.2 Secret Management

• All secrets stored in Railway environment variables (production)
• Local development uses .env.local (git-ignored)
• Never commit secrets to the repository
• .env.example contains variable names only (no values)
• Stripe test keys for development, live keys for production only

8.3 Environment Variable Validation

All environment variables validated at application startup via Zod schema (packages/shared/env.ts). Missing or malformed variables cause immediate startup failure with clear error messages.

9. Deployment Procedures

9.1 Standard Deployment

1. Feature branch → PR against develop
2. CI passes (lint, type-check, tests, Prisma validate)
3. Code review + approval
4. Squash merge into develop
5. develop → main via release PR (weekly or milestone-based)
6. Railway auto-deploys from main

9.2 Database Migrations

1. Create migration: prisma migrate dev --name description
2. Review generated SQL
3. Test migration on Neon branch database
4. Include migration in PR
5. Migration runs automatically on deploy via prisma migrate deploy

9.3 Rollback

• Application: Railway instant rollback (one click)
• Database: Migrations are forward-only. If a migration must be reversed, create a new migration that undoes the change. Never manually edit the database in production.

10. Monitoring and Alerting

10.1 Application Monitoring

10.2 Alerts

11. Document History