# Supabase Production Readiness Register — Terra Vita Hub

## Status
Operational hardening register for the next backend track. This document is a control register only; it does not change Supabase, SQL, RLS, Netlify Functions, credentials, or production data.

## Operating principle
Terra Vita Hub should run as one governed Hub infrastructure with multiple protected programme environments. Programmes should be separated by `programme_id`, `project_code`, `organisation_id`, role, workspace assignment, and RLS policies. Separate Supabase projects should be used for staging/testing and, where sovereignty or client sensitivity requires it, dedicated country/client environments.

## Production environment controls
- Dedicated Supabase production project for the live Hub.
- Separate Supabase staging/test project for risky fixes, QA, migrations, and load testing.
- No direct testing of risky patches on production.
- Environment variables separated by production, staging, and local development.
- Access to production service-role credentials restricted to server-side functions and approved operators only.

## Data access and RLS controls
- RLS enabled on every sensitive table.
- Programme-level policies bound to `programme_id` and/or `project_code`.
- Organisation-level policies bound to `organisation_id`.
- User-level policies bound to authenticated `user_id` and profile/workspace access rows.
- Admin-only operations routed through server-authorized APIs.
- Periodic RLS test suite for CARH, Jazira, Marys Mount, public projects, mining, Blue Governance, investor, DFI, and admin roles.

## Indexing priorities
Add or verify indexes for the highest-use filters and joins:
- `programme_id`
- `project_code`
- `organisation_id`
- `user_id`
- `status`
- `created_at`
- document routing keys
- evidence/workflow foreign keys
- funding milestone/tranche relation keys

## Serverless and pooling controls
- Avoid uncontrolled database connections from Netlify Functions.
- Use Supabase API/client access where appropriate.
- Use connection pooling for direct server-side database access where required.
- Keep admin APIs controlled and narrow.
- Monitor database connection usage during active pilots.

## Heavy process separation
The following should not run as heavy live page-load processes at global scale:
- AI Advice synthesis
- PDF/DOCX export pack generation
- investor/data-room bundle generation
- satellite/GIS interpretation
- large uploads and post-processing
- committee pack generation
- TV-CRI recalculation

Target pattern:
- queued jobs
- stored summaries
- cached readiness states
- generated export records
- visible governed statuses such as `synthesis queued`, `export ready`, `satellite interpretation pending`, and `committee pack generated`.

## Performance and caching controls
- Dashboard summary views.
- Materialized funding/readiness views where appropriate.
- Cached document counts and route posture.
- Stored AI Advice summaries.
- Stored TV-CRI posture.
- Stored programme readiness summaries.
- CDN caching for public pages.

## Backup, restore, and monitoring
- Point-in-time recovery appropriate to production risk level.
- Daily backups and restore drills.
- Monitoring for API errors, function errors, database CPU, memory, connection pressure, storage growth, and slow queries.
- Audit log retention policy aligned to institutional requirements.
- Incident response contacts and escalation path.

## Sovereignty and enterprise deployment options
- Standard central Hub production project for controlled pilots.
- Dedicated client/country Supabase project where sovereignty, procurement, or confidentiality requires separation.
- Region selection aligned to client jurisdiction and data-residency requirements.
- Sensitive identity/evidence retained inside approved jurisdiction where required.
- Portfolio reporting can use derived or permissioned indicators without collapsing country authority.

## Next backend implementation sequence
1. Confirm production/staging Supabase separation.
2. Export current schema and policy inventory.
3. Run RLS coverage audit by table and role.
4. Add/verify critical indexes.
5. Review Netlify Function connection behaviour and admin API boundaries.
6. Define heavy-task queue/export strategy.
7. Add monitoring and backup verification.
8. Run controlled load tests for pilot, programme rollout, and institutional usage scenarios.

## Protected boundary for UI packages
UI ZIP releases may document this register and surface admin links to it, but should not change Supabase policies, SQL, production credentials, admin APIs, or Netlify Functions unless a backend-specific release is explicitly authorized.


## v172 Global deployment database readiness pack

The database hardening track now has a concrete SQL pack and runbook:

- `sql/172_global_deployment_database_readiness.sql`
- `supabase/migrations/172_global_deployment_database_readiness.sql`
- `ops/SUPABASE_GLOBAL_DEPLOYMENT_READINESS_RUNBOOK.md`

The pack adds a global readiness control register, data-sovereignty configuration table, export audit log, background-job queue, risk-assurance register, continuity-test register, MRV quality-check register, conditional indexes, and admin readiness views.

This is a deployable readiness pack, not a live database execution. It should be run in staging first, then promoted to production after review.