Receptive-Field Map¶
Artifact — instantiates Receptive-Field Tiling Design
The canonical blueprint: it names the input space, delineates each local field, and shows how the fields tile to cover it.
A Receptive-Field Map is the foundational artifact of the whole pattern — the blueprint that first names the input space, then draws each local field's center and boundary onto it, and shows how the fields tile together to cover the whole. Its defining move is that it is the static reference document everything else reads from: a probe suite aims its tests at the boundaries this map draws, a heatmap colors the cells this map defines, a routing matrix places cases into the fields this map names. It is not a live monitor, not a metric, and not a ritual — it is the drawing of record. Its one job is to make the tiling explicit and legible: this is the space, these are the fields, this is how they fit, and here is who each field belongs to.
Example¶
A SaaS company's support organization has grown into chaos: tickets land in a single queue and get grabbed by whoever is free, so a billing question ends up with an infrastructure engineer and a subtle data-loss bug sits for days. Before fixing routing or staffing, they draw a receptive-field map. First they define the input space honestly — not by team org chart but by the real dimensions along which tickets differ: product area, severity, and customer tier. Then they carve that space into bounded fields — "billing / any severity / enterprise," "data integrity / high severity / any tier," and so on — each with a clear boundary and a named owning queue.
Laid out as a single tiling, the map immediately shows what the queue hid: two product areas with no owning field at all, and a stretch of the severity axis where three fields overlap. The map does not fix these — it makes them visible and nameable, so the org can now argue about a specific gap rather than a vague sense that "some tickets fall through." Every downstream mechanism, from the routing workflow to the coverage dashboard, is built on top of this drawing.
How it works¶
- Name the input space first. The map's foundation is an explicit statement of the territory to be covered — the real dimensions of variation, chosen because inputs differ along them, not because they match the org chart.
- Delineate each field. Every local field gets a center, a span, and a boundary drawn on the space, so its jurisdiction is a defined region rather than an implicit habit.
- Show the tiling as a whole. The fields are assembled into one picture where gaps, overlaps, and unowned pockets are visible by construction — the map's value is the composite, not the individual fields.
- Label ownership as metadata. Each field carries the name of its owner as a recorded label, so the drawing answers "whose is this?" even though acting on that ownership happens elsewhere.
Tuning parameters¶
- Dimension choice — which axes of the input space the map is drawn on. The single highest-leverage decision: fields drawn on org-convenient axes rather than real input variation produce a tidy map that mis-covers reality.
- Field granularity — how finely the space is carved. Fine fields give precise jurisdiction but a crowded, high-maintenance map; coarse fields are legible but blur who owns what.
- Boundary crispness — whether fields are drawn with hard edges or acknowledged overlap zones. Crisp edges are simple to read; drawn overlaps admit the reality that some inputs sit between fields.
- Representation medium — a static diagram versus a queryable data structure. A diagram communicates; a structured map can be consumed programmatically by routing and audit tools, at the cost of being harder to eyeball.
When it helps, and when it misleads¶
Its strength is that it makes an implicit division of labor explicit and shared: once the tiling is a drawing, gaps and overlaps that were invisible in day-to-day handling become nameable, and every other mechanism has a common reference to build on. It is the artifact that turns "we sort of know who handles what" into a picture the whole team can point at.
Its central failure mode is staleness — a map is a snapshot, and the moment the input distribution shifts, the drawing quietly diverges from reality while still looking authoritative, the map–territory confusion in operational form.[n1] Its classic misuse is drawing the fields along organizational convenience rather than real input variation, producing a map that is internally tidy but covers the wrong space. The guarding discipline is to treat the map as a living artifact with an owner responsible for revising it, and to derive its dimensions from how inputs actually vary rather than from who currently sits on which team.
How it implements the components¶
input_space_definition— its first act is to name the territory to be covered and the dimensions along which fields are drawn.local_receptive_field— it delineates each field's center, span, and boundary, turning a vague responsibility into a defined region.coverage_tiling_map— it assembles the fields into one tiling that shows how they cover the whole space, making gaps and overlaps visible by construction.
It records who owns each field as a label but does not perform the accountable-owner role — chasing drift and answering for a live field is field_owner_stewardship, exercised by Geofenced Service Coverage Grid over its zones — and it draws boundaries without setting any activation threshold, since selectivity_and_threshold_rule is Sliding-Window or Kernel Bank's.
Related¶
- Instantiates: Receptive-Field Tiling Design — the blueprint on which the whole pattern is built.
- Sibling mechanisms: Coverage Heatmap Audit · Edge-Case Probe Suite · Field Calibration Review · Geofenced Service Coverage Grid · Multi-Scale Field Pyramid · Overlap Handoff Protocol · Sliding-Window or Kernel Bank · Specialist Routing Matrix · Unowned Input Alert
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Receptive-Field Map operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it the canonical blueprint: it names the input space, delineates each local field, and shows how the fields tile to cover it.
Independent corroboration: The frozen evidence defines Receptive-Field Map as 'The canonical blueprint: it names the input space, delineates each local field, and shows how the fields tile to cover it', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Neuroscience
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Receptive-field mapping is a foundational sensory-neuroscience method and representation.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
The receptive-field map is the artifact most siblings consume: heatmaps color its cells, probe suites aim at its boundaries, routing matrices place cases into its fields, and unowned-input alerts fire when an input matches none of them. Because so much depends on it, its staleness is uniquely costly — a wrong map propagates a wrong space into every mechanism built on top of it.
[n1] "The map is not the territory" — Alfred Korzybski's reminder that a representation is not the thing it represents. A receptive-field map is especially prone to this: it is authoritative-looking and rarely re-checked, so it keeps being trusted after the input distribution it describes has moved on. ↩