You are exposing your business objects directly as the external interface (contract) for your service?
At the risk of being overly blunt - that's a terrible idea. It is a fundamentally flawed architectural choice.
Services are constructed to expose an immutable contractual interface. Changing that interface should take a concious effort or act, because such changes will break consumers (as you've discovered).
Architecturally, who would want to tie the internal implementation (your objects) to this immutable contract? You can't ever change your object model without breaking the contract - which means you can't ever change your object model. Which means you can't evolve or maintain your application.
A service is a type of interface - no different from a web or Windows interface. No one ever exposes their objects directly through those interfaces - they always have UI code (or data binding) between the interface and the object model.
The exact same thing applies to a service interface. You should never expose your objects directly through a service interface either. You should always have some UI code (or data binding equivalent) between the interface (contract) and the object model.
Certainly CSLA doesn't guarantee it'll maintain the same interface for meta-properties (like BrokenRulesCollection) over time. I try to avoid breaking UI code, but the idea of exposing objects directly as the interface is way outside of any scope I'd consider (mostly because you can probably tell how I feel about doing such a thing :) ).
Copyright (c) Marimer LLC