ABOUT
About System Diagnosis
An independent diagnostic practice for the structural analysis of human systems.
System Diagnosis exists for situations where recurring friction, unclear decisions, or complex patterns cannot be understood only as poor execution, unclear communication, or missing tools.
The practice examines the architecture behind behavior: how context, roles, decisions, incentives, constraints, and feedback loops shape what a system repeatedly produces.
Its work is grounded in bounded inquiry, written analysis, and structural clarity before prescription or further action.
01. WHY IT EXISTS
Why this practice exists
Many systems are pushed to perform before they are properly understood.
Processes are adjusted, tools are added, communication is clarified, and more effort is applied. Yet the same patterns often return: delay, misalignment, unclear ownership, rework, or decisions that stall.
System Diagnosis exists for that gap: the space between visible problems and the structure that keeps producing them.
The practice was created to make those structures legible before another layer of activity, redesign, or implementation is added.
OUR PURPOSE
To examine systems at the structural level so judgment can happen from clarity rather than repetition.
02. STANDARD
How the work earns trust
A diagnosis is only useful when its limits are explicit.
System Diagnosis works from bounded scope, supplied information, written reasoning, and a careful distinction between observation, inference, and uncertainty.
The goal is not to create confident language where the system cannot responsibly be read.
The goal is to clarify what can be seen, what remains ambiguous, and which conditions would need to be understood before stronger conclusions are made.
Bounded Scope
Each diagnosis is constrained by a defined system, question, and information base.
WRITTEN REASONING
The analysis is produced as a written artifact so assumptions, structure, and conclusions can be reviewed.
NAMED UNCERTAINTY
When the available information is insufficient, uncertainty is stated rather than hidden.
DIAGNOSTIC RESTRAINT
The work does not force implementation recommendations before the system has been understood.
03. OBSERVATIONS
The public layer of the practice
Observations are where System Diagnosis develops its analytical lens in public.
They are short notes on systems, friction, coordination, narratives, institutions, technology, and human behavior.
They are not general commentary.
They are attempts to read structure: how systems explain themselves, where friction reveals architecture, how visible movement can be mistaken for progress, and what becomes difficult to see from inside a system.
For visitors, Observations make the practice legible before a formal diagnosis is requested.

PUBLIC LENS
Observations make the analytical lens visible before a formal diagnosis is requested.

STRUCTURAL READING
Each note looks for the structure beneath visible events, behavior, or recurring friction.

ACROSS DOMAINS
Observations may move across organizations, technology, institutions, products, and human systems.

NOT COMMENTARY
The purpose is not to react to topics, but to identify architecture.
04. DIRECTION
The analytical direction behind System Diagnosis
Carlos guzmán
Founder / Principal Analyst
Carlos developed a background in data analysis, business process improvement, process automation, and the design and implementation of end-to-end digital solutions through his own company.
That work required looking beyond isolated tools or processes and understanding how workflows, roles, information, incentives, constraints, and decision flows interact.
Over time, that orientation developed into a structural approach to reading systems: not only what is being implemented, but what the system is producing, preserving, obscuring, or making difficult to change.
System Diagnosis was created to apply that orientation to human systems: organizations, teams, institutions, products, and decision environments where recurring friction, unclear decisions, or complex patterns point to deeper structure.
Make the system legible before acting on it.
If a system keeps producing friction despite reasonable fixes, System Diagnosis may help clarify the structure behind the pattern.