Six ways teams use it,
from a better drawing to a harness for the code.
Start with the lightest one and grow into the next when you need it. It is the same model all the way.
A modelling tool instead of a drawing tool
Boxes that know what they are, and diagrams that follow the model.
When
Your architecture lives in draw.io, Miro or slides, and the same box is drawn on six diagrams, each one a separate truth.
How
Radical Studio alone, in the browser, as a desktop app, or inside VS Code next to the code. Keep the model in the browser, in one .radical file, or as a folder of Markdown files in git. No account, nothing uploaded.
Radical StudioRadical Model
What you get
- Rename once, every diagram follows. An element is one thing; diagrams are views of it.
- Studio knows what a box is. A component sits inside a container, a container inside a system, and only the relations the metamodel allows can be drawn.
- One model, eight readings. C4 structure diagrams, a wiki of articles, a table of a subset, a treemap, a flow of numbered steps, a matrix, an explore view, a Warnier diagram.
- Search and explore. Find any element and see what it reaches, level by level.
- Present a walk through the architecture. Slides over views, each with its camera and collapse state, played full screen, with a URL per slide.
- Share it as a file or a folder. Send the
.radicalfile or commit the folder; whoever opens it starts in Viewer, read-only. - Evolve it. Milestones freeze as-is and target states and compare them; a change is an edit, not a redraw.
- Bring what you have. A Structurizr DSL workspace imports as a C4 model.
Open Studio → Models & files → The eight view types → Viewer & Presenter →
Requirements that stay attached to the architecture
A replacement for the Confluence wiki for the business analyst, with every page written from the model.
When
A business analyst keeps needs, requirements and processes in Confluence pages that drift apart, and a rename means hunting through twenty of them.
How
The governance part of the Radical metamodel, with or without a C4 model beside it: needs in the stakeholder's words, EARS requirements, Gherkin scenarios, processes, state machines, mockups and screen flows. Write it on the wiki page or in a table; Studio splits a sentence into its fields, and the AI assistant derives EARS requirements from a pasted brief, each linked to the need it came from.
Radical StudioRadical Model
What you get
- Relations are real. A requirement derives from a need, a scenario verifies it, a component satisfies it. Follow the chain in either direction.
- Change in one place. Rename, split or re-link, and every page, table and diagram follows.
- The wiki is the model. Every article is written from it, so it is never out of date, and it is edited in place.
- Paste a list of requirements and see what its lines will become before they are added.
- Completeness is checked as you write. Requirements without a scenario, needs without requirements, in the Inspector.
- Processes, states and mockups sit next to the requirements they refine, not in another tool.
Needs, requirements, decisions → Writing the model on a wiki page → Processes → Mockups & screen flows →
One language across the organisation
Your own language for the architecture, with standards and decisions in one place and a view per audience.
When
Standards, decisions and principles are spread over wiki pages, decks and chat, and every team reads a different version.
How
A metamodel of your own: the element types and relations your organisation talks in, with their forms and glossary. ADRs with status, context, consequences and alternatives, linked to the elements they constrain; fitness functions that check them; concern packs from the Radical Hub for the decisions every system has to make; a view per audience, from one model.
Radical StudioRadical HubRadical Model
What you get
- A view for each stakeholder. C4 diagrams for engineers, wiki articles for product owners, tables and matrices for compliance. Nobody keeps a second copy.
- A common language, defined by you. The metamodel editor adds the types your organisation needs, such as a capability, a team or a standard, with a form for each and the rules between them. The Glossary explains them on every wiki.
- Decisions next to what they govern. An ADR constrains the systems it applies to and supersedes the one it replaces.
- Recurring decisions settled once. A Hub pack asks a few questions and brings the need, requirements, decision and checks, all linked.
- As-is, interim and target in one deck. Milestones freeze each stage of a transformation and compare them; Presenter plays the roadmap.
- What is still undecided, listed. The Hub's critic names each concern a model of this shape has to settle and no accepted decision covers, which is an audit on demand.
- Viewer is a sandbox. Stakeholders can drag, collapse and explore without changing anything.
The metamodel editor → Explore the Hub → ADRs & fitness functions → Milestones → Viewer & Presenter →
No blank page: a model from a brief, or from the code you already have
A reviewable first draft in an hour, for a system that does not exist yet or one nobody wrote down.
When
A new system to design for a proposal, an RFP or a discovery workshop, with a deck due next week. Or an old system nobody documented, and the people who knew it are gone.
How
For a new system, Radical Forge turns the brief into requirements, a domain model, scenarios, states, processes, mockups and a C4 model, one stage at a time, with the Hub's concern packs settled on the way. For an existing one, a coding agent connected through MCP reads the repository and writes the model; the Inspector says what is still missing, and the Hub's critic which concerns nobody has decided.
Radical ForgeRadical MCPRadical HubRadical Studio
What you get
- A first draft in an hour, not a week. Requirements, domain, scenarios and the C4 model, linked, from one description.
- Every stage asks before it writes and can be regenerated; nothing lands in the model that you did not accept.
- The decisions settled early. The packs the brief calls for come in with their requirements and checks before the first box is drawn.
- A deck the same day. The stage views go straight into Presenter for the workshop or the proposal.
- An existing system, written down before the next change, not after: the agent reads the code and files what it finds as containers, components and relations.
- The gaps named. The Inspector lists what the draft lacks, so the review has an agenda.
Radical Forge → An agent on your repository → The Inspector → Presenter →
The architecture the code follows
One source of truth from need to test, for people and for agents, checked in CI.
When
You want the architecture to be the single source of truth from need to test, for people and for AI agents, and to know when the code drifts from it.
How
The whole family. The model as a Markdown folder in the repository, Studio to shape it, the MCP server for the agents, radical check in CI, the Inspector to read the result.
Radical StudioRadical MCPRadical CLIRadical Model
What you get
- One source of truth for humans and agents. The agent reads the architecture, decisions and requirements through MCP before it writes code, and updates the model when the design changes.
- CI checks the implementation against the model.
radical checkreads the test reports and verifies that the tests scenarios and fitness functions name exist and pass. A gap above its baseline fails the build. - Model health on every change. Consistency, Completeness, Traceability and Decisions as percentages, with goals and baselines; the ratchet only tightens.
- Changes on branch. What a pull request changed in the model, with what the tests say about each requirement and decision.
- One plane. Need → requirement → component → scenario → test, traced end to end.
- Proven on itself. This repository keeps its own architecture this way and checks it on every push.
The MCP server → radical check in CI → The Inspector → Changes on branch → Our own model →
A harness for vibe coding
Model first, code second, and CI that notices when they part.
When
You build fast with agents and still want to know, a month later, what you have.
How
Radical Forge builds the model first, from a brief, one reviewable stage at a time: requirements, domain model, fitness functions, scenarios, state machines, processes, mockups, C4 model, review. Concern packs from the Hub are settled at the start. Then the agent works through MCP, and CI gates the code with the CLI.
Radical ForgeRadical HubRadical MCPRadical CLI
What you get
- Model first, code second. The agent starts from a map, not a blank repository.
- Lower cost. The agent reads the model instead of re-reading the codebase every session. Shorter context, fewer wrong turns, less code thrown away.
- Best practices by default. Packs bring the decisions you would forget, such as who is calling, how long personal data is kept and what happens when a partner is down, with their requirements and checks. Each rests on named sources, OWASP ASVS, NIST, the GDPR, Google SRE, and the catalogue refuses a pack without them.
- Guardrails that fail CI. Fitness functions and scenarios name tests, so drift shows up in the build, not in production.
- You stay in control. Every Forge stage asks first and can be regenerated; proposals are yours to accept.
- The model keeps up with the code, so what you have a month later is still written down.
Radical Forge → Concern packs → Connect your agent → Gate it in CI →
Start anywhere
- Open Studio in the browser and draw.
- Add the requirements when the diagrams need a why.
- Put the folder in git when the team needs it.
- Connect your agent when the code should follow.
It is one model the whole way.