How it works
This page explains the ideas behind MethodSketch. To learn what to click, refer to the Tutorial and the How-to guides.
The design is text
You write a sketch as text, and MethodSketch draws the diagrams from it. The text is the design. The diagrams are views of the design.
Text is fast to change. When a call chain shows you a better place for a component, you change one line and iterate. You do not move boxes and arrows on a canvas, and the other diagrams follow the change by themselves.
Text is also easy to compare, to put in source control and to review line by line. An AI agent can read and write the text, the same as you can.
When you move boxes in the diagram editor, the pad keeps only the box positions. The pad stores the positions in a folded [v1 …] block after the block that you edited. The design itself stays in the text.
Each iterate is a version
Iterate sends the text to the server. The server reads the text, checks the design against the rules of the Method, draws every diagram and saves the result as a new version.
So you can try an idea and go back. History lists every version, and you can open each version.
The parser stops at the first line with a syntax error. The diagrams then leave out everything after that line, and the editor marks the line in red. So fix the first error first. If the server cannot make the design at all, the pad keeps the last diagrams and shows the error.
One design, many views
Each block in the sketch gives one or more diagrams. All diagrams are views of the same design, so the diagrams always agree.
| You write | You get |
|---|---|
StaticAspect | The static aspect, with each component in the correct layer |
UseCase | A call chain and a sequence |
| Call detail on the calls | A DTO flow for the use case, the service contracts and the data contracts |
| All use cases | The dependency diagram |
DTO, Identifier, Value | A diagram of each type |
Flow, StateChart, Activity | A BPMN process, a statechart, an activity diagram |
The views grow as the design grows. In System Design you write components and calls, and you see the static aspect, call chains and sequences. In Detailed Design you add operations and DTOs to the same calls, and the DTO flows and contracts show up. You keep one sketch from the first idea to the last detail.
The rules of the Method
The Method has rules about which component can call which. A client calls a manager. A manager calls engines and accesses. Only an access calls a resource. A manager calls another manager only with a queued or asynchronous call.
MethodSketch checks each call against these rules. The editor offers only the calls that follow the rules. A call that breaks a rule gets a warning, and the diagrams leave that call out. So the diagrams always show a design that follows the Method, and the warnings show where your text does not.
From design to code
The generator turns the design into a .NET solution. The generator makes a project for each component, the interfaces from your call detail, and the DTOs, identifiers and values from your types. The generator writes the result as a script that you run on your own computer, so the code is always yours.
The script adds only what is new. When the design changes, you generate again and run the new script in the same folder.
With Enforce Design, the script also adds modelanalyzer.json and an analyzer to the projects. The file holds the design, and MethodSketch signs the file. When you build, the analyzer compares the code with the design and reports each place where the code leaves the design. So the design stays true after the code is written.
Back from code to design
Dispatch Witness goes the other way. Dispatch Witness runs your tests, records each call between your components, and sends the record to MethodSketch. The pad then shows each test next to the use case that the test covers, with the values on each call and the path through each component. You see what the code did, next to what the design said would happen.
Dispatch Witness is a preview.
Agents
An AI agent can work on a sketch over MCP. The design endpoint lets the agent read and change a sketch. When the agent changes a sketch, the pad shows each change, and you accept or reject each change. So the design stays yours.
The brief endpoint lets an agent read a design, with no access to change the design. Give the brief endpoint to an agent that writes the code, so that the agent builds what the design says.