Discussion: capturing processed data

_Spinning off from [this comment](https://github.com/APS-4ID-POLAR/ipython-polar/issues/42#issuecomment-765815133):_

For the most part, we intend processed data to go in a separate BlueskyRun, which may reference the BlueskyRun(s) with the original data. There are several reasons to put this in a separate Run rather than an additional stream in the original Run.

1. The data management for processed / derived / analyzed data may be different than that of raw data---for example, rules about who can access and how long it is retained in the system.
2. For any given raw data set, there may be multiple process / derived / analyzed data sets, and expressing this "one to many" relationship inside streams will get awkward.
3. Many part of the Bluesky infrastructure make the assumption that once a BlueskyRun is complete (i.e. once the 'stop' document is emitted by the RunEngine) that it will not change. This assumption simplifies a lot of things. Breaking it to add streams after the fact comes with a high complexity cost.

This is our working theory of how to capture analysis results in Databroker: https://blueskyproject.io/databroker/docs-rewrite-draft/how-to/store-analysis-results.html (Note: This link is to a _preview_ of new Databroker documentation that is being evaluated by some users. It will be moved to https://blueskyproject.io/databroker/how-to/store-analysis-results.html

One could then imagine queries like "Show me all the processed results for Scan ID X," or "Given this processed result, find me the raw data."

_However_ some analysis that can be done cheaply in real time during data acquisition and in a rote fashion that is highly unlikely to require _re_-processing with different parameters might be done in the Ophyd/Bluesky layer as part of data acquisition, and could be including in a stream in the original BlueskyRun. That particular case stays on the right side of points 1-3 above.

Start by reading the linked Databroker documentation preview and the originating comment in issue #42. The issue presents a working theory rather than naming files, tests, an implementation entry point, or acceptance criteria, so a concrete scope and definition of done would need to be established first.

Written by the indexing model from the issue text.