Voltfeld — example organization
A fictional maker of EV charging hardware, described in DWSD: an AC Wallbox line and a DC Charger line, developed by one Agile Release Train of three product lines, built in a plant, sold and serviced by a commercial department — about 120 people, of whom this folder models the thirty-seven that carry the structure. It is the second worked example next to the Goldcrust Bakery; where Goldcrust is small enough that the line and the work almost coincide, Voltfeld is the example where they do not.
New here? Take the tour — eight stops, fifteen minutes: one engineer in two pictures, a platform that serves two product lines, the train’s board, a route that stops at the plant, two signals and a decision, the decision in two agreements, an agent that prepares while people decide, and an order process with a factory and a studio. If this is your first DWSD example, start with the Goldcrust tour instead — it is smaller.
Fictional and public-safe. Names and numbers are invented.
Partially SAFe-inspired
Voltfeld has borrowed several ideas from SAFe without adopting the framework: product development runs as one Agile Release Train (Charger ART) on a ten-week Program Increment cadence, facilitated by a Release Train Engineer; Product Management ranks a feature backlog that two product owners split into team backlogs; a System Architect keeps the runway; four Business Owners represent the portfolio at PI planning. The rest of the company — the plant, the supply base, sales, field service — works outside the train, and that seam is where this example is interesting.
DWSD describes this the way it describes any organization: the ART is a unit with
unit-type: [ART, work-system] at FL2; its three product lines are work systems at FL2 beside it, each
coordinating two teams that are plain units without a flightlevel; the portfolio is the FL3
work system above. SAFe terms appear where Voltfeld uses them; nothing in the format depends
on them.
SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.
Flight-level map
The whole company, from the Portfolio down. Manufacturing contributes straight to the Portfolio, beside the train, not inside it.
The same map as plain text (renders everywhere, even without the DWSD renderer)
FL3 Portfolio ◄──────────────────────────────────────────────┐ ▲ contributes-to │FL2 Charger ART ◄──── Wallbox DC Charger Connectivity │ plans, syncs, ▲ ▲ ▲ ▲ ▲ ▲ ▲ │ releases per PI │ Home Fleet Power Site Backend App │ │ └── six teams, not work systems ──┘ │FL1 System Integration Manufacturing HW Base ─────────► Wallbox, DC Charger contributes straight up Firmware Platform ► Wallbox, DC Charger, Connectivity to FL3: development and production share no FL2 Supply Chain · Sales · Field Service — plain teams (no flightlevel)
FL2 Order to Delivery ──► Portfolio the order process: factory in the ERP, studio around itTwo things to notice:
- Two platform work systems contribute to more than one. HW Base
feeds both hardware product lines; the Firmware Platform
feeds those two and Connectivity.
contributes-tois a list, and the edges run up from FL1 to FL2. One level higher they run sideways: the three product lines contribute to the Charger ART on the same level, and the train coordinates across them — allowed, as long as nothing contributes downward. The six teams under the product lines are plainunit-type: teamunits withcontributes-to, not work systems: they have no flightlevel and no board of their own; the Wallbox Board gives each Wallbox team a lane. - Manufacturing has no FL2. The plant is a work
system — it coordinates a flow every day — but it is not in the ART. Its output is
steered from the Portfolio directly. The ART coordinates development; the COO coordinates
production; they meet at FL3. That gap is the as-is this example describes, and it is
the one that
member-ofandcontributes-todisagree about: Manufacturing belongs to Operations and contributes to the Portfolio. - Order to Delivery belongs to no department. It is the work system around the order process — people from Sales, Manufacturing and Supply Chain share it, and nobody reports into it. See Factory and studio below.
Two trees, not one
The line and the work are two different pictures here, drawn from two different frontmatter keys of the same files.
The org chart — reports-to, individuals only. Engineers report to the heads of
Hardware Engineering and
Software Engineering, who hire, develop and review them:
The units — member-of, units only. The same engineers are members of the six
cross-functional teams inside the train’s product lines; the two engineering departments appear as boxes with no team
inside them, because nobody works there — their line chip says so:
(focus + radius: { up: 0, down: inf } mean “this root and everything below it”. The
renderer indexes the whole workspace, and this repository holds two example organizations
— without the scope, both roots would appear side by side. The dashed ring around the
outer box marks the focus. Open one example folder as its own workspace and the two keys
become redundant; they are kept because they say what the picture is of.)
Follow one person through both: Daria Novak reports to Kaspar Reinholt (org chart, under Hardware Engineering) and works in Wallbox (units, inside the Charger ART). Both standalone views live at the org root: Voltfeld Org Chart.dwsd-orgchart and Voltfeld Units.dwsd-units.
In Operations and Commercial the two trees agree — people work where they report. The difference is confined to engineering, which is exactly what an ART does to a line organization.
Agents at sub-process level
Three ai-agents/ work inside the flow, each bound to a part of a board
rather than to a single column. The DFM Check Agent
is bound to the whole Verification column group of the HW Base board
(group:Verification::in); the Release Dossier Agent
to the Release group inside the ART board’s feature lane
(lane:Feature/group:Release::in); the
Field Issue Triage Agent sits ::before
the Triage column of the expedite lane — the queue in front of the column, not the column.
Each also anchors to a person or a unit, so the same agent shows on a box in the org chart
or the units view. In every case the agent prepares and the people decide.
Factory and studio
Most of what a company does with a customer order is defined in its ERP and runs there without anyone touching it. Order to Delivery is the work system around that process, and the Customer Order Route shows how: two bands without a flight level stand for two work modes, not two places.
ERPis factory mode — order entry, scheduling, production order and invoice, run by the system of record. The route’ssources:block points at the ERP process; the band is bound to no board, because the ERP is where that state lives.Studiois studio mode — the seven orders in a hundred that do not go through. The Order Exception Agent, bound to the factory stage, flags them and prepares the case; people work it on the Order Studio Board; the clarified order flows back.
The edge into the studio is an andon cord, and the Order Andon says who answers it within what time. The reason code every case leaves with feeds the monthly Order Exceptions Review — the improvement loop that used to be a ticket queue — and from there the ladder: Configuration Cases Pile Up in the Studio is the factory’s view of the variant the platform keeps declining.
None of this needs a new type. A route, two bands, a board, an agreement, an agent and a signal are enough. The board is not the workflow: the workflow is in the ERP; the board is where the people meet when it does not work.
How to read this folder
- One file = one entity; the
type:in the frontmatter decides what it is. - Files are grouped into flat per-type folders (
individuals/,roles/,work-systems/, …) — the folder is a convenience, thetype:is authoritative. - Relationships are
[[wikilinks]]to other entities. - The
```dwsd.topology,```dwsd.orgchartand```dwsd.unitsblocks are inferred views — they list no people and no units, only where to look (focus) and how far (radius); rename a file or move areports-toand the pictures follow. All three are optional extras; an entity is complete without them.
Entry points
- Structure —
work-systems/: ten work systems; the Charger ART and HW Base carry the fullest domain descriptions.units/holds the company root, four departments, three plain teams outside the train and the six teams of the product lines.roles/holds the ART roles, the Manufacturing Lead and the Production Liaison — two roles one person keeps in two contexts — including Business Owner, a role shared by four keepers.individuals/: thirty-seven people, one of them the vacancy NA1. - Flow —
visualizations/: six boards. The Charger ART Board is the train’s program board (timebox: 10w) with a feature lane in three column groups and an expedite lane for field issues; the HW Base Board runs hardware work throughDesign→Verification→Release; the Portfolio Board is the FL3 epic kanban; a team board and the Manufacturing Board — which nothing on the ART board points at — and the Order Studio Board, which shows only the orders that need people, complete the set.flight-routes/holds four routes, one per item type, each a different pattern: the Epic Route (top-down, FL3 → FL2), the Feature Route (one PI, ending with a release copied to the plant — and no edge back), and the Field Issue Route (bottom-up from a band with no flight level, forking into hotfix or feature), and the Customer Order Route (factory mode in the ERP, studio mode around it);flight-item-types/defines what flows.interactions/holds the ART’s cadence — PI Planning, ART Sync, System Demo, Inspect and Adapt — the monthly Portfolio Sync, the weekly Field Issue Triage, two unscheduled ones — the DFM Review, called when a tooling release approaches, and the Safety Issue Call, triggered by a field report with a safety risk and anchored on a route stage — the daily Order Studio Huddle, the monthly Order Exceptions Review and a 1-1; each scheduled one has a.mwsibling, aggregated in operating-rhythm.mw.agreements/holds five standing agreements, anchored on board positions (PI Commitment on a column group), on a board position and a route stage at once (Expedite Lane Policy on a lane and before the hotfix fork, Order Andon on a column and before the studio) or on entities (Platform Variant Rule on the two platforms and the System Architect role, DC Rig Booking on a team without a board). - Change — the ladder climbs from two
signals/(PI Objectives Missed on Enclosure Tooling Twice, Fixtures Built After the Release) through the insight, the driver and the proposal to the decision record Production Joins the Train’s Planning, which two agreements and one role operationalize viaderived-from: Long-Lead Commitment at PI Planning, Ramp Readiness Review and the Production Liaison. Decided 2026-10-06, in force from the next PI planning — so the as-is pictures above are still true today. A third signal, Variant Request Declined Three Times, is uninterpreted: the ladder starts there, unclimbed. A fourth, Configuration Cases Pile Up in the Studio, comes out of the Order Exceptions Review and points at the same variant from the factory’s side.
Like what you see? → Start — build your own org folder in ~2 min