Design datastore persistence based on state of the Entity I have an entity Content to persist in the database. The entity has an attribute LifeCycleState that denotes the present state of the content.

For the sake of elaborating further, assume we have DRAFT, REJECTED, ARCHIVED life cycle states. Corresponding to each of these, there is some detailed information that is supposed to be persisted in the database. Such as:

DRAFT {creationDetails}
REJECTED {creationDetails, updateDetails, rejectReason}
ARCHIVED {creationDetails, updateDetails, archivalReason}


Moreover, we are currently using a NoSQL datastore(mongodb) to persist the Content entity.

The question here in terms of designing the schema is based on the fact that the content would be in one state at a time, which is when any other state information would be useless to read. 

For example, a content moves from state DRAFT to REJECTED to ARCHIVED, the users would just be interested in the archivalReason and would not worry about the intermediate state. [Not of interest to the question, there is a status change history that we are persisting anyway for bookkeeping the writes.]

Our current implementation defines an attribute stateSpecificDetails under Content and dumps all the attributes pertaining to various states within it, but that seems like an unwanted clutter to a single attribute knowing the fact that only one of such attribute would actually be set based on the state transitions. 

Is there are a cleaner way of defining the entity or creating a separate collection for such content state based persistence?
Mongo allows the content of a record to change. You can add any values you need and remove any you don't each time you persist a record.

The application could have an object class for each state. To mutate a record read it into an instance of whatever class corresponds to its current state. Then map the values you intend to retain to an object of the new state. This new-state object will not have attributes for the values which are no longer relevant. Now persist the new object. The on-disk representation will have only those values applicable to the new state.

Whether you have a collection per state or hold all the records in a single collection is, to a large extent, an operational concern. One risk with separate collections is that the system may fail after the new record is written but before the old one is removed, leaving duplicates. You'll need some clean-up logic on start-up to account for this.