Give Generated Apps Managed Data Without Losing Ownership

This course is built around the public Zheta Kubernetes Lab monorepo. The excerpt below is runnable source, not pseudocode.

Source: services/control_plane/domain.py

def create(self, project_id: str, organization_id: str, name: str, actor: str, archetype: str) -> Project:
        project = Project(project_id, organization_id, name, actor, blueprint={"name": name, "archetype": archetype})
        project.collaborators.add(actor)
        with self.repository.transaction():
            self.repository.create(project)
            self._audit(project, actor, "project.created")
        return project

Code to reality

Declared intent

Create one tenant-owned project and its audit evidence as a single product operation.

Interpreter

Python executes the Forge domain model after the controller supplies authenticated command values.

Software effect

The repository durably owns the project while the event port publishes project.created evidence.

Hardware effect

The service process uses CPU and writes database pages to its persistent volume or managed database.

Observable evidence

A tenant-scoped GET plus a project.created evidence record proves both state and accountability.

The source tables below remain the detailed contract. Begin with these customer paths:

• D07-UC-01
  • Person: Application creator
  • Job: Add durable domain data to a policy portal, approval workflow, or support dashboard
  • Observable result: App migration succeeds and a tenant-scoped record survives pod replacement
• D07-UC-02
  • Person: Generated-app tenant administrator
  • Job: Keep one app tenant's records inaccessible to another tenant
  • Observable result: Valid tenant reads its records through app authorization predicates

Now turn each customer job into a story with a result that an engineer can check:

• D07-US-01
  • Story: As an application creator, I want a versioned managed-data contract, so that schema changes and recovery are reproducible
  • Observable acceptance: Provision ID, database binding, migration digest, backup ID, and post-restart read are recorded
• D07-US-02
  • Story: As a generated-app tenant administrator, I want tenant predicates enforced on every domain query, so that knowing a record ID cannot bypass isolation
  • Observable acceptance: Wrong-tenant request is denied and audited; right-tenant positive control remains successful

Finally trace each story through the system that owns its state and the evidence that proves the outcome:

• D07-FLOW-01
  • Trigger: Creator selects Enable managed data
  • Responsible systems: Data Provisioner, migration runner, secret/workload-identity adapter, generated app
  • Authoritative state: Provision record in control plane; generated-app PostgreSQL for domain data
  • Owned record: DataProvision
  • Observable evidence: Actor, app, provision ID, binding, migration digest, record ID, replacement Pod UID, read trace, timestamp
  • Failure signal: Provision error, migration failure, failed readiness, or missing post-restart record
• D07-FLOW-02
  • Trigger: Tenant B requests Tenant A's record ID
  • Responsible systems: Runtime Gateway, generated-app session and repository policy, Audit Evidence
  • Authoritative state: Generated-app PostgreSQL and app audit trail
  • Owned record: DomainRecord
  • Observable evidence: Actor, app tenant, record, predicate policy, denied result, positive-control trace, environment, immutable run ID
  • Failure signal: Missing tenant predicate, cross-tenant row, denial without trace, or failed positive control

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.

Managed data is useful only when application code owns domain rules and the platform owns lifecycle automation. These use cases prove both durable writes and denied cross-tenant reads.

Database connectivity is not authorization. These stories require application-level tenant policy plus platform-level credential isolation.

The customer enables managed data from the application settings, not by receiving a master password. A generated workload obtains only its app-scoped binding.

Giving every service a database password would erase least privilege. Data Provisioner creates a binding; the generated app alone implements its domain schema and tenant predicate.

Provider metadata and customer domain rows need separate deletion and export rules. An opaque provision reference connects them without transferring authority.

Generated-application database: Not created in this runnable slice — the monorepo persists provider project/artifact state and hosted-runtime payloads, while the generated-app PostgreSQL contract below remains a production design requiring its own adapter, migration, tenant-denial, backup, and deletion proof.

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

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.