Design Rationale — Platform
Non-obvious design choices for the platform module — the WHY behind each decision.
Platform (locked 2026-05-13 / 2026-06-09)
Platform owns Vrida→tenant subscription billing — not the billing module
Decision: platform schema owns all tenant subscription, tier, invoice, and SaaS payment tables (subscription, subscription_invoice, payment, tier_definition, tenant_entitlement). The billing schema owns merchant A/R and A/P (tenant charges its customers).
Why: "Vrida charges the tenant" is a platform-level concern; "tenant charges its customers" is a merchant-layer concern. Keeping them in separate schemas prevents the confusion that made the original 11_billing.md spec stale (it conflated both).
Guard: Subscription, MRR, tier-gate, and SaaS-payment concepts belong in platform, never in billing or payments. If it's about Vrida's own revenue, it's platform.
Tenant lifecycle events and setup tasks on platform, not in owning modules
Decision: tenant_lifecycle_event and tenant_setup_task live in platform even though they reference milestones across many modules.
Why: The platform is the control plane for tenant onboarding and lifecycle; no nursery module should own provisioning state. Centralizing here lets the foundation milestone gate be enforced in one place.