SDL GPT — User Guide¶

A tool for deliberate system thinking, design, and validation

1. What is System Design Lens?¶

System Design Lens (SDL) is a thinking tool that helps you:

design systems deliberately instead of accidentally
analyze and compare existing frameworks or methods
understand what a system actually optimizes
identify where systems fail, break, or get misused

SDL is not a chatbot for brainstorming ideas.
It is a design instrument for working with systems as decision-shaping structures.

2. What SDL means by “system”¶

In SDL, a system is:

An intentional construct designed to make certain decisions easier, safer, or more reliable.

A system can be:

a framework
a methodology
a governance rule
a workflow
a scoring model
a decision rule
a coordination mechanism

If something does not change decisions, SDL does not treat it as a system.

3. What SDL is good at¶

Use SDL when you want to:

design a new framework, process, or model
understand what an existing system actually does
compare multiple systems that claim to solve the same problem
check whether a system is coherent or fragile
identify hidden assumptions in a method
make tradeoffs and constraints explicit

SDL is especially useful when things feel:

“elegant but vague”
“widely used but poorly understood”
“promising but fragile”
“hard to explain why this works”

4. What SDL is not¶

SDL is not:

a brainstorming assistant
a creativity tool
a motivational coach
a teaching or tutorial system
a step-by-step recipe generator
a guarantee of correctness

SDL will often slow you down.
That is intentional.

5. Core ideas SDL enforces¶

SDL is built on a few strict ideas:

5.1 Every system solves a failure¶

If you cannot name:

what breaks without the system
where the failure shows up
who experiences it

…then SDL will challenge whether a system is needed at all.

5.2 Systems are decision machines¶

SDL always asks:

What decisions does this system change?
For whom?
Compared to what alternative?

If decisions stay the same, the system is decorative.

5.3 Design comes before prescription¶

SDL does not jump to:

tools
best practices
implementation advice

First comes structure:

scope
constraints
tradeoffs
boundaries

5.4 Misuse is part of design¶

A system is incomplete unless you can say:

how it fails
how it is misused
under what conditions it collapses

Optimism is not a design strategy.

5.5 Artifacts matter¶

SDL expects something inspectable, such as:

a system definition
a map or table
explicit rules
a contract
a vocabulary
a decision matrix

If nothing concrete exists, SDL will say so.

6. How to use SDL (practically)¶

You can use SDL in four main ways.

You do not need special keywords — just state your intent.

Mode 1: Explore the system landscape¶

Use when:
You are unsure which framework or system fits your problem.

SDL will help you:

identify existing systems
compare what each optimizes
see overlaps and blind spots

Typical output:

comparison tables
decision focus differences
gaps no system addresses well

Mode 2: Decompose an existing system¶

Use when:
You want to understand how a system actually works.

SDL will break it down by:

problem it targets
decisions it optimizes
assumptions it relies on
constraints it enforces
failure modes

Typical output:

structured breakdown
strengths vs fragilities
misuse patterns

Mode 3: Design a new system¶

Use when:
You want to intentionally create a system.

SDL will guide you through:

the failure you are addressing
the assumptions you are making
the decisions you want to improve
the object you control
the constraint(s) you impose
the artifact you produce
how the system fails when misused

Typical output:

a draft system definition
a clear system “shape”
explicit tradeoffs

Mode 4: Review or validate a system¶

Use when:
You want to test whether a system is sound.

SDL will check:

whether the problem fits the system
whether decisions are clear
whether constraints have teeth
whether misuse is acknowledged

Typical output:

strengths
gaps
likely failure scenarios
design-level improvement suggestions

7. What to provide for best results¶

SDL works best when you can provide at least one of:

a concrete problem or failure
a named system or framework
a draft idea you suspect is a system
a comparison you want to make

If your input is vague, SDL may ask one clarifying question before proceeding.

8. How SDL may respond¶

SDL may:

slow the conversation down
refuse to design without a concrete failure
challenge vague language
point out missing constraints
say “this is not a system yet”

This is normal and intentional.

9. Common mistakes SDL will push back on¶

“I want a framework for clarity”
“Help me design a flexible system with no constraints”
“This should work for individuals, teams, and organizations”
“It’s more of a mindset than a system”
“We’ll figure out misuse later”

These are signals of accidental design.

10. When SDL is not the right tool¶

SDL is not ideal when:

you are still exploring what the problem is
you want quick inspiration
you need implementation help
the stakes are trivial
you want reassurance rather than structure

In those cases, a general chat assistant may be better.

11. How to think while using SDL¶

Treat SDL like:

a design review board
a structural engineer
a stress-tester for ideas

Not like:

a collaborator
a cheerleader
a teacher

12. What success looks like¶

A successful SDL session usually ends with:

a clearer system than you started with
or
the realization that you don’t need a system yet

Both outcomes are wins.

13. Final note¶

System Design Lens exists to help you think like a system designer, not to give you systems to copy.

If you leave with:

clearer tradeoffs
sharper boundaries
fewer illusions
more respect for constraints

…it has done its job.