DEC-0057 — Capability→delivery (delivered_by) grounded via a deterministic practice→workflow bridge

Context

The RBA reference tenant (clients/rba/tenants-firecrawl/rba-consulting) reached conformance-clean + graph-clean at commit 8229530 (Dossier — Decision & Audit Log 2026-06-19; the dedup keystone 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 and the FDE QA surgery), but was not full reference quality: the DXA capability.delivered_by edge — the associative "which delivery workflow realizes this commercial capability" edge (The produces edge is canonical on the producing process only reserves produces to a process, so this edge is deliberately associative; it is a registry-driven vertical edge per OKF edge vocabulary is registry-driven — a vertical declares its own traversable edges) — was grounded on only 8/187 capabilities. The cause was structural, not a missed edit: RBA capabilities are modeled as relates_to practices/disciplines, not the delivery workflows/processes the edge expects. This was carved out of the accountability-spine surgery (Have extraction populate the accountability spine (owner / reports_to / members / decision_rights)) and routed to the Principal Knowledge-Format Architect as Close the RBA delivery-modeling taxonomy gap — capability→delivery `delivered_by` grounding + two persona-role cleanups, because closing it looked like it needed LLM-grade inference rather than a mechanical remap — i.e. possibly an extraction-capability change, not data surgery.

On inspection the realizing workflows turned out to be a small, enumerable set of named atoms (~6), and the bridge from a capability to its delivery workflow already exists in the atoms — via each capability's relates_to practice, plus a few prose-named workflows. That reframes the question (the explicit decision below): is grounding delivered_by at scale an extraction-loop change or a one-time curation pass?

Options considered

1. Leave delivered_by at 8/187. Rejected: the delivery spine is the DXA vertical's reason for existing; leaving the capability→delivery layer unwired makes the tenant conformance-grade but not reference-grade, and the gap was already filed as the honest remaining blocker.
2. Teach the extraction loop a capability→workflow inference pass (an extraction-capability change). Rejected for RBA: the realizing workflows are ~6 enumerable named atoms and the practice→workflow bridges already exist in the atoms, so the mapping is deterministic given a table — paying for LLM-grade inference (and its faithfulness risk) here would be over-engineering. (This option is not foreclosed for a future tenant where the realizing workflows are not enumerable; this decision scopes the RBA answer, not a permanent loop policy.)
3. A one-time deterministic CURATION pass over an explicit practice→delivery-workflow bridge table (chosen). Map each capability's existing relates_to practice/discipline (plus prose-named workflows) to that practice's declared delivery workflow, source-traceable and re-runnable, fabricating nothing.

Decision

Ground capability.delivered_by on the RBA tenant by a deterministic practice→delivery-workflow bridge — a one-time curation pass, NOT an extraction-loop change.

• Bridge. Each capability's existing relates_to practice/discipline (plus prose-named workflows in the capability's body) maps to that practice's delivery workflow via an explicit bridge table.
• Two-tier precedence. Discipline-specific delivery workflows take PRECEDENCE over the universal rba-project-delivery-lifecycle: rba-ux-design-process, rba-envision-create-deliver, digital-workplace-implementation-workflow, rba-ma-integration-workflow, and office-365-exchange-online-migration-workflow win over the lifecycle when a capability's practice maps to one of them.
• Union + dedup + precedence when a capability relates to multiple practices: take every mapped workflow, dedup, and apply the discipline-over-universal precedence.
• Delivery / engagement models map to the lifecycle only when project-services-flavored; staff-aug / co-delivery-alone and managed-services map to empty (they are not project-delivery workflows).
• No bridge → empty, never fabricated. A capability whose practice has no declared delivery workflow keeps an empty delivered_by. Faithfulness over coverage (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, Dossier — The Knowledge Model (v0) principle 8).
• Conformance fixes folded in (8 pre-existing non-conformant edges, knowledge re-homed not deleted):
  • 7 industry verticals carried delivered_by: [rba-consulting] (a client/org, not a workflow — a category error for an associative delivery edge) → re-pointed to relates_to: [rba-service-delivery-model].
  • expert-staffing carried 12 consultant-* roles under delivered_by → moved to relates_to. Roles staff work; they do not deliver it — delivered_by points at the workflow/process, not at the people.

