Skip to main content
computer-science economics medicine-and-health

​
Context asymmetry

​
Description

A pattern that recurs across multi-agent, multi-layer, and multi-stakeholder systems: two contexts operate side by side but at different grains or with different visibility. The deliberate version is productive — information hiding lets each layer reason about its own scope without overload; abstraction boundaries are explicit context-asymmetries. The accidental version is harmful — the wrong context loses signal it needed, or carries information it shouldn’t. The diagnostic question — “is the asymmetry deliberate (carries information-hiding value) or accidental (loses signal)?” — separates productive layering from leakage. A canonical software case is the orchestrator-workers split: the orchestrator accumulates session context and dispatches; each worker has a fresh, fixed context. The mismatch is the design — the orchestrator absorbs context so workers can stay scoped.

​
Triggers

User-initiated: User describes a mismatch between what two parts of a system can see or know, or asks “should this layer have access to X?” Vocabulary cues: “context-asymmetry,” “grain mismatch,” “visibility,” “scope,” “what they need to know.” Agent-initiated: Agent notices that two parts of a system operate at different granularities or visibility levels, and the difference is doing structural work (or producing structural problems). Candidate inference: “is this asymmetry deliberate (information hiding) or accidental (lost signal)?” Situation-shape signals: Multi-agent or multi-layer systems. Discussions about information hiding, scope, “what should X know about Y?” Bug reports involving “the test passed but production failed” or “the orchestrator missed what the worker saw.”

​
Exclusions

  • Symmetric peer interaction — when both contexts see the same information, the asymmetry is absent. Doesn’t fire.
  • Trivial information hiding — private keyword in OOP is technically asymmetric but rarely worth naming as context-asymmetry; reach for the concept when the asymmetry is doing meaningful structural work.
  • Single-context systems — single-threaded scripts with no layering or boundaries. The concept requires the two-context shape.

​
Structure

Internal structure of context-asymmetry: a table of its component slots and the concepts that fill them.

​
Relationships

Relationship neighborhood of context-asymmetry: a graph of the concepts it connects to and the concepts it is a part of.
  • container — context-asymmetry is fundamentally two containers; the concept presupposes containment.
  • grain — most context-asymmetries are grain differences.
  • seam — seams are format-mismatch boundaries; context-asymmetries are visibility-mismatch boundaries; they often co-occur.
  • surface — one context’s surface is what the other context sees; the asymmetry lives at the surface boundary.
  • load-bearing — diagnostic for an asymmetry: is the information-hiding load-bearing (deliberate), or is signal getting dropped (accidental)?

​
Examples

Code reviewer vs author · computer-science

author has full mental model; reviewer has only the diff + relevant files. The asymmetry is what makes review valuable (independent view) and risky (missed assumptions).

Doctor / patient information asymmetry · medicine-and-health

clinical context vs patient context; the doctor sees what the patient cannot.
logger sees timestamps + traces + thread IDs; application sees domain objects; the grain difference is deliberate (telemetry grain vs business grain).
Akerlof’s 1970 paper “The Market for ‘Lemons’” identified a destructive information-asymmetry dynamic in the used-car market: sellers know whether their car is good or a “lemon,” buyers cannot tell, and so buyers can only offer a price that reflects the average expected quality. That average price drives the highest-quality sellers out of the market (their cars are worth more than the average price), which lowers average quality and drives the next tier out, and so on — in the limit, only lemons remain.For the catalog, this is the canonical accidental, harmful form of context-asymmetry: two parties at different grains of information, where the asymmetry is not by design but is the unintended product of the situation, and where the harm comes from the receiver’s inability to discriminate. Akerlof’s framing earned the Nobel because it showed the dynamic recurs across markets — insurance, labor, credit, online platforms — wherever sellers know more about quality than buyers and cannot credibly signal it. The catalog uses it as the load-bearing exemplar of the failure mode the deliberate-context-asymmetry pattern (information hiding, encapsulation, intentional division-of-labor between agents at different context grains) is designed to avoid.
caller knows the API surface, not the internals; the asymmetry is the abstraction.
David Parnas’s 1972 Communications of the ACM paper “On the Criteria to Be Used in Decomposing Systems into Modules” articulated information-hiding as the principle for module decomposition: each module should be designed around a design decision likely to change, and the module’s interface should expose only what callers need and hide everything that callers shouldn’t depend on. The module’s interior and its exterior see different things — that asymmetry is the design, not a leakage. Callers see a stable interface; implementers see the changing implementation; neither has full visibility into the other’s context, and the asymmetry permits each to change independently without cascading consequences.The paper’s significance is that it made the asymmetry deliberate and load-bearing rather than incidental. Earlier decomposition strategies organized modules around processing steps in the program’s execution; Parnas showed that organizing around hidden design decisions produced systems that survived requirements changes far better. The structural primitive that recurs is: two contexts at different visibility levels, with the asymmetry intentionally protecting downstream stability against upstream change.Inference: When designing module boundaries, the question isn’t “what does this module do?” but “what design decisions are this module’s callers protected from?” If the answer is “none — callers see everything,” the module isn’t carrying its weight as an information-hiding boundary. If the asymmetry is real and load-bearing, the boundary is doing structural work and survives the test of changing requirements.
test fixtures provide narrower context, assume determinism production lacks; accidental asymmetry leaks bugs.