docs

docs/getting-started/index.md

@@ -1,9 +1,8 @@
 # Pick your starting point
 
-Setup differs depending on what you are here for. Pick the path that matches.
-
-Pick the one that sounds like you. Everything past this section is the same for
-both.
+Choose the setup that fits your work.
+Both paths lead to the same Fluksio engine, with a first flow to try along the way.
+This is really just about a decision what you're planning to do with Fluksio.
 
 <div class="fluksio-lanes" markdown>
 
@@ -11,13 +10,13 @@ both.
 
 ### Data science
 
-*"I have a training script. I want to stop losing track of what I ran."*
+*"I have some Python code. I want to keep track of what I ran."*
 
-One `pip install`, one command, and you are writing Python again. No Docker, no
-database, no ports to open. Flows are files, runs are rows, and the metrics are
-just the numbers your loop already produces.
+Install Fluksio with pip in your research environment. Turn a function into a
+node, record metrics and artifacts, and compare experiments. Connect to
+[fluksio.com](https://fluksio.com) for the browser dashboard.
 
-[Set up for experiments →](data-science.md)
+[Start with Python →](data-science.md)
 
 </div>
 
@@ -25,46 +24,20 @@ just the numbers your loop already produces.
 
 ### Facility automation
 
-*"I have a homelab and a pile of sensors. I want them to do something."*
+*"I have a bunch of sensors. I want them to do something."*
 
-A stack you bring up once and leave running: the engine, a broker, a
-time-series database, dashboards, alerting. Most of the work happens in the
-browser, and it is worth doing properly because you will live in it.
+Start the Docker stack for a local engine and browser interface. Build a live
+flow, connect your devices, and put their values on a dashboard.
 
-[Set up a homelab instance →](facility-automation.md)
+[Start with Docker →](facility-automation.md)
 
 </div>
 
 </div>
 
-## Not sure?
+## Next steps
 
-Some rough tells:
-
-| | Data science | Facility automation |
-|---|---|---|
-| **The flow** | starts, finishes, has a result | never ends |
-| **You mostly** | write Python | wire nodes in the browser |
-| **Time to first result** | a few minutes | an afternoon |
-| **Runs on** | your laptop, or a login node | a box in a cupboard |
-| **Data lives in** | SQLite beside the flows | InfluxDB, usually |
-| **The thing you look at** | run history and loss curves | a dashboard, maybe on a wall |
-
-If both describe you (a lab with instruments to drive *and* models to fit),
-start with the data-science path. It is the smaller instance, and it
-grows into the other one without being reinstalled: the same engine, the same
-flows, just more of them running all the time.
-
-## What is the same either way
-
-Whichever door you came in:
-
-- **Flows are files in a git repository.** Every save is a commit. You can read
-  the history with ordinary git, and you can copy a flow between instances
-  by copying a directory.
-- **Editing is separate from running.** You edit a draft; the engine keeps
-  running what was published until you publish.
-- **Nodes are typed.** A port declares what it carries, and a mismatch is
-  caught at edit time rather than at three in the morning.
-- **Everything the browser does is an API call.** The dashboard is a client of
-  the same REST API you can script against.
+- [Flows, nodes and messages](../concepts/flows.md) explains the graph.
+- [The flow editor](../interface/flow-editor.md) covers editing and publishing.
+- [The command line](../code/cli.md) covers local and remote use.
+- [Configuration](../reference/configuration.md) lists settings and data paths.