Synthesis: Layer 4 Session Review

Status: Session synthesis. What we found, what's missing, what it means.

1. What's confirmed and solid

Layer 4 exists as a genuine layer. Six primitives {Fw, Mn, Cx, Ls, Cp, Tj} passed the three-test criterion, have a dependency DAG, two core triads {Mn,Cx,Ls} and {Mn,Cx,Tj}, anchor pair Mn-Cx, 31.25% filter. Holds up across all tested instances.

No Layer 5. Every candidate reduced to existing concepts — process patterns (OODA), meta-properties (specificity), cross-layer operations (aggregation), or parameters (tempo, cadence).

Existing strategic frameworks are partial instantiations. OODA, Porter, SWOT, TRL all map to Layer 4 subsets at specific Fw levels. Structural prediction, testable.

The methodology doesn't require physics. It works for pure abstractions. Physics enters only when you constrain to specific physical instances. The methodology is about structural analysis, period.

2. What's missing from the Layer 4 analysis

The domain analysis found the right primitives but missed a structural dimension. The issue surfaced as repeated confusion about physics, coupling, and abstraction level. Diagnosis:

2.1 Manifestation conflates position and scope

The current Mn primitive captures WHERE an entity sits in the lattice (position) but not HOW SPECIFIC the entity is (scope).

"Git" and "Git on my laptop" have the SAME position in the entity system lattice: {E-Full, I-Full, T2, M0, X0, P0}. But they're different manifestations:

• "Git" = a CATEGORY. Many dimensions unfixed (hardware, OS, config, user). Universal claims.
• "Git on my laptop" = a constrained category. Some dimensions fixed. More specific claims.
• "This Git process PID 42 right now" = an INSTANCE. All dimensions fixed. Particular claims.

Mn's current partial levels (Mn0-Full) describe BREADTH — how many domains are included in the position. They don't describe SCOPE — how constrained the entity is. These are orthogonal.

2.2 The Mn-Cx boundary shifts with scope

This is the "weird interplay" between manifestation and context.

At universal scope:

• Mn = structural position (small — just lattice coordinates)
• Cx = era-level conditions (broad — "the cloud era")
• Many dimensions FREE (not in Mn or Cx — just unspecified)

At particular scope:

• Mn = specific instance with all properties (large — includes hardware, state, location)
• Cx = local conditions (narrow — "this room, this network, this moment")
• No free dimensions — everything is either Mn or Cx

The boundary between what's "the entity" (Mn) and what's "the environment" (Cx) is NOT fixed. It's determined by scope. When you increase scope (constrain more), Mn absorbs dimensions and Cx localizes. When you decrease scope (abstract more), Mn shrinks and Cx broadens.

This means Mn and Cx are NOT structurally independent the way the domain analysis presented them. Cx was classified as an "independent root" — no prerequisites. That's true at the PRIMITIVE level (you can analyze context without a manifestation). But at the OPERATIONAL level, the content and boundary of Cx depends on the scope of Mn.

2.3 Coupling, landscape, and trajectory all shift with scope

Every primitive transforms when scope changes. Same structural role, different content. The Layer 4 analysis captured the primitives but not this transformation.

2.4 What "locking in" means

The user's key phrase: "anytime you make a manifestation you're locking in the specificity."

To do applied analysis, you CHOOSE a scope. That choice:

