Make a data-path register

Run one approved synthetic CRUD fixture under a named evaluator. For each data class, capture a source or observed record, the destination, the access role, the retention or recovery owner, and unresolved dependencies.

Data class What to trace
Application definition and metadata Destination, retention owner, and export or retrieval path
Business records Data source, reads, writes, and recovery owner
Attachments and generated files Object path, deletion and retrieval boundary
Credentials and secrets Creation, storage, rotation, and emergency-access path
Logs and audit records Event location, access role, retention, and export path
Backups and replicas Scope, location, restore authority, and tested limit
Provider or support access Terms, configuration, recorded access evidence, and unknowns

Leave an unobserved path as unknown. A self-hosted deployment label cannot fill in a vendor integration, browser telemetry, external identity provider, support process, or backup location.

Keep factual labels separate

Call a statement documented when it comes from an identified primary source. Call it observed only when the named fixture and configuration generated an inspectable record. Call it unresolved when the evaluator cannot see the path.

This procedure is the data-path child of the vendor-cloud and customer-cloud responsibility method. The related self-hosted definition explains why an install location alone is not an operating model; pair the register with a BYOC vendor evaluation instead of using any one page as proof of a complete data boundary.

Stop condition

Do not name a platform as keeping application data in a company's cloud while any material data path is unobserved or based on a non-equivalent fixture. The right result may be “unknown pending evidence,” not a product conclusion.

Is an application definition the same as business data?

No. They can have different destinations, retention policies, operators, and recovery procedures. Record them separately.