# Simon Abstraction Layer Heuristics - Run Output

Run date: 2026-07-02
Model: Codex GPT-5
Prompt: `245 Simon abstraction layer heuristics/FORAY_PROMPT.md` v1

## 1. Simon Reading

1. Complexity is practical before it is metaphysical. A complex system is one whose whole-system behaviour cannot be trivially inferred from its parts and local rules.
2. Hierarchy means successive subsystem structure, not merely command structure. It applies to organisms, molecules, organisations, books, music, products, and problem solutions.
3. The "elementary" unit is purpose-relative. A cell, atom, team, task, room, or module can be elementary for one inquiry and decomposable for another.
4. Interaction patterns reveal boundaries. Dense or frequent interaction within a cluster, plus weaker or slower interaction across clusters, is evidence for a useful abstraction layer.
5. Stable intermediate forms make complex construction feasible. Reusable subassemblies reduce the cost of interruption, search, and failure.
6. Problem-solving heuristics play the same role as stable intermediate forms. A partial result that looks like progress lets search continue from an intermediate platform instead of starting again.
7. Near decomposability is the licence for abstraction. Short-run component behaviour can often be analysed locally; long-run behaviour depends more on aggregate cross-component effects.
8. Time-scale separation matters. Faster dynamics often live inside lower-level subsystems; slower dynamics often live among larger assemblies.
9. Sparse interaction makes concise description possible. If most things are weakly connected to most other things, useful description can ignore most possible interactions.
10. Redundancy enables compression. Repeated substructures, recurring patterns, and generative rules make a complex system describable without reproducing every detail.
11. State descriptions and process descriptions are complementary. A blueprint says what exists or is desired; a recipe, program, or dynamic law says how it is generated or changed.
12. A representation is a working instrument. It is valid over a purpose, granularity, and time horizon, not as a final truth about the system.

## 2. Universal Heuristic Kit

| Heuristic | Question to ask | Evidence to look for | Layer revealed | Failure signal | Layer-shift move |
|---|---|---|---|---|---|
| Interaction-density scan | Who or what interacts most often and most strongly? | Communication logs, dependencies, flows, shared constraints, coupling strength | Candidate subsystem boundaries | Cross-boundary effects dominate local effects | Repartition around actual interaction clusters |
| Elementary-unit test | What can safely be treated as a unit for this purpose? | Stable behaviour, internal complexity irrelevant to current decision, repeatable interface | Working element layer | Unit behaviour changes when internal detail is ignored | Zoom in one level and expose internal state |
| Stable-intermediate search | What partial assemblies retain value after interruption? | Reusable modules, validated milestones, conserved patterns, durable intermediate products | Construction or evolution layer | Progress vanishes when context changes | Redefine milestones as stable subassemblies |
| Within/across contrast | Are within-subsystem links stronger than cross-subsystem links? | Matrix blocks, dense clusters, high internal traffic, weak external dependencies | Near-decomposable layer | Similar link strength everywhere | Treat as network/process, not hierarchy |
| Time-scale split | What changes fast, and what changes slowly? | Event cadence, review cycles, degradation rates, feedback delays | Dynamic layer | Slow variable shifts faster than assumed | Move up or down to the active time-scale |
| Aggregation licence | Can cross-boundary effects be treated as totals or signals? | Aggregate load, average price, total demand, summary risk, service-level effects | Interface/aggregate layer | Individual cross-boundary cases determine outcome | Replace aggregate with typed boundary cases |
| Common-coupler check | Is one subsystem quietly linked to everything? | Shared resource, bottleneck, data platform, funding pot, customer channel, governance forum | Hub or waist layer | Local changes propagate through hidden hub | Model hub explicitly as a separate layer |
| State/process pair | Are we holding a static picture where we need a generating recipe? | Gap between desired state and current trajectory, unclear transformation path | Representation layer | The map is correct but action remains unclear | Switch from blueprint to recipe/process law |
| Compression test | Can the domain be described with a small alphabet of parts and rules? | Repetition, templates, modular components, grammar-like transitions | Generative-description layer | Every case needs bespoke detail | Stop compressing; build case library or exemplar set |
| Failure-range ledger | Where exactly does the abstraction fail, and where does it still work? | Boundary cases, exceptions, decision errors, unexplained variance | Validity-range layer | Exceptions are treated as refutations or ignored | Keep model with scope notes and update triggers |
| Direction-of-search cue | What counts as recognisable progress before the final answer? | Leading indicators, partial proofs, prototypes, pilots, working modules | Heuristic-search layer | Search has no retained partial gains | Define progress cues or smaller stable steps |
| Representation swap | Would another notation make hidden redundancy visible? | Matrices, graphs, process maps, state machines, recipes, dependency diagrams | Encoding layer | Current representation is verbose or misleading | Recode, then retest interaction and time-scale claims |

## 3. Abstraction Failure Taxonomy

