SIGNAL: A Framework for Systems Thinking

Technical problems often appear difficult because their system boundaries, interactions, assumptions, and desired outcomes have not been made explicit. People may begin with equations, software tools, components, or solutions before clarifying what system is actually being analyzed. SIGNAL was developed to slow down that first step.

• The system boundary may be unclear
• Important inputs may be ignored
• Interactions may be mistaken for components
• Outputs may not match the real objective
• Assumptions may remain hidden
• Constraints may be discovered too late
• Uncertainty may be removed from the explanation instead of represented

SIGNAL is a reusable framework for organizing a system before detailed analysis or design. It does not provide the final equation, simulation, architecture, or physical design. It creates a structured representation of the problem so that those tools can be selected and used more responsibly.

• Define the object of analysis
• Identify what enters the system
• Describe what governs internal behavior
• Clarify expected outputs
• Expose assumptions and constraints
• Preserve unresolved uncertainty

SIGNAL is not a complete engineering method, mathematical model, or universal design process. It cannot replace domain knowledge, experimentation, governing equations, simulation, or validation. Its purpose is to improve the structure of the question that comes before those activities.

• Not a substitute for governing equations
• Not a replacement for experimentation
• Not a universal optimization algorithm
• Not proof that the system boundary is correct
• Not a guarantee that every interaction has been identified
• Not a method for eliminating uncertainty

SIGNAL organizes system analysis around six connected elements. The letters are not intended to describe a strictly chronological process. Analysis may move repeatedly among the six elements as new information changes the system model.

• S — System
• I — Inputs
• G — Governing Interactions
• N — Outputs
• A — Assumptions and Constraints
• L — Latent Uncertainty

The system is the object, process, organization, platform, mechanism, or collection of interacting parts selected for analysis. Defining the system requires drawing a boundary. Everything inside the boundary belongs to the current model. Everything outside may belong to the environment, neighboring systems, users, or external conditions.

• What exactly is being studied?
• Where does the system begin and end?
• Which components belong inside the boundary?
• Which actors or conditions remain outside?
• What level of abstraction is appropriate?
• Is the selected boundary useful for the current question?

A system does not arrive with one universally correct boundary. The boundary depends on the question being asked. A robotic finger may be treated as a mechanical linkage, an electromechanical actuator system, a control system, or one component within a complete robotic hand. Each boundary includes different inputs, interactions, outputs, and uncertainties.

• A narrow boundary simplifies analysis
• A broad boundary captures more interactions
• A boundary may hide important external effects
• Different questions require different system definitions
• Changing the boundary may change the apparent cause of a problem
• The boundary should remain open to revision

Inputs are the quantities, materials, information, energy, forces, commands, resources, or disturbances entering the system. An input is not simply something that exists near the system. It is something that crosses the selected boundary and influences internal behavior.

• Energy
• Material
• Information
• Forces and moments
• Control commands
• User behavior
• Environmental disturbances
• Initial conditions
• Boundary conditions
• Resources and constraints supplied from outside

Inputs can be classified according to whether they are intentional, environmental, uncertain, controlled, or measured. This distinction matters because a system may respond differently to a command input than to an uncontrolled disturbance.

• Controlled inputs
• Uncontrolled disturbances
• Measured inputs
• Estimated inputs
• Continuous inputs
• Discrete events
• Initial conditions
• User-generated inputs
• External constraints

Governing interactions describe how the parts of the system influence one another and transform inputs into outputs. In engineering, these interactions may be mechanical, electrical, thermal, fluid, computational, informational, social, or probabilistic. Components describe what exists. Governing interactions describe what happens between them.

• Forces and motion
• Energy transfer
• Heat transfer
• Fluid flow
• Electrical relationships
• Control feedback
• Software logic
• Database operations
• Human decisions
• Probabilistic dependencies

Listing components does not explain the system. A robotic finger may contain links, joints, cables, actuators, sensors, and fasteners. Understanding emerges from how forces, movement, constraints, sensing, actuation, and feedback interact across those components.

• Parts identify structure
• Interactions identify behavior
• Connections may matter more than individual components
• A failure can emerge from relationships rather than broken parts
• Feedback can produce nonlinear behavior
• The same components can create different systems when connected differently

Outputs are the observable or desired results produced by the system. They may include physical motion, information, decisions, heat, force, rankings, user experiences, environmental effects, or unintended consequences. Outputs should be connected to the original question. A system can produce many outputs while only some are relevant to the present analysis.

• What does the system produce?
• Which outputs are desired?
• Which outputs are measured?
• Which outputs are latent or difficult to observe?
• What unintended outputs may appear?
• How will success or failure be evaluated?

A designed system may produce an immediate technical output while creating broader consequences outside the selected boundary. A ranking system may output an ordered list of videos. The intended outcome may be more credible learning content. Those are not the same claim.

• Technical output
• User-facing output
• System-level outcome
• Delayed consequences
• Unintended behavior
• Externalities
• Measures that only approximate the desired outcome

Assumptions are conditions temporarily treated as true so that a model can be constructed. Constraints define what the system, model, or design is permitted or able to do. Both shape the result. If they remain hidden, the final solution may appear more universal or reliable than it actually is.

• Geometric assumptions
• Material assumptions
• Idealized behavior
• Constant-property assumptions
• Budget limits
• Time limits
• Safety requirements
• Available tools
• Data limitations
• Manufacturing limitations
• Legal and ethical constraints

