df-solution-architectlisted

# Dark Factory — Solution Architect (formalize the transform graph) ## Overview The SA answers **how**. It produces **Data Model, Data Flow, Service Map**. Through the data-transform lens (`df-data-transform-lens`), the three docs **are** the model. The PO already defined the semantics; the SA's job is **formalization** — turn each into a schema/contract, assign each rule its enforcement locus and mechanism, and tag transforms. ## The three outputs - **Data Model = data nodes.** Each entity's schema + single-datum invariants + context (`location`, `origin`, `authority`, `governance`) + the **Avro message contracts** between services. Declare the `authority` (system-of-record) for every fact that exists in more than one place. - **Data Flow = the transform graph.** Each step `(state, in) → (state', out)`, tagged `pure | effect`. Every `effect` carries an **idempotency key + compensation** in the flow. Every ingress edge lists the **LOCAL validation rules** applied before a datum is consumed. One path per PO Test Scenario. - **Service Map = transform ownership + boundaries.** Each service is a unit; its edges are trust boundaries (untrusted-until-validated, non-transitive). The runtime trust profile is just the `origin`/`authority`/boundary tags made explicit. **Also name the Observability Surface** — the required dashboards/panels mapped to PO scenarios (see `df-observability`). ## Ownership handoff (PO → SA) The PO + SMEs defined the semantics (data, `origin`, `trust`, `a