Re-type 6 client-specific RBA workflow atoms as DXA engagements

Surfaced by the Principal Knowledge-Format Architect during the Capability→delivery (`delivered_by`) is grounded by a deterministic practice→delivery-workflow bridge — a one-time curation pass, not an extraction-loop change delivery-modeling pass and deliberately held out of scope of that decision (which grounds delivered_by, not type-discipline). Six RBA tenant atoms are typed workflow but are single-client SOW instances — a named delivery RBA ran for one specific client — not standing process orchestrations.

The six mis-typed atoms

banner-bank-digital-transformation · bcu-digital-transformation-engagement · edina-realty-platform-delivery · fastenal-sales-operations-workflow · myturf-portal-development-workflow · nutrition-hub-ux-engagement-workflow

Why engagement, not workflow

The Dossier — The Knowledge Model (v0) is explicit: a workflow is the standing path-through-nodes (the org's repeatable orchestration); a one-off named delivery for a specific client is the DXA vertical engagement type (Digital Experience Agency vertical as the first reference implementation). Three of the six even carry the client name + "engagement"/"delivery"/"platform-delivery" in their id. They should re-type to engagement and wire the edges the type expects: client → the client atom, runs → the generic delivery workflow(s) the engagement executed (the same lifecycle/discipline workflows Capability→delivery (`delivered_by`) is grounded by a deterministic practice→delivery-workflow bridge — a one-time curation pass, not an extraction-loop change bridges delivered_by to), capabilities → the capabilities exercised.

Why a task, not a fix-in-place

This is the same type-discipline class as Fix extraction type-discipline — `system` used as a catch-all + non-slug ids (RBA run) (system used as a catch-all) — here workflow is used where engagement is meant. Re-typing six atoms and wiring client/runs/capabilities correctly (source-grounded, nothing fabricated) plus deciding whether the extraction path should make this distinction at emit time is a knowledge-model + extraction-layer judgment, not a one-token hygiene correction. Routed to the Knowledge-Extraction & GraphRAG Engineer (the type-discipline / emit-time owner, mirroring its sibling), with the Principal Knowledge-Format Architect confirming the type calls. Scoped to the RBA tenant OKF (clients/rba/tenants-firecrawl/rba-consulting, gitignored per Fix git-per-tenant isolation when a tenant root is nested inside another repo). Board globbed before filing — no open task covered the engagement-retyping (grep of the six atom names + "engagement-retype" returned only this task's own back-references). confidence: inferred (agent-filed).

Resolution (2026-06-19, tenant commit 975cc83; chain d9865f2 → 975cc83)

DONE via deterministic data surgery (no LLM re-extraction). The six mis-typed client-specific workflow atoms were re-typed to DXA engagement:

• 2 kept as new engagement nodes — banner-bank-digital-transformation; nutrition-hub-ux-engagement (re-slugged off its misleading -workflow suffix).
• 4 MERGED into their pre-existing same-SOW engagements per Concept identity = type + (canonical-title OR prefix-stripped id), exact-match closure — dedup owned by the @dossier/okf keystone, in-pass + opt-in reconcile + loop default (provenance + edges unioned, fuller body kept, no supersedes — an unmanaged near-dup is not a version chain): bcu-digital-transformation-engagement→rba-bcu-digital-transformation, fastenal-sales-operations-workflow→fastenal-sales-orchestration-engagement, edina-realty-platform-delivery→edina-realty-digital-platform-modernization, myturf-portal-development-workflow→rba-toro-equipment-maintenance.
• Engagement edges grounded in content. client/runs/capabilities wired only where the atom's own content grounds them; the orphaned stages/outcomes folded into runs + prose. Banner Bank's client and Fastenal's runs deliberately left UNSET for lack of grounding (no Banner Bank client atom; no faithful generic delivery-workflow for a CRM build) — honest, not fabricated (The produces edge is canonical on the producing process only associative; faithfulness over coverage).
• 14 inbound refs re-pointed (1 frontmatter edge + 13 body wikilinks), 0 stranded. parse 440/440 (100%); validateGraph 0 issues / 0 dangling (no orphan-artifact / dangling regression). Counts: workflow 15→9, engagement 14→16, total 444→440. Hero workflows/digital-workplace-implementation-workflow.md byte-identical/untouched.

confidence: inferred → verified (evidence: tenant commit 975cc83, parse 440/440, validateGraph clean). With this, the RBA tenant is type-disciplined, conformance-clean, and graph-clean — reference-grade on the tenant DATA. The remaining item is forward-looking: the durable emit-time type-discipline heuristic so future extractions don't need post-hoc curation, filed as Improve extraction EMIT-time type discipline for DXA vertical types (so future runs don't need post-hoc curation) (spans this engagement mis-emit + the system-catch-all root cause from Fix extraction type-discipline — `system` used as a catch-all + non-slug ids (RBA run)). Tenant lives in gitignored clients/ (Fix git-per-tenant isolation when a tenant root is nested inside another repo, local sandbox).