1. Fixes which dimensions are part of Mn (the entity's properties at this scope)
2. Fixes which dimensions are Cx (external conditions at this scope)
3. Determines how Ls, Cp, Tj behave (categories vs instances, structural vs physical, epochs vs days)

Changing your analysis = MOVING the scope. Locking in = choosing a scope and holding it fixed for one analytical pass. The OODA loop = making a pass at one scope, then potentially shifting scope for the next pass.

Joint manifestation = locking in TWO manifestations AND their coupling at a specific scope. "This developer using this workbench right now" = Mn₁ + Mn₂ + Cp at particular scope.

Running the landscape analysis = locking in at universal scope. "How does the entity system compare to AT Protocol?" = Mn₁ + Mn₂ + Ls at universal scope. No physics because both entities are categories.

3. What this means structurally

3.1 Scope is a dimension of the entire Layer 4 analysis, not of any one primitive

Scope isn't a property of Mn alone. It's a property of the ANALYSIS. When you choose scope, ALL primitives shift together. You can't have Mn at particular scope and Cx at universal scope — they co-vary.

This is analogous to how, in Layer 1, partial levels are a property of PRIMITIVES (each primitive has its own levels) but the overall resolution of the analysis is set by the analyst. In Layer 4, scope is a property that applies to the entire analytical pass.

3.2 Scope might be a hidden dependency in the Layer 4 lattice

The Layer 4 domain analysis found Cx as an independent root (no prerequisites). But the Mn-Cx interplay suggests there's a hidden structural connection: the BOUNDARY between Mn and Cx is determined by scope.

This doesn't invalidate the dependency DAG (Cx can still be analyzed independently at any fixed scope). But it means the Layer 4 analysis has an additional dimension it didn't capture — the scope parameter that transforms all primitives simultaneously.

3.3 The category theory connection

At universal scope: manifestation is a FUNCTOR from lattice to category of instances. At particular scope: manifestation is a specific OBJECT in that category.

Changing scope = applying NATURAL TRANSFORMATIONS that restrict or generalize the functor.

The lattice (from Layers 1-3) is the structural space. Layer 4 operates in this space. Scope determines WHETHER Layer 4 operates on the space abstractly (functors, categories) or concretely (objects, instances).

This is why the methodology works at any abstraction level: the lattice structure is the same regardless of scope. Only the CONTENT of the analysis changes.

4. What should change in the methodology

4.1 Manifestation needs a scope dimension

The Mn partial levels should be revised to have TWO orthogonal dimensions:

Breadth (current Mn0-Full): how many domains

• Mn-B0: uncharacterized
• Mn-B1: single-domain position
• Mn-B2: multi-domain
• Mn-B3: unified (all connected domains)
• Mn-B4: decomposed (subsystems separated)

Scope (new): how constrained

• Mn-S0: universal — the category itself (all instances)
• Mn-S1: class — constrained category (some dimensions fixed)
• Mn-S2: configuration — heavily constrained (many dimensions fixed)
• Mn-S3: instance — specific entity (all structural dimensions fixed)
• Mn-S4: event — specific moment (all dimensions including temporal fixed)

A full manifestation characterization specifies BOTH: "Git at Mn-B3/Mn-S0" = unified manifestation of the Git category. "This Git process at Mn-B3/Mn-S3" = unified manifestation of a specific instance.

4.2 Context co-varies with scope

Cx's partial levels should acknowledge that context LOCALITY shifts with Mn's scope:

• When Mn is at Mn-S0 (universal): Cx describes era-level conditions
• When Mn is at Mn-S3 (instance): Cx describes local conditions
• The context domain's primitives are the same — their RESOLUTION changes

4.3 The Mn-Cx pair description should note the boundary shift

The current pair description ("bottleneck identification") is correct but incomplete. Add: "the boundary between Mn and Cx co-varies with scope — increasing scope absorbs dimensions into Mn and localizes Cx."

4.4 A note on scope in the methodology

The methodology document should note: Layer 4 analysis occurs at a chosen scope. Scope determines whether the analysis is about categories (abstract, physics-free) or instances (specific, potentially physically grounded). All six primitives transform with scope. The analyst locks in scope for each analytical pass and may shift scope between passes (the OODA cycle across abstraction levels).

5. Does this resolve the "something more"?

5.1 What it resolves

• The physics confusion: physics enters at particular scope, not by methodology requirement. Resolved.
• The coupling confusion: coupling between categories is structural; coupling between instances may be physical. Same primitive, different scope. Resolved.
• The joint manifestation question: locking in two manifestations + coupling at a specific scope. Derived concept, scope-dependent. Resolved.
• The landscape question: landscape of categories (Ls at universal scope) vs landscape of coupled instances (Ls at particular scope). Same primitive, different content. Resolved.
• The OODA question: cycling through Layer 4, potentially shifting scope between passes. Process pattern using scope as parameter. Resolved.

5.2 What it doesn't resolve

• Is scope a primitive, a dimension, or a meta-property? Tentative: dimension of the analysis (like partial levels in Layer 1). Needs 3/3b treatment.
• Does the Mn-Cx boundary shift imply they're not truly independent? Maybe. At the primitive level they're independent (you can analyze each at a fixed scope). At the operational level they co-vary. This might mean the Layer 4 dependency DAG is incomplete.
• Are there domains where scope doesn't apply? Pure abstractions (category theory, information theory) only have universal scope — there are no particular instances of "the category of groups." Does scope only apply when the domain HAS instances? Probably — and that's fine. Scope is relevant when you're analyzing MANIFESTED things. Pure abstractions don't manifest.
• Does the scope dimension change the Layer 4 domain analysis results? It might change pair loads (Mn-Cx might be HEAVIER when scope co-variance is accounted for). It shouldn't change the primitive set (scope is a dimension of the existing primitives, not a new primitive). But this needs checking.

5.3 The honest status

We've identified a missing structural dimension (scope) that resolves the confusions we encountered. Adding scope as a dimension of Layer 4 analysis fixes the physics problem, the coupling problem, and the Mn-Cx interplay. It doesn't require new primitives — it adds an orthogonal dimension to the existing ones.

Whether this means:

• (a) Layer 4's Mn needs revised partial levels (two-dimensional: breadth × scope) — minimal change
• (b) Scope is a structural feature of Layer 4 analogous to partial levels in Layer 1 — moderate change
• (c) There's a missing domain of "scope operations" (constrain, abstract, transfer) that connects to Layer 4 — larger change

...depends on further analysis. The user's intuition that "there's a domain of using the system" may be pointing at (c). The constrain/abstract/transfer operations are what you DO when using the methodology, and they operate on the scope dimension. Whether those operations have their own primitive structure is an open question.

6. Session inventory and status

7. Scope as a Primitive: Full Analysis

The confusions weren't resolved by treating scope as a dimension or meta-property. They persisted because scope IS a primitive — a missing structural unit of Layer 4.

7.1 Three-test criterion

Structural minimality: Removing scope means you can't distinguish "Git" (the category) from "this Git process" (the instance). The methodology oscillates between abstract and concrete analysis without vocabulary to notice it's doing so — exactly the confusion pattern we experienced. Removing scope forfeits the ability to control what level of abstraction you operate at. ✓

Compositional productivity:

• Sc + Mn = entity at specified scope ("Git the category" vs "this Git process")
• Sc + Cx = context at matching locality (era vs room — the boundary shift)
• Sc + Cp = coupling character (structural relationship vs physical event — resolves physics confusion)
• Sc + Ls = landscape character (set of categories vs network of instances)
• Sc + Tj = trajectory grain (epochs vs daily commits)
• Sc + Fw = framework resolution (general methodology vs this session's application)

Every combination produces a qualitatively different analysis. ✓

Empirical recurrence: Every applied analysis makes scope choices. The 9 unified manifestations: Sc0 (universal — categories positioned). The keypress trace: Sc4 (event — specific physical interaction). Entity system checkpoint: Sc1-2 (class/configuration — specific project, abstracted hardware). Every strategic framework operates at implicit scope (TRL at Sc0, SWOT at Sc1). ✓

7.2 Partial levels

Phase transition Sc0→Sc1: Domain-specific constraints enter. Below: pure structural claims (true for all instances). Above: platform/era constraints bind. The analysis becomes context-dependent.

Phase transition Sc2→Sc3: For physically-grounded domains, this is where physics becomes load-bearing. Below: the analysis applies to many possible physical instances. Above: a specific physical realization — all hardware/computing dimensions fixed. This is the transition the physics confusion was about: physics enters at Sc3, not as a methodology requirement, but as a consequence of constraining to a specific instance in a physical domain.

For NON-physical domains (pure math, category theory): Sc3 may not exist. There's no "specific instance" of the category of groups — the category IS the universal. Scope levels stop at Sc0-Sc2 for domains without physical realization.

7.3 Dependencies (revised Layer 4)

Fw → Mn (positioning requires framework)
Fw → Sc (scope requires framework to define fixable dimensions)
Mn → Ls (landscape requires manifestations)
Mn → Cp (coupling requires manifestations)
Mn → Tj (trajectory requires manifestation)
Cx: independent root

Sc and Mn are SIBLINGS — both depend on Fw, neither depends on the other. You can set scope before choosing an entity ("I want instance-level analysis"), and you can position an entity before choosing scope (defaulting to Sc0 universal). But they interact heavily (Mn-Sc is a heavy pair).

      Fw
     / | \
    Sc Mn  (siblings, both from Fw)
       |\ 
       | \→ {Ls, Cp, Tj}
    Cx (independent root)

7.4 Filter

2^7 = 128 total subsets. Coherent: if Mn → Fw, if Sc → Fw, if {Ls,Cp,Tj} → Mn → Fw. Cx independent.

Without Cx: 19 coherent. With Cx: 38 coherent.

Filter: 38/128 = 29.7%

This matches Layer 1's filter exactly (29.7%). The addition of Scope tightened the filter from 31.25% (6 primitives) to 29.7% (7 primitives). The tightening is because Sc adds another Fw dependency, reducing the number of valid subsets.

7.5 Pair analysis (new and changed pairs)

C(7,2) = 21 pairs. The 15 original pairs are unchanged. Six new pairs:

Revised heavy pair count: 8 out of 21 = 38%.

Revised hubs:

• Mn: 5 heavy (Fw-Mn, Mn-Cx, Mn-Ls, Mn-Tj, Mn-Sc) — strongest hub
• Cx: 4 heavy (Mn-Cx, Cx-Ls, Cx-Tj, Cx-Sc) — strong co-hub
• Sc: 2 heavy (Mn-Sc, Cx-Sc) + 4 medium — well-connected

7.6 Core triads (revised)

{Mn, Cx, Sc} — The Analytical Frame ★ NEW CORE TRIAD

All three pairs heavy (Mn-Cx, Mn-Sc, Cx-Sc). Irreducible:

• Mn+Cx without Sc = entity in context but you don't know if you're talking about the category or a specific instance (the original confusion)
• Mn+Sc without Cx = entity at scope but unconstrained (positioned but no bottleneck analysis possible)
• Cx+Sc without Mn = scoped context with nothing to constrain (environment with nobody in it)

This triad IS the analytical frame — "an entity, in its operating context, at a chosen level of specificity." You need all three before any other Layer 4 operation makes sense.

{Mn, Cx, Ls} — Strategic Positioning (unchanged)

All three pairs heavy. "Entity in context among peers." Still valid — Ls adds the spatial/comparative dimension to the analytical frame.

{Mn, Cx, Tj} — Trajectory Planning (unchanged)

All three pairs heavy. "Entity in context over time." Still valid — Tj adds the temporal dimension.

The three core triads share the Mn-Cx anchor and branch in three orthogonal directions:

                  Sc (scope — at what level of abstraction?)
                  |
            Mn —— Cx (anchor pair: entity-in-context)
           / \
          Ls   Tj
    (space —    (time —
     among whom?)  over what period?)

Three dimensions from one anchor: scope, space, time.

Fw provides the analytical lens for all three. Cp provides cross-chain reach. But the three core triads define the three fundamental questions of applied analysis:

1. "At what level am I analyzing?" → {Mn, Cx, Sc}
2. "Where does this sit among peers?" → {Mn, Cx, Ls}
3. "Where is this going?" → {Mn, Cx, Tj}

7.7 What Scope resolves

With Scope as a primitive, the confusions disappear structurally:

The physics confusion: Physics enters when Sc ≥ Sc3 in physically-grounded domains. At Sc0-Sc2, the analysis is abstract — structural claims about categories. At Sc3+, the analysis is concrete — claims about specific physical instances. Physics isn't a methodology requirement; it's a consequence of scope in physical domains.

The coupling confusion: At Sc0, coupling between Mn₁ and Mn₂ is a structural relationship between categories. At Sc3+, it's a physical interaction between instances. The coupling PATH only needs to be traced at Sc3+ (where physical mediation matters). At Sc0, coupling is an abstract edge.

The Mn-Cx boundary shift: At Sc0, Mn captures structural position (small) and Cx captures era-level conditions (broad). At Sc3, Mn captures the full specific instance (large) and Cx captures local conditions (narrow). The shift IS the Cx-Sc pair interaction — scope determines where the boundary falls.

Joint manifestation: Locking in two manifestations + coupling at a specific scope. Joint(A,B) at Sc0 = abstract coupling between categories. Joint(A,B) at Sc3 = specific physical interaction. The scope determines whether the joint system is abstract or concrete.

7.8 Revised Layer 4 structural signature

The structure is cleaner with 7 primitives. Three core triads branching orthogonally from the anchor pair in scope, space, and time. The filter tightened to match Layer 1 exactly (29.7%). Mn is a stronger hub.

7.9 The 3/3b stability check

Does adding Scope trigger any other changes?

Should any existing primitive split? No — Ls, Cp, Tj, Cx, Fw are all stable. Their interaction with Sc is captured by pair analysis, not by splitting.

Should any primitive merge with Sc? Mn-Sc is the heaviest new pair, but they're clearly different things: Mn is WHAT you're analyzing, Sc is HOW SPECIFICALLY. Merging would re-create the conflation that caused the confusion.

Does the dependency structure change? No fundamental change. Sc depends on Fw (same as Mn). Sc doesn't create new dependencies for other primitives.

Primitive set is stable at 7: {Fw, Mn, Sc, Cx, Ls, Cp, Tj}.

8. What the Seven Primitives Reveal: Further Exploration

8.1 Strategy vs tactics

The strategy/tactics distinction is one of the most universal in applied analysis. How does it map?

Strategy = analysis at LOW scope with emphasis on Ls and Tj.

• Sc0-Sc1: universal/class — you're thinking about categories, not instances
• Ls-heavy: where do we sit among peers? What's the competitive landscape?
• Tj-heavy: where are we going over years? What epoch are we in?
• Cx at era-level: "the cloud era," "the AI era"
• Coupling at Cp1-2: structural relationships between categories

Tactics = analysis at HIGHER scope with emphasis on Mn and Cp.

• Sc2-Sc3: configuration/instance — you're thinking about specific systems, specific interactions
• Mn-heavy: what exactly is our current position? What are the immediate constraints?
• Cp-heavy: how does the specific coupling work? What's the interface quality?
• Cx at local level: "our current team size," "this quarter's resources"
• Tj at short grain: "this sprint," "this release"

Operations = analysis at HIGHEST scope with emphasis on events.

• Sc4: event level — specific interactions at specific moments
• Cp at Cp4: physical coupling traced, latencies measured
• Tj at shortest grain: "this commit," "this user session"

So the strategy/tactics/operations hierarchy IS the Scope gradient:

The insight: strategy, tactics, and operations aren't different KINDS of analysis. They're the SAME analysis at different Scope levels. The same 7 primitives, the same lattice, the same pair interactions — just at different Sc settings.

This explains why organizations need all three simultaneously: each Scope level reveals different structure. A strategic analysis (Sc0) can't see the implementation bottleneck (visible only at Sc3). An operational analysis (Sc4) can't see the competitive positioning (visible only at Sc0). You need multiple scopes running concurrently, with findings propagating between them.

And this is where the OODA cycle connects: Boyd's nested loops (strategic OODA inside tactical OODA inside operational OODA) ARE Layer 4 runs at different Scope levels, with findings propagating up and down the Scope gradient.

8.2 Ontogenetic pathways and scope-locked traversal

Ontogenetic analysis — tracing how a specific entity develops over time — is a powerful applied mode. In the methodology, we've done this for:

• Git: 5 development epochs from creation to ecosystem maturity
• Computing: 8 epochs from mainframes to AI
• Application architecture: universal build-up order (D→Sh→Mt→Ac→Pc+Pn→...)
• Entity system: trajectory from initial spec through three implementations to current position

What's happening structurally in an ontogenetic analysis?

You LOCK scope and sweep time. Specifically:

1. Choose a manifestation (Mn) — "Git" or "the entity system"
2. Lock scope (Sc) — usually Sc0 or Sc1 (tracking the category, not a specific install)
3. Hold framework (Fw) fixed — same analytical lens throughout
4. Context (Cx) CHANGES along the time axis — Git in 2005 context vs 2025 context
5. Landscape (Ls) CHANGES along the time axis — different competitors at each epoch
6. Trajectory (Tj) IS the sweep — the sequence of positions over time
7. Coupling (Cp) may change — Git's coupling to developers evolved (CLI → GUI tools → IDE integration)

The ontogenetic pathway is:

At fixed Sc and Mn-identity:
  t₁: Mn(P₁), Cx(C₁), Ls(L₁), Cp(K₁)  →  observe position, context, landscape, coupling
  t₂: Mn(P₂), Cx(C₂), Ls(L₂), Cp(K₂)  →  position has changed, context may have shifted
  t₃: Mn(P₃), Cx(C₃), Ls(L₃), Cp(K₃)  →  ...

Mn's IDENTITY is fixed (it's still "Git" throughout) but Mn's POSITION changes (Git gains features, community grows). Cx changes independently (Moore's Law, cloud computing, etc.). Ls changes as competitors enter and exit.

