diff --git a/website/content/docs/cli.mdx b/website/content/docs/cli.mdx
index 51e07a7..9c76c67 100644
--- a/website/content/docs/cli.mdx
+++ b/website/content/docs/cli.mdx
@@ -193,19 +193,19 @@ Node input/output schemas are shown when defined.
 
 ## light doctor
 
-Check environment health.
+Check the environment and light-run connectivity.
 
 ```bash
 light doctor
 ```
 
 **Checks:**
-- Node.js version (>= 18)
-- Docker installation
-- Docker daemon status
-- gVisor (runsc) availability
-- GPU support (nvidia-smi)
-- Docker GPU plugin
+- Node.js version (prints `process.version`)
+- `LIGHT_RUN_URL` - decides the mode:
+  - **unset (all-in-one):** confirms the `light-run` binary is installed, since `light serve`/`light run` will spawn it automatically. Fails if the binary is missing.
+  - **set (explicit runner):** pings the runner's `/health` and fails if it is unreachable.
+
+Container-level concerns (Docker daemon, gVisor, GPU) live on the light-run host, not here - `doctor` only checks that light-process can reach a runner.
 
 ---
 
diff --git a/website/content/docs/getting-started.mdx b/website/content/docs/getting-started.mdx
index 7b02a58..2846252 100644
--- a/website/content/docs/getting-started.mdx
+++ b/website/content/docs/getting-started.mdx
@@ -2,6 +2,8 @@
 title: "Getting Started"
 ---
 
+The mental model in one breath: a **node** is a Docker container that reads JSON on stdin and writes JSON out, a **link** is an arrow that passes one node's output to the next node's input, and a **workflow** is the graph (`workflow.json`) wiring them together. That is the whole model - everything below is just creating nodes, linking them, and running the graph. The full reference is in [Workflows](workflows).
+
 ## Requirements
 
 - **Node.js** >= 20 ([download](https://nodejs.org))
@@ -99,6 +101,26 @@ light run example --input '{"name": "Alice"}'
 -> {"hello":"world","input":{"name":"Alice"}}
 ```
 
+## Run from code (`main.js`)
+
+`light init` also dropped a `main.js`. It does exactly what `light run example` does, but from JavaScript via the SDK instead of the CLI - this is how you embed light-process inside a real app:
+
+```js
+import { LightRunClient, loadWorkflowFromFolder } from 'light-process';
+
+const wf = loadWorkflowFromFolder('./example');
+const result = await wf.execute({}, { runner: new LightRunClient() });
+
+console.log(result.success ? 'Success' : 'Failed');
+console.log(JSON.stringify(result.results, null, 2));
+```
+
+```bash
+node main.js
+```
+
+The CLI is for iterating; the SDK is for integrating (build graphs in code, hook `onNodeStart`/`onLog` callbacks, expose workflows over HTTP). See the [SDK Guide](sdk) for the full surface.
+
 ## Validate a workflow
 
 ```bash
diff --git a/website/content/docs/workflows.mdx b/website/content/docs/workflows.mdx
index 07856d2..480c51d 100644
--- a/website/content/docs/workflows.mdx
+++ b/website/content/docs/workflows.mdx
@@ -139,6 +139,10 @@ Without `maxIterations`, adding a cycle throws `LinkValidationError`.
 
 ## Run-scoped networks (`networkDefs`)
 
+<Callout type="info">
+Everything from here down (`networkDefs`, services/sidecars) is advanced. Skip it for your first workflows - nodes and links are enough to build real graphs. Come back when you need a node to reach a database, a proxy, or a provider behind a secret.
+</Callout>
+
 A bare name in `networks` must already exist on the light-run host, or the run fails. `networkDefs` lets a workflow declare networks it wants **created for the duration of a single run and destroyed afterwards**, so you never manage Docker networks by hand.
 
 ```json