Documenting future products

shared/workspaces/workspaces/ARCHITECTURE.md

@@ -104,3 +104,18 @@ external-execution-block-id future product; it begins life unresolved.
    
 5. The capability system receives the event and matches to the request in the AWAIT PRODUCT state. The step is now 
    complete and the engine advances the request to the next step.
+
+
+## Notes from call with Nathan
+
+- Capability Request could have type Filesystem -> Filesystem
+- Future Product system could become Product system, adopt responsibility for running the data fetcher or doing copy 
+  from earlier request to follow-on request
+- How do we deal with capabilities that do not need files retrieved? They don't have AWAIT PRODUCT at the outset
+- How do we deal with capabilities that ingest or are otherwise final? They still have a working directory at their 
+  conclusion which can be used as an input to the next request
+- TODO How do we handle requests that need to fetch multiple things before executing? Restores, for instance,
+  need to retrieve the data AND retrieve the calibration tables? Open question. 
+   - Multiple AWAIT PRODUCTs? Or Product System is parameterized by a list of products?
+   - What about follow-ons that also need to request data? Think CIPL -> image
+