The trajectory Tj IS the sequence: (P₁, C₁, L₁, K₁) → (P₂, C₂, L₂, K₂) → ...

The scope lock is critical. If you shift scope mid-analysis (from "Git the category" to "this specific Git installation"), the trajectory becomes incoherent — you've changed what you're tracking. Ontogenetic analysis REQUIRES scope stability.

8.3 Different scope locks for different pathway types

Phylogenetic pathway (category evolution): Sc0 locked. Track how a CATEGORY evolves. "How did version control systems evolve?" The manifestation is the category; scope is universal. Cx and Ls change. This is macro-evolution — landscape-level dynamics.

Ontogenetic pathway (individual development): Sc1-Sc2 locked. Track how a SPECIFIC SYSTEM develops. "How did Git develop from 2005 to 2025?" The manifestation is the project; scope is class/configuration. Cx and Ls change. This is development — one entity's trajectory.

Operational pathway (instance behavior): Sc3 locked. Track how a SPECIFIC INSTANCE behaves. "How does this Git server handle the Monday morning push rush?" The manifestation is the instance; scope is particular. Cx is local conditions (load, network). Cp traces actual physical interactions.

Event pathway (interaction sequence): Sc4, sweeping through events. Track a SPECIFIC INTERACTION SESSION. "This developer's Git workflow for today's code review." Each event is Sc4; the sequence of events IS the pathway.