| Failure type | Symptom | Diagnosis | Response |
|---|---|---|---|
| Local leak | One exception keeps breaking the model, but most cases still fit | A weak cross-boundary link became locally important | Keep and qualify the abstraction; add an exception rule or local boundary condition |
| Boundary misplacement | The model's boxes do not match observed flows | Partition follows habit, org chart, or data availability rather than interaction density | Split, merge, or repartition around observed couplings |
| Cross-layer coupling | A lower-level detail changes higher-level behaviour, or vice versa | Time-scale or interaction separation is weaker than assumed | Add an explicit bridge variable or expose the coupling layer |
| Wrong time-scale | The abstraction worked last month but fails today, or works in operations but not strategy | Fast and slow dynamics have been mixed | Move to the time-scale at which the decision is being made |
| Hidden common cause | Separate components appear correlated for no local reason | A shared driver, bottleneck, or platform is missing from the model | Add the common subsystem, hub, or waist as its own layer |
| Irreducible detail | The abstraction loses the behaviour that matters | The system is not sufficiently redundant or sparse for this purpose | Stop compressing; use exemplars, simulation, or detailed case tracking |
| Fake stable intermediate | A milestone looks complete but cannot survive handoff or interruption | The subassembly is not genuinely stable outside its maker's context | Redefine done conditions around durability and reuse |
| Representation mismatch | The model is plausible but unhelpful for action | State description is being used where a process description is needed, or the reverse | Switch representation and translate between state and process |
| Aggregate masking | Averages look stable while critical cases fail | Cross-boundary effects cannot be safely aggregated | Replace aggregate with distribution, segments, or typed interfaces |
| Overextended analogy | A useful metaphor begins deciding facts | Similarity is superficial or only partially relevant | Retain the analogy as a prompt, not as evidence; demand direct domain tests |

## 4. Near-Decomposability Test

Use this as a practical field test, not as a theorem.

1. List candidate components. Start with natural units in the domain, but do not trust the first partition.
2. Build a rough interaction matrix. Mark interaction strength, frequency, direction, and consequence.
3. Compare within-component and cross-component interactions. A useful abstraction layer usually has a visible contrast.
4. Check time-scales. Ask whether internal dynamics settle faster than cross-component dynamics matter.
5. Identify stable intermediate forms. Look for modules, states, milestones, proofs, routines, components, or concepts that retain value after interruption.
6. Test aggregate sufficiency. Ask whether cross-boundary effects can be handled as load, rate, signal, average, risk, interface, or constraint.
7. Look for common couplers. A shared resource, platform, customer, governance forum, or physical constraint may defeat a clean partition.
8. Run a boundary stress test. Change one component and ask what else must change immediately.
9. Score the result:
   - Strong: clear internal density, weak external coupling, stable intermediates, time-scale split.
   - Useful but leaky: mostly local behaviour, known exceptions, manageable aggregate effects.
   - Weak: no clear boundary contrast, pervasive coupling, no durable intermediate forms.
10. State the range. Record purpose, time horizon, decision type, and failure triggers.

## 5. Layer-Shift Protocol

1. Name the abstraction that failed. State what it was supposed to predict, explain, or guide.
2. Preserve the valid range. Record where it still works before diagnosing the failure.
3. Classify the failure. Use the taxonomy above: leak, boundary, layer coupling, time-scale, common cause, detail, aggregate, or representation.
4. Inspect the interaction pattern. Ask whether the current boundary still matches actual flows.
5. Inspect the time-scale. Ask whether the decision now depends on faster or slower dynamics.
6. Choose a layer move:
   - Zoom in when internal detail now drives behaviour.
   - Zoom out when aggregate or slow dynamics dominate.
   - Repartition when interaction clusters cut across the current boxes.
   - Add bridge layer when cross-layer coupling is real.
   - Switch representation when a state picture needs a process account, or a process needs a state target.
7. Define a small test. Choose one case where the old abstraction failed and see whether the new layer explains it with less distortion.
8. Keep both models if needed. Mark old abstraction as `valid for X, fails when Y`; mark new abstraction as `candidate for Z`.
9. Add an update trigger. Say what evidence would force another shift.
10. Return to action. The aim is not perfect ontology; it is a better decision at the right level.

## 6. State/Process Translation

A state description tells us what the system is, has, or should look like: an org chart, WBS, blueprint, taxonomy, risk register, architecture diagram, or capability map.

A process description tells us how that state is generated, maintained, changed, or repaired: a workflow, recipe, transition rule, feedback loop, learning process, control law, or programme of actions.

When a static abstraction fails, ask:

1. What state does this representation name?
2. What process generates or sustains that state?
3. Which process step is invisible in the state description?
4. Which state distinction is invisible in the process description?
5. Does the failure arise because we confused a desired state with a generating process?

Translation helps because many abstractions fail at the join. A project WBS may correctly describe desired deliverables but say little about how work discovers, validates, sequences, or changes them. A process map may correctly describe activity but hide what stable intermediate state each activity is meant to create. Simon's useful move is to keep both: blueprint plus recipe, structure plus dynamics, target plus path.

## 7. Two Worked Applications

### A. Project Planning And Delivery

First partition: workstreams, packages, governance boards, suppliers, technical systems, benefits, data, and assurance.

Interaction-density scan may show that the official WBS is not the real subsystem structure. Real coupling may sit around interfaces, scarce people, shared data, regulatory gates, or integration environments.

