Where Your Project Data Lives Before and After Sign-In
SlateX keeps guest data and signed-in data in two separate physical database stores. They use the same data model, but they are not the same file. The guest store holds records created while signed out. The account store holds signed-in records, and only that account store is configured with a private cloud database. Ownership is not determined by a rule such as “whoever is signed in owns everything”; individual records are evaluated against Apple-identity ownership conditions.
Separate stores describe where records are kept. They do not, by themselves, prove a security, privacy, or cross-device outcome.
Guest and account records live in different store files
Both stores are placed in an application-support directory reserved for the app. This is not the Documents location that a user browses in the Files app. A database file therefore should not be treated as a complete media backup, and copying that file alone should not be described as a complete recovery method.
The two stores share the same data-model instance, so projects, scenes, takes, and continuity assets still use the same object structure. The difference is the storage destination. Guest data goes to the guest store. Signed-in data goes to the account store. The code configures a private cloud database only for the account store; the guest store has no cloud-upload configuration during its lifecycle. That is a statement about configuration in the code, not a claim that device testing has proven the absence of every possible upload.
Photos and videos are represented differently
Photo data is stored as binary data in the database, so the photo payload follows that database record. Video is different: the database stores a path to a local file rather than the video payload in the same kind of field.
That distinction means photos and video paths should not be given the same cross-device expectation. The code shows what each record contains, but it does not support a promise that a media item will always appear, or never appear, on another device. A database record and a local media file are two different facts.
A media record in the database does not prove that its corresponding local file has arrived on another device.
Ownership is checked per record
On the account side, ownership is evaluated through Apple-identity predicates and the relationships that connect a record back to its owner. Signing in does not simply turn every row in the store into data owned by the current account.
This ownership check also matters when records are read, migrated, or removed during an account transition. Sign-in selects an account data environment, but a particular record still has to resolve through the ownership relationships used by the data layer.
Guest migration happens only during an explicit sign-in
Moving guest data into the account store is not a side effect of restoring an existing sign-in. The migration path is enabled when the user explicitly starts sign-in; automatic restoration of a saved account does not migrate the guest store.
The migration is staged. The app first snapshots guest data, writes the supported graph into the account store, and then verifies properties, relationships, and ownership in a fresh context. Only after that verification succeeds is the source guest data cleared. If a stage fails, the source-clearing step does not run.
If verification fails, the source is kept rather than partially removed. This describes the current migration sequence. It does not prove any additional cloud or device-level guarantee.
The boundary of this explanation
This mechanism can answer where guest and signed-in records are stored, which store is configured with a private cloud database, how photo and video records differ, and when guest migration runs. It does not establish any particular encryption model, an all-encompassing privacy guarantee, or a completed device-level security audit.
Questions such as whether another device will receive a specific media file, whether deleting the app enables later recovery, or whether a legal requirement is satisfied need evidence beyond what these code paths establish, so this page does not extend the claim that far.
FAQ
Do guest and signed-in records use the same database file?
No. They use separate physical database stores while sharing the same data-model instance. Guest records go to the guest store and signed-in records go to the account store.
Is the guest store configured for the private cloud database?
No cloud-upload configuration is attached to the guest store in the current code; the private cloud database configuration is attached to the account store. That is a code-configuration fact, not a device-test claim about every network behavior.
Why should photos and videos have different cross-device expectations?
Photo payloads are stored in the database, while video records contain a local file path. Those are different storage mechanisms, so the presence of a database record alone does not establish that the corresponding video file exists on another device.
When does guest data move into an account?
The migration path is enabled when the user explicitly signs in. Restoring an existing sign-in does not automatically migrate guest data, and the source is cleared only after the migration has been verified.
Axiom One LLC — SlateX. Figures current as of 24 September 2026.