Each pathway type is the SAME structural operation (scope-locked traversal along Tj) at a different Sc level. The analytical vocabulary is identical. Only the grain changes.

8.4 Comparative pathway analysis

The most powerful analytical move: run pathways at the SAME scope for DIFFERENT manifestations, then compare.

Same scope, different entities:

• Git's ontogenetic pathway (Sc1) vs Mercurial's ontogenetic pathway (Sc1)
• "Both started in 2005. Git froze substrate in 2 weeks. Mercurial evolved substrate gradually. Why?"
• Answer visible in the trajectories: Git's aggressive scope constraint (Linus's design decisions) vs Mercurial's broader exploration.

Same entity, different scopes:

• Entity system at Sc0 (strategic: "where does content addressing sit in computing history?")
• Entity system at Sc2 (tactical: "what SDK features should we build next quarter?")
• Entity system at Sc4 (operational: "why is the workbench slow when browsing large trees?")
• Same entity, three analyses. Findings at each scope inform the others.

Same scope, same entity, different contexts:

• Entity system trajectory in 2005 context vs 2026 context (same Sc1, same Mn, different Cx)
• This IS the "same substrate potential, different outcomes" that context domain analysis explains

8.5 What the strategy/tactics/operations mapping reveals about the primitives

The clean mapping confirms the primitive set. Strategy, tactics, and operations use ALL SEVEN primitives — they just weight them differently based on Scope:

