Formal Representation
Constrains output to a rule-governed symbolic form (for example JSON, SQL, DOT) so meaning is carried by structure rather than prose.
Problem
Prose descriptions of rules, states, and dependencies are readable but ambiguous and hard to validate programmatically.
Solution
Constrain output to a rule-governed symbolic form (JSON, SQL, DOT, Mermaid, etc.). Syntax carries explicit relationships, enabling validation, parsing, rendering, and execution.
Example
One worked example. The book has 2–4 per technique.
Define the state transitions for our order processing workflow as a Mermaid state diagram. Output only valid Mermaid syntax. An order starts as pending, moves to confirmed when payment succeeds or to cancelled if payment fails. Confirmed orders can be shipped. Shipped orders become completed upon delivery.
```mermaid
stateDiagram-v2
[*] --> Pending
Pending --> Confirmed : payment succeeded
Pending --> Cancelled : payment failed
Confirmed --> Shipped : order dispatched
Shipped --> Completed : delivery confirmed
Cancelled --> [*]
Completed --> [*]
```Techniques
Concrete ways to implement Formal Representation. Each technique fits a different situation.
- 01
Schema Constraining
Require output that conforms to a data schema with defined field names, types, and nesting so the result can be validated and parsed programmatically.
- 02
Notation Encoding
Require output in a notation where syntax carries semantic meaning (graph edges, SQL joins, state transitions, regex) so relationships are explicit.
Full treatment in the book
Formal Representation — the complete chapter
- ▸ Mechanism — why this pattern works
- ▸ 2–4 worked examples per technique
- ▸ Placement, sequencing, and debugging rules
- ▸ Composition with related patterns