Generated from smart-base/processes/content/l2-component-edit-review.bpmn by gen-processes-viz.ts — do not edit here. All processes

L2 component edit and review

Process_L2ComponentEditReview · advisory · 6 step(s)

One pass over one L2 DAK component: the agent edits it, runs its checker, renders and stages it with a before/after, and hands it on; review forks off beside that hand-on and never holds it up, because adjudication is QA, not a gate. That is the owner’s ruling of 2026-10-14. Called by each authoring track of l2-dak-authoring.bpmn (Process_L2Dak), one call per component pass.

The call’s inputs, which are the only things that differ between components (skill l2-component-edit-review, “The inputs, per component”):

• component: personas and user scenarios (C2, C3), business processes (C4), core data elements and glossary (C5) with their terminology bindings, decision-support and scheduling logic (C6, C7), indicators and requirements (C8, C9);
• authoring skill: l2-dak-authoring, bpmn-authoring, dmn-authoring or terminology-management, named on the calling activity, so it joins this process’s skills along the call path (review-task.bpmn’s scoped composition);
• renderer and diff: what the reviewer looks at, before and after;
• checker: the mechanical checks the agent runs before asking anyone;
• reviewing role: the person who takes on this process’s reviewer lane for the call.

One process rather than one per component because nothing but those inputs differs: DMN’s test cases are its checker, BPMN’s picture is its renderer, the glossary’s term diff (dak-data-dictionary-diff.ts) is its diff and its binding check its checker, and traceability to L1 is the checker of personas, scenarios and requirements.

How it connects

• Called by: L2 DAK authoring
• Calls: Review task
• Presented on: no docs page section shows this diagram

Lanes — who acts

lane	role	what it does here
Authoring agent	authoring-agent	Does everything except judge. Edits the component with the authoring skill the call names, runs the component’s checker, renders it and makes the before/after preview on a staged build, hands the component on without waiting, and asks for review with staging deep links. Prepares the review material and never records the verdict (smart-guideline-end-to-end, rule 4). On request-changes it edits again; on reject it reopens the stage upstream and flags what was derived from it.
Component reviewer (person)	reviewer	A person, never the agent, in the role the call names for this component: the clinical SME for business processes, decision logic, personas and scenarios; the terminologist for terminology bindings and the glossary’s codes, since the person who chose a code does not review it; the business analyst with the programme manager for indicators and requirements. Each takes on this generic reviewer lane for the call path only (review-task.bpmn), so the reviewer of a DMN table does not statically carry the terminologist’s skills. Reads the staged component, its before/after and its checker’s findings; the preview is made in the agent’s lane and only read here.

Steps

Every one of the 6 step(s) is documented.

step	lane	skill / sub-process	what it does
Edit the component Task_Edit	Authoring agent	l2-component-edit-review	Create or change the component with the authoring skill the call names (l2-dak-authoring, bpmn-authoring, dmn-authoring or terminology-management), one component per pass. On rework, apply the review’s findings; a fix the reviewer wrote in an AuditNote is applied as given. An adapted component is edited against its pinned upstream, so the before side of the diff is that upstream, not an empty file.
Run the component’s checker [content-validate · content-test] Task_Check	Authoring agent	content-validate content-test artefact-reachability	The mechanical checks for this component, before anyone is asked (skill l2-component-edit-review, column “checker”): BPMN imports in bpmn-js with no warnings and its lanes map to personas (dak-swimlanes.ts); DMN loads, its decisions are reachable (artefact-reachability, audit:reachability) and its test cases run (content-test); the data dictionary’s ids are unique and its references and terminology bindings resolve (check-dak-annexes.ts); personas, scenarios and requirements each trace to an L1 recommendation (recommendation-extraction’s implementedBy edges). Findings travel with the review request; a failing check does not stop the hand-on, it is a finding the reviewer sees.
Render, stage, before/after [before-after-preview · feature-staging] Task_RenderStage	Authoring agent	before-after-preview feature-staging	Render the component the way its reviewer reads it (column “renderer and diff”): the BPMN diagram (render:bpmn) with a visual-diff picture; the DMN decision table (smart-base-transform.py dmn2html) with each rule’s L1 citation; the data dictionary’s term diff (dak-data-dictionary-diff.ts) and the chosen wireframe of each form; personas, scenarios and requirements as a prose diff. Commit to the feature branch so it is staged as STAGING// on the platform's just-the-docs site (for smart-base, a folio-assistant staging re-pin, never the IG's /deploy), and make the before/after preview here, in the producing lane, so it exists when review starts.
Ask for review with staging deep links Task_RequestReview	Authoring agent	staging-review interaction-modality	Ask the person in the reviewing role, following staging-review’s deep-link rule: one deep link per changed page and anchor on STAGING//, each beside the same page on main as before (or "new page"), the pages taken from the change (rendered-impact) rather than chosen; no preview yet is said, not hidden. The request leads with what changed in prose, then the links, the before/after and the checker's findings, and puts its question in interaction-modality's form. Where it goes is a judgement, and more than one place may be right: this conversation, the GitHub issue the work came from, the pull request; each place carries the same links. A comment tagged on the PR becomes a review-comment todo (review-comments).
Review the staged component Call_Review	Component reviewer (person)	calls Review task content-review visual-diff l2-component-edit-review	cat-harness’s generic review, not a copy of it: classify what changed, review it, and record the decision as a qa-review/v1 QaReview whose subject is the component and whose Decision carries the reviewing role. The reviewer reads the staged page and the before/after; for a figure or table, the visual-diff picture and its changed-pixel count; for a form, the wireframe (wireframe-design-review; at L3 its Questionnaire follows fhir-questionnaire-wireframe). What to judge per component is the skill l2-component-edit-review’s column “the reviewer judges”.
Reopen upstream, flag derived assets Task_ReopenUpstream	Authoring agent	todo-manager l2-component-edit-review	File a bean against the stage that chose the rejected source or dependency (check for an existing bean first), and mark every asset derived from this component adjudication: rejected-upstream on its wasDerivedFrom edge. Nothing is deleted ahead of time: the re-derivation may come out the same.

Decisions

Every one of the 1 decision(s) is documented.

decision	what decides it	branches
Verdict? Gateway_Verdict	The reviewer’s recorded Decision outcome: approve ends the review; request-changes sends the component back to the edit, which re-stages it and asks again; reject means the component is wrong at the root (wrong source, wrong dependency) and reopens the stage that chose it. The calling track has not waited for any of these.	approve → Component approved request-changes → Gateway_Rework reject → Reopen upstream, flag derived assets