Every cell has content. No primitive is unused at any level. The seven primitives span the full strategy-to-operations range.

8.6 Guidance for methodology use: operational patterns

The following are PATTERNS for using Layer 4, not additional primitives:

Scope-locked sweep (ontogenetic analysis): Fix Sc. Fix Mn identity. Sweep Tj. Observe Cx, Ls, Cp changing along the sweep. Produces: development history, lifecycle classification, trajectory prediction.

Multi-scope concurrent analysis: Run Layer 4 at Sc0, Sc2, Sc3 simultaneously for the same Mn. Compare findings. Strategic findings inform tactical priorities. Tactical findings reveal operational bottlenecks. Operational findings validate or invalidate strategic assumptions.

Scope descent (zoom in): Start at Sc0 (strategic overview). Identify an issue. Descend to Sc2 (which architectural component?). Descend to Sc3 (which specific implementation?). Descend to Sc4 (which interaction event?). Each descent adds physical specificity.

Scope ascent (zoom out): Start at Sc4 (a specific bug or performance issue). Abstract to Sc3 (is this instance-specific or general?). Abstract to Sc2 (is this a configuration issue?). Abstract to Sc0 (does this reflect a structural limitation of the category?). Each ascent removes specificity.

OODA as scope oscillation: Boyd's orientation phase often involves SHIFTING SCOPE — dropping from strategic to tactical to check assumptions, then rising back to strategic to adjust the plan. The scope shift IS the orientation. Fast scope traversal = fast orientation = tempo advantage.

These patterns are how you USE Layer 4's primitives in practice. They're not additional structure — they're the methodology's operational guidance for applied analysis.