A pointer file is the small text stub Git LFS commits in place of a large binary. It contains a version line, the object's OID hash, and its size, and it is what actually lives in your Git history. The real content sits on an LFS server, fetched on demand.
The design works while every participant is LFS-aware. The failure mode is what happens when one is not. A teammate clones without LFS installed, or a CI runner, or an automated tool. They see the pointer files as ordinary text. If they then commit, the pointers are committed as the file contents, and the association with the real asset is broken.
What makes this the classic Git LFS data-loss story is that nothing fails loudly. The repository is valid. The commit succeeds. The file is present. Someone opens the project a week later and finds a texture that is 130 bytes of text, and the actual asset has to be recovered from whoever still has it locally.
Spotting one is easy once you know: open the file in a text editor. If it starts with `version https://git-lfs.github.com/spec/v1`, it is a pointer, not your asset.
USourceControl has no pointer layer at all. The file you commit is the file stored, so this class of failure does not exist.