Rationale

• Curation, not a loop change, because the inputs are enumerable and already present. ~6 realizing workflows and bridges that already live in the atoms make the mapping deterministic given a table — exactly the case where a one-time pass beats an inference loop. This is the same judgment DEC-0056 applied to dedup (a deterministic, source-grounded transform over LLM fuzziness) — here applied to delivery modeling.
• Faithfulness over coverage. The empty-when-no-bridge rule and the staff-aug/managed-services → empty calls keep the edge true: 88 grounded edges and 99 honestly empty capabilities, with zero fabricated delivery edges. A fabricated delivered_by would silently assert a delivery path that does not exist — worse than a visible gap (Adopt OKF as Dossier's canonical knowledge format provenance; Dossier — The Knowledge Model (v0) principle 8).
• Edge semantics stay clean. delivered_by is associative (not produces, per The produces edge is canonical on the producing process only) and points capability→workflow; re-homing the 12 consultant-* roles to relates_to and the 7 verticals to relates_to: [rba-service-delivery-model] removes category errors (a client and a role are neither of them a delivery workflow) without losing the knowledge.
• confidence: verified — field-applied + measured, not asserted. Unlike a design conviction, this model decision was applied to live data and measured (the same bar DEC-0056 met): the Knowledge-Extraction & GraphRAG Engineer applied the bridge on the RBA tenant (chain 8229530 → tenant commit d9865f2) with the result delivered_by 9/187 → 88/187 grounded, 99 honestly empty, validateGraph 0 issues / 0 dangling (no regression), parse 444/444. The promotion gate is met by measurement.

Consequences

• The RBA delivery spine is grounded (88/187) and conformance-clean — capability→delivery is now traversable in GraphRAG for the 88 capabilities the source grounds. This closes Close the RBA delivery-modeling taxonomy gap — capability→delivery `delivered_by` grounding + two persona-role cleanups (AC1, AC4, AC5).
• ~99 capabilities remain honestly empty — by design, not omission: no declared delivery workflow exists to bridge to, or the capability is staff-aug / managed-services. This is the faithful state; a future tenant-curation pass can extend the bridge table if RBA declares more delivery workflows, but inventing edges to hit "100% delivered" is explicitly out of bounds.
• Bridge table is tunable curation DATA, not a contract. The practice→workflow mappings, the discipline-over-universal precedence, and the delivery-vs-engagement-model split are re-runnable policy (two-way door). The durable commitments: delivered_by is grounded by an explicit, source-traceable bridge (never fabricated); discipline-specific beats universal; no-bridge → empty; roles staff via relates_to, never deliver via delivered_by.
• A sibling type-discipline gap remains open — six client-specific atoms mis-typed as workflow (single-client SOW instances that should be DXA engagements) are filed as Re-type 6 client-specific RBA `workflow` atoms as DXA `engagement`s (single-client SOW instances, not standing orchestrations), routed to the Knowledge-Extraction & GraphRAG Engineer (the same type-discipline class as Fix extraction type-discipline — `system` used as a catch-all + non-slug ids (RBA run)). So the tenant reads "delivery spine grounded + conformance-clean," not "fully done."
• clients/ is gitignored (Fix git-per-tenant isolation when a tenant root is nested inside another repo), so the 9→88 measurement and commit d9865f2 live in the tenant's own isolated repo, not this repo's history. This record is the durable account of it.

Review

This record is confidence: verified — field-applied + measured on a real tenant (RBA, delivered_by 9/187 → 88/187, 99 honestly empty, validateGraph 0 issues / 0 dangling, parse 444/444; tenant commit d9865f2). The promotion gate is met. Revisit the bridge table (not the policy) if a future tenant's realizing workflows are not enumerable — at which point reconsider Option 2 (a capability→workflow inference pass in the extraction loop) for that tenant specifically; the empty-when-no-bridge and faithfulness-over-coverage commitments carry across either mechanism.