A model is not reality in full. It is a deliberate simplification created for a purpose. The important question is not whether a model contains assumptions. Every useful model does. The important question is whether the assumptions are visible, justified, and appropriate for the decision being made.

• What has been simplified?
• What has been ignored?
• Why is the simplification acceptable?
• Under what conditions will it fail?
• Which assumptions require later testing?
• How sensitive is the result to the assumption?

Latent uncertainty consists of unresolved factors that may influence the system but are not directly observed, fully understood, or represented in the current model. This uncertainty should not be treated as an inconvenience to hide. It is part of the current state of understanding.

• Unknown parameters
• Hidden variables
• Measurement uncertainty
• Model uncertainty
• Incomplete causal understanding
• Human behavior
• Future environmental changes
• Unobserved interactions
• Uncertain objectives
• Unknown failure modes

Some uncertainty is visible and measurable. Other uncertainty remains latent because the relevant variable, interaction, or assumption has not yet been recognized. SIGNAL ends with latent uncertainty to prevent the completed model from creating a false sense of closure.

• Known knowns
• Known unknowns
• Unmeasured variation
• Unknown interactions
• Unrecognized assumptions
• Uncertain consequences
• Questions created by the current model

SIGNAL can be used as an iterative questioning process.

• Define the system and its boundary
• List the inputs crossing the boundary
• Describe the governing interactions
• Identify desired, measured, and unintended outputs
• State the assumptions and constraints
• Record the uncertainty that remains latent
• Revisit the system boundary when contradictions appear
• Update the model as evidence changes

The robotic-hand project provides a physical example of the framework.

• System — one robotic finger and its mechanical assembly
• Inputs — actuator motion, electrical power, control command, and external contact force
• Governing Interactions — joint rotation, cable tension, link geometry, friction, deformation, and feedback
• Outputs — finger position, grip force, speed, and stability
• Assumptions and Constraints — available materials, actuator capacity, joint limits, manufacturing methods, cost, and safety
• Latent Uncertainty — tendon routing, friction losses, material behavior, sensor accuracy, and how closely the mechanism approximates a human finger

SIGNAL can also describe a software and ranking system.

• System — a credibility-oriented short-form learning platform
• Inputs — videos, user behavior, creator information, time, domain, and moderation decisions
• Governing Interactions — evidence collection, ranking logic, posterior estimation, confidence penalties, time decay, and feed generation
• Outputs — ranked video feeds, confidence-oriented ordering, bookmarks, and recommendations
• Assumptions and Constraints — behavioral signals contain useful evidence, limited users and data, infrastructure limits, and incomplete ground truth
• Latent Uncertainty — whether signal meaning changes by learner, domain, objective, interface, and knowledge state

A social product can also be understood as a system rather than a collection of pages.

• System — an immigrant-support information and community platform
• Inputs — questions, housing posts, answers, guides, resources, moderation decisions, and user needs
• Governing Interactions — submission, review, categorization, discovery, response, moderation, and trust formation
• Outputs — published information, community answers, housing opportunities, and reduced navigation uncertainty
• Assumptions and Constraints — early user base, limited moderation capacity, incomplete information, legal boundaries, and trust requirements
• Latent Uncertainty — adoption, information reliability, user safety, cultural differences, and which problems create repeated value

SIGNAL can help distinguish the educational system from the content alone.

• System — learner interacting with an engineering task
• Inputs — prior knowledge, instruction, examples, tools, time, and feedback
• Governing Interactions — attention, retrieval, reasoning, practice, error correction, and reflection
• Outputs — recall, performance, transfer, explanation, or creation
• Assumptions and Constraints — available time, task difficulty, assessment design, environment, and cognitive load
• Latent Uncertainty — whether observed performance represents durable learning or temporary support

SIGNAL structures the system being analyzed. Evidence of Learning helps interpret evidence about whether learning occurred. The Sufficient Understanding Framework helps decide when understanding is adequate for action. The frameworks address different questions and may be used together.

• SIGNAL — What system are we analyzing?
• EoL — What evidence supports the inference that learning occurred?
• SUF — When is understanding sufficient to act?

SIGNAL is most useful when a problem feels broad, tangled, or prematurely solution-oriented.

• Before selecting equations
• Before constructing a simulation
• Before designing a software architecture
• Before defining a research question
• Before building a physical prototype
• When a project contains several interacting domains
• When assumptions are producing repeated failure
• When the desired output remains unclear
• When the system boundary may be wrong

SIGNAL is currently a conceptual systems-thinking framework rather than an empirically validated engineering methodology. Its usefulness depends on the analyst’s domain knowledge, the quality of the selected system boundary, and the willingness to revise the model.

• The framework does not identify every relevant variable
• Users may define the system boundary incorrectly
• Interactions may be oversimplified
• Latent uncertainty cannot always be enumerated
• The categories may overlap
• The framework does not calculate sensitivity or risk
• Domain-specific engineering methods remain necessary

SIGNAL demonstrates my effort to turn a recurring way of analyzing engineering and software problems into an explicit, reusable framework. It preserves uncertainty as part of the model instead of treating uncertainty as evidence that the analysis failed.

• Systems-thinking development
• Cross-domain abstraction
• Engineering-problem decomposition
• Explicit assumption management
• Uncertainty-aware reasoning
• Application across physical and software systems
• Technical communication
• Framework design