Near-decomposability test:

- Strong within-workstream cadence suggests local control is valid for short-run execution.
- Cross-workstream integration gates suggest a slower aggregate layer.
- Shared architecture, funding, or safety case may be a common coupler.
- A completed design package is only a stable intermediate form if it can survive handoff, review, and downstream construction.

Failure example: a workstream plan says each team is green, but integration fails. This is not proof that workstream abstractions are useless. It says the abstraction was valid for local progress but blind to cross-boundary coupling.

Layer move: preserve workstream control, add an interface/integration layer, and define stable intermediate forms as "accepted by downstream consumer" rather than "finished by producer."

State/process translation:

- State: WBS, milestone map, RAG report.
- Process: design discovery, dependency negotiation, review, change control, integration testing.
- Better abstraction: a two-level plan where local packages are managed for short-run progress and interface states are managed for long-run system coherence.

### B. Urban Traffic Congestion

First partition: roads, junctions, neighbourhoods, transit lines, schools, delivery zones, parking, weather, events, and signal control.

Interaction-density scan may reveal that congestion is not a property of "the city" in general, but of a few recurrent coupling points: school start times, bridge crossings, station exits, freight windows, car parks, or signal sequences.

Near-decomposability test:

- Local streets may settle quickly after a disruption.
- Arterial roads and transit hubs may propagate effects over a longer time.
- A bridge or tunnel can act as a common coupler across otherwise separate neighbourhoods.
- Average journey time may mask segment-specific failures.

Failure example: a model using neighbourhood averages fails during stadium events. The abstraction remains useful for ordinary days, but the event creates a temporary high-coupling regime.

Layer move: keep neighbourhood model for baseline, add an event-regime layer, and model common couplers explicitly. For event days, switch from area averages to route-specific flow and capacity constraints.

State/process translation:

- State: current road speeds, queue lengths, modal share, parking occupancy.
- Process: inflow, signal timing, route choice, boarding, school release, incident response.
- Better abstraction: model stable local traffic cells for normal operations, plus cross-cell process rules for bursts, incidents, and shared bottlenecks.

## 8. Field Card

When entering an unfamiliar domain, do not start by asking for the correct hierarchy. Start by asking where interaction is dense, where it is sparse, and what can survive interruption as a stable intermediate form. Treat any "elementary" unit as purpose-relative: a team, cell, component, task, paragraph, or molecule is elementary only for the current decision.

Look for near decomposability. If within-part interactions are stronger or faster than cross-part interactions, you probably have a useful abstraction layer. If cross-boundary effects can be handled as aggregates, the layer is useful even if it leaks. If a hidden hub, shared resource, or faster-than-expected coupling breaks the model, do not throw the abstraction away. Mark its range, diagnose the leak, and move layers.

Use the failure to choose the move. Zoom in when internal detail matters. Zoom out when slow aggregate effects dominate. Repartition when real interaction clusters cut across official categories. Add a bridge layer when two levels are genuinely coupled. Switch representation when a static map needs a generating process, or when a process needs a target state.

The test of a good abstraction is not whether it never fails. It is whether it compresses reality for a stated purpose, tells you when it is leaving its valid range, and helps you find the next layer when it does.

## 9. Model Surprise

Add a "boundary exchange rate" to the heuristic kit.

For any candidate abstraction boundary, ask: what must be translated, paid, delayed, simplified, or lost when something crosses this boundary? A boundary with low exchange cost may not be a meaningful layer. A boundary with high exchange cost, repeated translation work, or persistent loss of context is probably a real abstraction boundary even if it is not visible on an org chart or physical diagram.

This extends Simon without violating him. It operationalises interaction strength in human and information systems where coupling is not only frequency or energy, but also translation burden. In projects, the boundary exchange rate shows up as rework, clarification meetings, interface control documents, data mapping, assurance delay, and handoff loss. In research, it appears when a concept must be recoded between disciplines before it becomes usable.

## 10. Self-Critique

Simon can be overextended in four ways.

1. Not every useful domain is hierarchic. Some systems are mesh-like, turbulent, adversarial, or regime-switching.
2. Near decomposability can become a comforting myth. If weak interactions accumulate, the aggregate effect may dominate the local model.
3. Stable intermediate forms can be socially declared rather than actually stable. A milestone, design package, or concept may look complete because a system needs it to be complete.
4. State/process translation is powerful but not sufficient. Some failures are measurement failures, incentive failures, political failures, or ethical failures, not merely representation failures.

Evidence that would force revision:

- cross-boundary interactions repeatedly explain more variance than within-boundary interactions;
- the same subsystem belongs indispensably to many competing decompositions;
- failures cluster around incentives or power rather than structure or dynamics;
- models with less hierarchy and more simulation, narrative, or agent-level detail perform better;
- practitioners cannot identify stable intermediate forms that survive real handoff.

The safe conclusion is not "all complexity is hierarchy." It is: when a system has enough hierarchy, redundancy, sparse interaction, and stable intermediates, Simon gives us a powerful way to choose abstractions, name their valid range, and recover intelligently when they fail.