Generated from smart-base/skills/content/authoring-who-smart-guidelines/l2-dependency-choice.md — do not edit here.

✎ Edit this page’s source

l2-dependency-choice

Skill id: l2-dependency-choice · Package: authoring-who-smart-guidelines · Stage 3 of smart-guideline-end-to-end, task Task_DepsL2 of smart-guideline-end-to-end.bpmn. Adjudicated by the programme manager and the business analyst.

A dependency decides what the guideline inherits, so the choice is an asset in its own right and is adjudicated like one.

Input and output

The contract is input.schema.json and output.schema.json.

• In: stage 2’s l1Kg (recommendation-extraction’s output), and the candidate DAKs already known (candidates: packageId, version, uri, publisher).
• Out: l2Dependencies: one dependencyRow per candidate, rejected ones included, the gaps, the comparison table and the decisionRequest. Stage 4 (l2-dak-authoring) takes it as its l2Dependencies.

The decision row

field	from	meaning
packageId, version, uri	cat-harness DependsOnRecord (schemas/depends-on.ts), the same three fields as FHIR ImplementationGuide.dependsOn	the candidate DAK (or, at stage 5, IG). A candidate missing one of the three is a DependsOnGap, listed in gaps, not a row
publisher, upstream	—	WHO, or the adapting jurisdiction; for an adaptation, the WHO original it adapts
evidence	smart-base KG evidence (smart-base/kg/src/graph.ts)	the L1 KG nodes (and, at L3, the L2 assets) that point at it
decision	this skill	reuse (unchanged) · adapt (fork and change) · extend (depend and add) · reject
reason	this skill	one sentence; required for reject
components	—	what is taken, piece by piece: DAK components here, profiles, value sets and libraries at L3
toolchain	this skill	on each component reused, adapted or extended: how the candidate produces it — a Tool id from bun run cat check:tools, or a script in the candidate’s own repository (its source spreadsheet, converter, CQL refresh, test format), found by the search in smart-base-tools §Adapting a DAK. Stages 4 and 6 produce the component with that toolchain. none only after that search came back empty, naming where it looked; the new tool is then a Tool node, never a script in the adaptation repository

Only decision, reason and toolchain are new. Once adjudicated, a reuse, adapt or extend row becomes an ordinary dependency: the DAK’s own reference at L2, a dependencies: entry in sushi-config.yaml at L3.

Steps

1. Find the candidates. Start from candidates, and add each DAK whose Component 1 the L1 KG’s implementedBy / realises edges reach. For each, find how it produces each component it would give (smart-base-tools §Adapting a DAK): that is the component’s toolchain, which stage 4 uses.
2. Reuse first. This is the precedence recommendation-extraction already uses for personas and processes: reuse an existing asset, then adapt one, and create only when neither fits, with a WARNING saying none fitted. The same precedence holds for the tooling that makes an asset: an adapted decision table is an edited copy of the upstream’s source spreadsheet run through the upstream’s converter, not a table re-typed in a new format with a new converter (2026-10-15, Uganda). Prefer the jurisdiction’s adaptation over the WHO original when one exists for the same scope, because it already holds the local decisions. Record the WHO original too, as that row’s upstream.
3. Lay the rows out as a decision-comparison table and ask through a DecisionRequest (schemas/decision-request.ts: two to four options, a recommendation, and what happens if nobody answers).
4. Go on. Under the QA rule the agent proceeds with its recommendation; the adjudicator’s answer is the stage’s review decision.

Processes that run this skill

process	step(s) that name it
SMART Guideline end to end	3 · Choose L2 dependencies (WHO / jurisdiction DAKs)