
Case study
The screen arrived before the system was defined
I built Design Dash, an open-source workflow that takes a fuzzy problem to a plan a team can build from. A generated interface is not that plan.
- Role
- Author and facilitator
- Form
- Open-source method, nine phases, runnable in a chat, an agent, or a workshop
- Used with
- Product, research, and engineering on the Renaissance Intelligence Assignments page
- Outcome
- A public method and an accepted file-based architecture. No public usage count.
A workshop could end as a stack of files
A dash could leave assumptions, a design spec, a flow, a wireframe, and a pitch site. The relationships lived in the prose. Asking why a control existed meant searching the folder.
I had already seen the other version of the same gap. A prompt can return cards, charts, and filters in seconds. The team still has not named the objects, the actions, or which claims are evidence and which are hopes.
On the Assignments page at Renaissance, I facilitated a session with product and engineering before we argued about layout. Every assignment shared a title, type, assigned date, and due date. Product-specific detail, such as questions answered or pages read, stayed beside those fields. That split is what let the page stay scannable.

I derived the rigor from the risk
I did not want the facilitator to choose how careful to be. Design Dash derives a tier from risk, reversibility, and reach.
Express is for low-risk, easily reversible, narrow work. It keeps an ethics floor, and any skipped gate is written down as evidence debt. Standard work requires evidence, a reconciliation between the system and the user’s mental model, a real comparison of concepts, an ethics review, and a learning plan. High-stakes work — hard to undo, broad in reach, or touching regulated, financial, or safety-related data — cannot waive those gates. A simulated reviewer does not count as sign-off.
Inside that path, the team names the objects and what a person can do with each before screens are treated as the source of truth.

Plain files are the only thing anyone edits
An early version of the method treated a rich living-plan document as the source of truth whenever a local toolchain was available. Hand-authored summaries drift, and they leave out anyone working from a chat or a worksheet.
The architecture I accepted on 23 August 2026 inverts that. The Dash Model is plain files: Markdown with a small header, plus typed links. A generated graph can be rebuilt and must not be edited by hand. Chat can facilitate, but a product decision has to leave the transcript as a record. The Design Plan regenerates from the current files. A Story is a frozen snapshot for a release.
Three links are required. The interface points at a decision. The decision points at a requirement or an object. The requirement points at an opportunity. An open assumption at a gate stays visible. I rejected a database as the canonical store because the method has to run without one, including when there is no Node toolchain.

Outcome
The Assignments session left a model the team could test
A finished dash yields object guides, a stakeholder pitch, requirements, monochrome wireframes that include empty, loading, error, and permission states, and an evidence trail. On the Assignments work, the session produced the object notes, diagrams, wireframes, and low-fidelity prototype the team tested. The grouped priority view that later shipped came out of that shared model.
I do not have a public usage count for the repository. The Dash Model is an accepted architecture, and existing dashes still move onto it one at a time. My takeaway: documents stay aligned when there is one store, the views are generated, and a gate can fail a screen that cannot point back to a decision.