An observable is something that can be measured, detected, or monitored, but the precise meaning depends on the field. In quantum physics, it refers to any physical property you can measure. In software development, it’s a data source that emits values over time. In medicine, it’s something a clinician can objectively detect. These uses share a common thread: an observable is a quantity or event that produces concrete, measurable information rather than something inferred or assumed.
Observables in Software Development
In programming, an observable is a data source that pushes out a sequence of values over time. Those values can be anything: user clicks, incoming messages, sensor readings, or responses from a server. The key idea is that instead of your code asking “is there new data yet?” over and over, the observable automatically notifies anything that’s listening whenever something new arrives.
This is built on the Observer design pattern, which establishes a one-to-many relationship between a data producer and its consumers. The observable (sometimes called a provider or subject) manages a list of observers. When its state changes, it pushes that update to every registered observer without any of them having to request it. According to Microsoft’s documentation, the observable handles three responsibilities: sending notifications, keeping track of who’s subscribed, and removing observers when notifications are complete.
The observer, on the other side, is a passive listener. It subscribes to the observable and then reacts to three types of signals:
- New data: the observable sends a value, and the observer processes it
- Error: something went wrong in the data stream
- Completion: the observable has finished sending data
This pattern is the foundation of reactive programming, where systems are designed around asynchronous data streams. Because observables emit data without blocking the rest of the program, they’re especially useful in user interfaces, real-time applications, and anywhere data arrives unpredictably. The observable pattern also enforces a clean separation between the code producing data and the code consuming it, which makes systems easier to test and modify.
If you’ve worked with libraries like RxJS, RxJava, or the .NET Reactive Extensions, you’ve used observables directly. Angular, for example, relies heavily on observables for handling HTTP requests and user events.
Observables in Quantum Physics
In physics, an observable is any physical property that can be measured. Position, momentum, energy, and spin are all observables. The term replaced older phrases like “physical quantity” or “measurable quantity” and became standard in quantum mechanics because measurement works fundamentally differently at the quantum scale than in everyday life.
In classical physics, you can (in principle) measure a property like the position of a ball without disturbing it. In quantum mechanics, measurement itself changes the system. An observable isn’t just a label for a property; it’s tied to the mathematical machinery that predicts what you’ll get when you measure. Each observable is represented by a specific type of mathematical object (called a self-adjoint operator) that determines the possible measurement results and their probabilities.
Max Born first recognized the statistical nature of quantum observables when he proposed that the wave function of a particle doesn’t tell you exactly where the particle is. Instead, the square of the wave function gives the probability of finding the particle at a given point. This insight applies to all quantum observables: before measurement, you generally don’t have a single definite value but rather a spread of possible outcomes with different probabilities.
There’s one important exception. If a system is already in a special state matched to a particular observable (called an eigenstate), then measuring that observable will produce one specific value with certainty. In every other state, you get a probability distribution of results. This is why repeating the same measurement on identically prepared quantum systems yields different outcomes, and why quantum mechanics is fundamentally a theory about probabilities rather than certainties.
Observables in Medicine
In clinical settings, the word “observable” refers to anything a clinician can detect, measure, or verify independently of what the patient reports. The standard distinction is straightforward: a symptom is what the patient complains of, while a sign (or observable) is what the clinician observes. Some findings, like a rash or fever, fall into both categories because the patient notices them and the clinician can confirm them directly.
Common clinical observables include:
- Vital signs: blood pressure, heart rate, respiratory rate, temperature, and blood oxygen level
- Physical exam findings: heart and lung sounds, the presence of swelling, skin color, rashes, or wounds
- Lab results: blood counts, metabolic panels, and cultures
- Imaging: CT scans, MRIs, ultrasounds, and X-rays
- Behavioral observations: level of consciousness, gait stability, and whether a patient can walk independently
Subjective symptoms, by contrast, include things like pain descriptions, feelings of dizziness or fatigue, nausea, and emotional states like anxiety. These are real and clinically important, but they can’t be independently verified by an outside observer.
In medical coding systems like SNOMED CT, “observable entity” is a formal category. It covers anything that can be assessed and given a result, from specific lab tests to behavioral assessments. A clinical finding (part of a diagnosis) is often linked to an underlying observable entity that produced it.
Observables in Philosophy of Science
Philosophers of science have long debated where to draw the line between what counts as observable and what doesn’t. The logical empiricists of the early 20th century tried to build a strict wall between observational knowledge (things you can see, hear, or touch) and theoretical knowledge (things you infer, like electrons or gravitational fields). The goal was to make observation the pure, unbiased foundation for evaluating scientific theories.
In this tradition, looking at a berry on a vine and noticing its color and shape counts as observation. But detecting a subatomic particle through a chain of instruments and mathematical inference is something different. The particle itself is unobservable; what you actually see is a readout, a track in a cloud chamber, or a spike on a graph. Whether that readout counts as “observing” the particle is where the philosophical debate lives.
Modern philosophy of science has largely moved away from a hard boundary. Measurement, as the Stanford Encyclopedia of Philosophy describes it, involves two layers: the concrete interaction between an object, an instrument, and the environment, and a theoretical model of that interaction. Even something as simple as measuring length with a ruler requires correcting for temperature-related expansion, which depends on theoretical assumptions about how materials behave. In this view, no observation is purely theory-free. Every measurement carries assumptions about how the instrument works and how the environment affects it, blurring the clean line between what’s “directly” observed and what’s inferred.
The Common Thread
Across all these fields, an observable is defined by its accessibility to measurement or detection. It’s the thing you can actually pin down with a number, a reading, or a notification, as opposed to something hidden, inferred, or merely theoretical. In programming, it’s the data source you can subscribe to. In physics, it’s the quantity your detector registers. In medicine, it’s the sign your clinician documents. The specific mechanics differ enormously, but the core idea is consistent: an observable is where abstraction meets concrete evidence.