Give Generated Apps Managed Data Without Losing Ownership
Provision durable application data through a platform contract while keeping each generated app responsible for its own tenants and authorization predicates.
System map · Day 07
Whole-system design
Five stable layers. Today's work is expanded and linked; the rest stays in context.
Product and authority
Covered — People and product entry points · HelixWorks control planeAhead — Identity and policy
Generated application plane
Design target · not proved
Application-owned users, roles, and domain predicates are the target boundary; the current generated HTML has none of them.
Delivery and desired state
Covered — CI and immutable artifactsAhead — Git desired state · Argo CD reconciliation
Cloud and orchestration
Covered — Terraform and AWS APIs · Accounts, VPC, DNS, and private paths · Kubernetes or EKS control plane
Compute and traffic
Covered — Worker compute · Platform service workloadsAhead — Ambient mesh data plane
Generated app workloads
Design target · not proved
A deployment-scoped data identity is required before a generated workload may reach managed data, but is not implemented yet.
Storage and evidence
Covered — Evidence and observabilityAhead — Infrastructure state · Cluster desired and live state
Product data and artifacts
Design target · not proved
Tenant-qualified generated-application storage, migrations, backup, export, and deletion remain an explicit implementation gap.
The enterprise problem and today’s slice
Enterprise problem: A shared database with provider-wide credentials lets one generated app read another app's records and makes export or deletion inseparable from platform metadata.
Whole-course context: The local preview runtime durably stores deployment payloads but is not an isolation sandbox; today separates that hosted-runtime state from the future generated-app domain database.
Today’s slice: Design the generated-application PostgreSQL ownership contract, then identify the gap between that production target and the current local runtime, which persists deployment payloads but has no generated-app domain database.
End-of-day evidence: The existing domain test proves organization-scoped provider lookup, restart durability, tombstoning, and retained evidence; a gap record names the missing app-tenant query, migration, backup, export, and deletion proofs.
Still unsolved: Enterprise-source connectors, delegated identity, sharing, publication, and multi-account AWS data services remain deferred.
Customer outcome and implementation focus
The customer outcome is a reviewable give generated apps managed data without losing ownership change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.
Components in focus
Generated-app API and database provisioner; application runtime pods; tenant database tables and backup/object storage; cache: optional and not used in this slice so authorization is checked at the database-facing service.
This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.
Provision tenant-scoped generated-application data
Prove persistence and tenant denial
A successful database connection says nothing about authorization. The current code proves only that repository lookups include both organization_id and project_id; it does not implement the generated-application database, schema migration, or app-tenant predicate described above. Read the actual local persistence seam in services/shared/persistence.py.
def get(self, organization_id: str, project_id: str) -> dict[str, object] | None:
row = self.database.one("SELECT payload FROM projects WHERE organization_id=? AND project_id=? AND deleted_at IS NULL", (organization_id, project_id))
return json.loads(row[0]) if row else None
Decision rules
Use platform automation to provision, bind, back up, export, and delete data services; keep schema semantics and row authorization in the generated application. Never use an opaque cross-plane reference as proof of permission.