diff --git a/plans/business-logic-fed-flows.md b/plans/business-logic-fed-flows.md
index dcc5babc..4a019775 100644
--- a/plans/business-logic-fed-flows.md
+++ b/plans/business-logic-fed-flows.md
@@ -1,8 +1,31 @@
-# Business logic as federated composition-flows
+# Business logic as composition — a content-addressed DAG over pluggable substrates
 
-**Vision:** business logic is part of an object's composition — declared on its **type**,
-alongside content grammar + allowed relations. State changes federate over fed-sx; federated
-services execute the business logic as durable **flows**.
+**Vision (elevated 2026-07-02):** business logic IS art-dag. An object's behavior is a
+**content-addressed DAG** (lib/artdag), declared on its **type** alongside content grammar +
+allowed relations. Everything else is a pluggable ADAPTER — the same fold/adapter principle as
+render-vs-execute-vs-deps, applied to execution/communication/deployment:
+
+- **Behavior = an artdag DAG** — the invariant, content-addressed (`artdag/dag`, analyze/plan/
+  optimize/schedule). Business logic, art media pipelines, workflows — all the same abstraction.
+- **Execution = an injected RUNNER** (`artdag/run dag RUNNER cache`; `artdag/op-table-runner`).
+  Substrates are just runners: SX op-table (synchronous/local), Erlang (durable — suspend/resume/
+  wait), Celery/JAX (heavy compute, artdag/l1), … **Durability is a runner capability, not a DAG
+  feature** — the same DAG runs eager or durable depending on the runner.
+- **Communication = an injected TRANSPORT** (`artdag/federation`, transport injected). Substrates:
+  fed-sx (ActivityPub/next/), internal HMAC HTTP (services), IPFS (content-addressed). Because
+  content-ids are global, a result computed on one instance is reusable on another by id.
+- **Deployment = PLACEMENT** — a subdomain service, a fed-sx peer, an L1 worker: just where a
+  runner runs. Not the essence.
+- **State change → triggers a DAG** (over a transport) → executed by a runner → effects (data) a
+  driver dispatches. fed-sx + Erlang is ONE adapter set (durable/federated), not THE architecture.
+
+So: the TYPE carries content-grammar + allowed-relations + a **behavior DAG (+ triggers)**; the
+object's state changes emit activities; the platform picks runner/transport/placement per context.
+
+**Prior narrower framing (kept below as the concrete first slice):** wire the live host's publish
+onto next/'s Erlang trigger→flow machinery. That's now understood as *one adapter choice* — a good
+concrete spike, but P0 should keep the DAG + the state-change event substrate-CLEAN so runners and
+transports swap trivially.
 
 **Design (decided 2026-07-02; corrected after review):**
 - **Activity log = every OBSERVABLE object-level state change** — the federated event source.