Add CLI integration section

Co-authored-by: Russell Bryant <rbryant@redhat.com>
Signed-off-by: Mark McLoughlin <markmc@redhat.com>

Author: markmc

Diff for: docs/sdg/sdg-flow-yaml.md

@@ -104,7 +104,35 @@ TODO: figure out how we want to handle these.
 Custom pipelines may have more unique model serving requirements. Instead of serving just one model, we may need to launch the model server with a model and an additional model with adapter.
 
 How should this be expressed in a flow configuration? Can it be inferred, or are explicit options needed?
+### CLI Integration
 
+As of the current version of `ilab`, it supports `simple` and `full` as parameters to `--pipeline` to select one of the two types of built-in pipelines included in the library. Once we have support for loading custom pipelines, we need a way for these to be specified with the CLI. Here is a proposed CLI UX for this:
+
+> `ilab data generate`
+
+Use the default pipeline, `simple`.
+
+> `ilab data generate --pipeline full`
+
+Use the built-in `full` pipeline.
+
+> `ilab data generate --pipeline full --pipeline-extend path/to/config.yaml`
+
+Use the `full` pipeline, but extend it with the pipeline defined in the provided config file.
+
+> `ilab data generate --pipeline none --pipeline-extend path/to/other_config.yaml`
+
+Do not use a built-in pipeline. Use only the pipeline in the custom configuration.
+
+### Future CLI Improvements
+
+A possible improvement would be to have a well-defined place on the filesystem where custom pipeline configs can be automatically loaded and included as options to the `--pipeline` parameter.
+
+For example, if the config format included new parameters, `name: full-extended` and `extends: full`, and the CLI discovered and loaded it automatically, we could support `--pipeline full-extended` without needing the additional `--pipeline-extend` option.
+
+`/usr/share/instructlab/sdg/` is a proposed location for this as a place for a distribution of InstructLab to include pre-defined custom pipelines, at least for Linux. See the [Filesystem Hierarchy Standard](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html) for more details on why this path is appropriate for this use-case.
+
+It would also make sense to support a configuration directory for user's own custom pipeline configurations. Assuming there is a base config directory, these could go in a `sdg` subdirectory. There is a separate proposal that discusses a proposed configuration location: <https://github.com/instructlab/dev-docs/pull/104>. Note this is separate from the distribution-provided, read-only pipelines discussed above with a different location.
 ## Alternative Approaches
 
 Alternatives already considered and discarded are listed below.