> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.

# surface

> What's exposed to the outside — image-schema sense (UI, top layer) and force-dynamic sense (attack, friction) mediating internal/external.

<Badge>computer-science</Badge> <Badge>linguistics</Badge>

# Surface

## Description

What's exposed to the outside — the part of a system that interacts with users, callers, attackers, or other systems. A surface has two flavors that frequently bleed together: the *image-schema* sense (a UI surface, a top layer, the visible part) and the *force-dynamic* sense (an attack surface, a friction surface, what's exposed to outside pressure). Both senses share the property of mediating between internal and external.

## Triggers

**User-initiated:** User names or implies a boundary between visible UI/API and internal mechanism. Most common phrasings: "does this thing belong here?", "two surfaces or one?", "reuse the X?", or proposals to consolidate / split visible interaction points. The strongest user-message signal is the word **"thin"** — "thin wrapper," "thin layer," "thin shell." Two recurring sub-shapes:

* **Splitting / unification** — user wonders whether two surfaces should be one or one should be two; agent applies the "what does each do that the other can't?" diagnostic. (Example: "are we complicating things with two surfaces to add camps to tray -- browse directory vs autocomplete/search path?" → agent: "two surfaces competing on the same job is a real risk; two surfaces handling adjacent jobs is a funnel.")
* **Reuse-the-surface** — user explicitly names the move (e.g., "could/should mirror the existing save modal -- reuse the surface?") and the agent elevates it to a principle: shared behavior lives in shared code.

**Agent-initiated:** Agent reaches for `surface` as a named-role decomposition partner — the substrate-surface-amplifier stack is the canonical case (surface as the named middle layer above substrate). Surface is reached for in agent-side reasoning at least as much as user-side framing.

**Vocabulary cues:** "thin wrapper," "thin layer," "thin shell," "surface," "attack surface," "change surface," "audit surface," "error surface," "primary scan surface," "reuse the surface," "two surfaces," "exposed to," "visible to," "mediates between."

**Situation-shape signals:** Multi-surface architecture decisions (whether to consolidate or split); surface-as-named-role in a layered architecture; same data shape covered at multiple visible boundaries with potentially-differing visual or interaction treatments.

## Exclusions

* **Fully internal systems** — pure libraries, pure data structures with no observable surface; the surface question is degenerate.
* **"Surface" as synonym for "layer"** — when used without the inside/outside semantics, the concept's specific work isn't being done.

## Structure

<img src="https://mintcdn.com/agentconcepts/0tEG4hXdVN7eFkO8/concepts/_assets/surface-slots.svg?fit=max&auto=format&n=0tEG4hXdVN7eFkO8&q=85&s=139bac3d4d099c75be4d4fc4ad026289" alt="Internal structure of surface: a table of its component slots and the concepts that fill them." style={{ width: "100%" }} width="603" height="273" data-path="concepts/_assets/surface-slots.svg" />

## Relationships

<img src="https://mintcdn.com/agentconcepts/ostLPxPGvPupm-Ij/concepts/_assets/surface-neighborhood.svg?fit=max&auto=format&n=ostLPxPGvPupm-Ij&q=85&s=ace7de59f286758a8389eb3874e7a03e" alt="Relationship neighborhood of surface: a graph of the concepts it connects to and the concepts it is a part of." style={{ width: "100%" }} width="957" height="1176" data-path="concepts/_assets/surface-neighborhood.svg" />

* [seam](/concepts/seam) — where two surfaces meet is a seam; the seam is often the failure point.
* [load-bearing](/concepts/load-bearing) — thin surface over a load-bearing piece is often the right decomposition; load-bearing piece is the moat, surface is the polish.
* [container](/concepts/container) — surfaces are the boundary of containers; the surface defines what's "inside" vs. "outside."

## Examples

<AccordionGroup>
  <Accordion title="Attack surface (information security) · computer-science" defaultOpen={true}>
    A system's attack surface is the total set of points where an unauthorized actor could try to get in or pull data out — every open port, exposed endpoint, input field, and third-party dependency. It is *surface* in the force-dynamic sense: the boundary where the interior meets outside pressure, the thing an attacker actually touches. The primary hardening move follows straight from the frame — *reduce the surface*: close unused ports, drop features, narrow permissions, so there is simply less exposed to push against. Enlarging it — a new integration, a new public API — is a security cost even when nothing on it is yet known to be vulnerable.
  </Accordion>

  <Accordion title="Image-schema lineage (Lakoff/Johnson — visible boundary). · linguistics">
    The image-schema lineage in cognitive linguistics — most associated with Mark Johnson's *The Body in the Mind* (1987) and George Lakoff's work on conceptual metaphor — treats a small set of recurring spatial-bodily structures (container, path, boundary, source-path-goal, contact, surface) as the primitive vocabulary in which abstract concepts are grounded. Surface in this lineage is the image-schematic structure of the outer-facing layer of a bounded entity: the part that contacts, that is touched, that mediates between interior and exterior.

    The example instantiates surface as a primitive grounded in embodied experience: it is what you encounter first, what determines how the entity participates in contact and force-transfer with the outside, and what gets reused metaphorically when we talk about an "attack surface," a "user-facing surface," or "scratching the surface" of an argument. The catalog's surface concept inherits this image-schematic grounding and extends it to non-physical domains where the same structural role recurs.
  </Accordion>
</AccordionGroup>
