I'm growing my understanding of event sourcing.  My understanding is that it provides a means of recording events as they happen so that given a common beginning state and an audit log of recorded events, the events can be replayed to achieve the same final state.I know that sometimes events are triggered by other events.  When I consider a system as a whole, I imagine that some events will be triggered externally by inputs from the user or another external source and that other events will be triggered and processed internally as side effects.  I am calling the former originating events and the latter secondary events.   Originating events trigger a domino effect of secondary events.  Since secondary events hinge directly on some originating event, should secondary events be recorded as part of the audit?  If you're aware of some source that discusses this in depth please cite.
At what granularity are events recorded in Event Sourcing?
design patterns;event sourcing
I think you're mixing up event sourcing and command sourcing. There is crucial difference between them. With command sourcing, you register external commands, like user inputs. In event sourcing, you register effects of those commands, i.e. what you've called secondary events.In practice, you should choose either command or event sourcing and stick to it, not combining these 2 approaches. As for which one to choose, it seems that industry consensus is skewing towards event sourcing. For example, in Akka, the Akka Persistence module is based on event sourcing. Main idea behind choosing event sourcing over command sourcing is that former allows for idempotency. I.e. however many times you replay the effects of your operation, your system would end up in the same state, while with command sourcing you're trying to rely on a fact that same command executed at different time would produce the same effect, which is, needless to say, is incautious.