The trouble is that a naked identifier doesn't tell you what space of identifiers it comes from. There is just this ambient knowledge that a field called Policy ID is issued from the System of Record for policies. That means there can only be one "space" of policy numbers, and they must all be issued by the same SoR.

I don't believe in the idea of a single system of record. One of my rules for architecture without an end state is "Embrace Plurality". Whether through business changes or system migrations, you will always end up with multiple systems of record for any concept or entity.

In that world, it's important that IDs carry along their context. It isn't enough to have an alphanumeric Policy ID field. You need a URN or URI to identify which policy system issued that policy number.

Imagine a Calendar service that tracks events by date and time. It would seem weird for that service to keep all events for every user in the same calendar, right? We should really think of it as a Calendars service. I'd expect to see API to create a calendar, which returns the URL to "my" calendar. Every other API call then includes that URL, either as a prefix or a parameter.

In the same way, your services should serve all callers and allow them to create their own containers. If you're building a Catalog service, think of it as a Catalogs service. Anybody can create a catalog, for any purpose. Likewise, a Ledger service should really be Ledgers. Any client can create a ledger for any reason.

This is the way to create services that can be recombined in novel ways to create maneuverability.