The isolation model, and an account of what this build actually enforces today.
Every row carries a tenant identifier, and row-level security is enabled AND FORCED on every tenant-scoped table. Forced matters: enabling alone exempts the table owner, and the application connects as the owner.
The policy covers writes as well as reads. Read-only isolation is the less dangerous half, without a write check a tenant could insert rows belonging to someone else.
A session that does not declare its tenant sees zero rows and can insert nothing. That is default-deny, and the database is what enforces it, and it is verified by attempting a cross-tenant read as a non-superuser role, not by reading the query and agreeing it looks correct.
Row-level security protects rows and nothing else, not the filesystem, not scratch space, not temporary files, not process memory. Media parsers handling customer-supplied files are a live remote-code-execution surface.
So the design is one job per worker lifetime, on ephemeral disk, with paths keyed by tenant and job, and no egress beyond the connector and the object store. Job-level purge is a separate ledger-driven operation rather than a side effect of an instance terminating, because otherwise the purge guarantee is unprovable.
No authentication. No authorisation. No access log. No encryption of data at rest beyond whatever the host filesystem provides. No key service, so the purge attestation is unsigned and says so.
This is a local development surface, and listing what is absent is more useful than describing an intended end state as though it were present.
Rub‑a‑Dub Duck