Cross-project refs treat public models as a stable API, not a package

The docs distinguish packages from project dependencies. A package installs another project's full source into yours so you can call its macros and run its models. A project dependency instead uses a background metadata service to resolve refs to public models defined elsewhere; you do not parse or run those upstream models yourself.

For data teams at scale, packaging every shared transformation as source code is a poor fit for multi-team collaboration. Project dependencies let producers own quality and stability while consumers depend on a dataset interface. Setup requires Enterprise or Enterprise+, models marked access public, a production environment with a successful job that emits manifest.json, and unique project names in the account.

That split maps shared meaning to an explicit contract between projects: upstream meaning is published as public models, downstream systems bind by reference, and governance sits with the maintainer rather than with copied code.