At several places, you refer to things which are "TBD". In some cases, I'm not sure whether they will be determined by you (or Robert, etc) based on some hard thinking as part of putting this document together, or whether they will be the result of research or experimentation during construction. Where it's the latter, we should call them out.
I believe all of these are research projects (or at least "thinking projects" that we'll need to plan for, not complete prior to planning). I'll update the text to clarify.
Related to the above, where there are decisions to be made during construction, it would be helpful to indicate how that decision should be made: is it driven by external factors (e.g. availability of Gaia catalogues), by research time that needs to be scheduled, etc?
I'll try to add annotations to this effect.
How robust is this design against algorithmic components that don't come up to scratch? Would failure to deliver some component operating at some level of performance cause major changes to plan?
I'm afraid it's not robust at all, but I think it generally gets more robust the deeper we get into the production. Essentially, we have a lot of iterative procedures that re hard to bootstrap, and that tends to put a much bigger burden on whichever of the components we choose to start with. If one of those components doesn't work out, the best response may be to restructure the pipelines to put some other component first.
Related to the above, we should attempt to capture performance & fidelity requirements for algorithms wherever we can.
I agree this is important (and I'm sorry I keep forgetting about it), but I'm hoping we can mostly defer figuring out success criteria until the designs themselves are better described (just because this would be enough extra work for me that I don't think I can get it all done by zivezic's deadline).