Guide: Applied Analysis in Practice

Status: Practical guide for using Layer 4. Covers scope management, operational patterns, ontogenetic pathways, strategy/tactics/operations, and the OODA mapping. Companion to analysis-applied-analysis.md (formal domain analysis).

1. Scope: The Master Control

1.1 What scope determines

Scope (Sc) is the specificity of your analysis. It determines the character of everything else:

1.2 Choosing scope

Match scope to your question:

1.3 The methodology doesn't require physics

At Sc0-Sc2, analysis is abstract. Structural claims hold regardless of physical realization. "Git has content addressing" is true on any hardware.

At Sc3+, for domains with physical grounding, physical constraints enter — frame budgets, latencies, memory limits. For purely abstract domains (mathematics, information theory), Sc3+ may not apply.

Physics is a consequence of scope in physical domains, not a requirement of the methodology.

1.4 The Mn-Cx boundary co-varies with scope

At Sc0: Mn is small (structural position only), Cx is broad (era). Many dimensions are free. At Sc3: Mn is large (all properties of the instance), Cx is narrow (this room, this moment). Everything is either Mn or Cx.

This is structural, not an artifact. Scope determines what's "inside" the entity vs "outside" as environment.

2. Strategy, Tactics, and Operations

2.1 The scope gradient

Strategy, tactics, and operations aren't different kinds of analysis — they're the SAME seven primitives at different scope levels.

Strategy (Sc0-Sc1):

• Questions: competitive positioning, long-term direction, market viability
• Emphasis: Ls (landscape) and Tj (trajectory in epochs/years)
• Cx: era-level — "the cloud era," "AI era"
• Example: "Should the entity system target enterprise or developer tools?"

Tactics (Sc2-Sc3):

• Questions: what to build, which interfaces, resource allocation
• Emphasis: Mn (current position) and Cp (architectural coupling)
• Cx: quarterly — "this team's capacity," "this quarter's priorities"
• Example: "The SDK needs type-driven rendering before the workbench can improve."

Operations (Sc3-Sc4):

• Questions: performance, specific interactions, debugging
• Emphasis: Cp (specific coupling paths) and Mn (instance state)
• Cx: immediate — "this hardware," "this network"
• Example: "Entity tree reads are O(n) on path depth — needs caching."

2.2 Running multiple scopes concurrently

Organizations need all three simultaneously. Each scope reveals different structure that the others miss.

• Strategic findings inform tactical priorities ("competitive advantage is content addressing" → "invest in I-related SDK features")
• Tactical findings reveal operational requirements ("type rendering needs 16ms frame budget" → "optimize tree reads")
• Operational findings validate strategic assumptions ("users actually need offline-first" → "P is more important than we thought")

Propagation between scopes: findings at one scope trigger re-analysis at adjacent scopes.

3. Ontogenetic Pathways (Scope-Locked Traversal)

3.1 The pattern

An ontogenetic analysis locks scope and sweeps time:

1. Fix Mn identity — track the SAME entity throughout
2. Lock Sc — hold specificity constant
3. Sweep Tj — trace the trajectory over time
4. Observe Cx, Ls, Cp changing — context shifts, landscape evolves, coupling develops

At fixed Sc and Mn-identity:
  t₁: Mn(P₁), Cx(C₁), Ls(L₁)  → position, context, landscape at time 1
  t₂: Mn(P₂), Cx(C₂), Ls(L₂)  → position changed, context shifted
  t₃: Mn(P₃), Cx(C₃), Ls(L₃)  → ...

The scope lock is critical. Shifting scope mid-analysis (from "Git the category" to "this Git installation") breaks trajectory coherence — you've changed what you're tracking.

3.2 Pathway types by scope

3.3 Comparative pathway analysis

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

Same scope, different entities:

• Git (Sc1) vs Mercurial (Sc1): both started 2005. Git froze substrate in 2 weeks; Mercurial evolved gradually. Why? Different design decisions visible in the trajectories.

Same entity, different scopes:

• Entity system at Sc0: "Where does content addressing sit in computing history?"
• Entity system at Sc2: "What SDK features should we build this quarter?"
• Entity system at Sc4: "Why is the workbench slow browsing large trees?" Same entity, three analyses. Findings at each scope inform the others.

Same scope, same entity, different contexts:

• Entity system in 2005 context vs 2026 context. Same substrate potential. Different context → different trajectory. This IS what context domain analysis explains.

4. The OODA Mapping

4.1 Single cycle

Each pass through Layer 4 maps to one OODA iteration:

Orient is the heaviest phase. It corresponds to the Fw-Mn pair (heaviest pair in Layer 4): framework-informed positioning. This is where mismatches between prediction and reality surface — and where the framework itself may need revision (Boyd's "destructive deduction" = L4→L1 feedback).

4.2 Scope oscillation

Boyd's nested OODA loops (strategic, tactical, operational) are the SAME Layer 4 cycle at different scope levels.

Fast scope traversal = fast orientation. When you can quickly zoom from Sc0 (strategic picture) to Sc3 (specific issue) and back, you orient faster than someone locked at one scope level.

AI-assisted methodology cycles are much faster than manual ones (20K-30K lines of structured analysis per session). This IS a tempo advantage — more OODA cycles per unit time, at multiple scope levels.

4.3 Scope descent and ascent

Descent (zoom in): Strategic analysis identifies "coupling is the bottleneck" (Sc0). Drop to Sc2: which coupling segment? "Semantic coupling — type rendering." Drop to Sc3: what specifically? "Entity→app bridge for type lookup is O(n)." Fix it. Return to Sc0.

Ascent (zoom out): Find a specific bug (Sc4). Is this instance-specific (Sc3)? Is this a configuration issue (Sc2)? Does this reflect a category-level limitation (Sc0)? Each ascent removes specificity, tests generality.

4.4 Multi-perspective analysis

Run Layer 4 from different perspectives (different Mn as subject):

1. Developer perspective: Mn = entity system, question = "what should I build?"
2. User perspective: Mn = application on entity system, question = "what can I do?"
3. Competitor perspective: Mn = AT Protocol, question = "what are we missing?"

Aggregate with Layer 3: find patterns across perspectives. Where perspectives converge = robust finding. Where they diverge = genuine tension to address.

5. Joint Manifestation

5.1 What it is

When two entities couple at a specific scope, the coupled system has a joint state:

Joint(A, B) at Sc = Mn(A) × Cp(A↔B) × Mn(B), all at scope Sc

At Sc0: abstract joint — "developers and version control systems" (category coupling). At Sc3: concrete joint — "this developer using this workbench on this laptop" (instance coupling).

5.2 Why it matters

The joint system's capabilities are bounded by the weakest coupling segment. A developer (high Kw, Sk) coupled through a poor tool (low Pc, Pn) = poor joint system. The bottleneck isn't either participant — it's the coupling.

5.3 Joint manifestation at different scopes

6. Landscape Network Structure

6.1 Landscape at different scopes

At Sc0-Sc2 (strategic): Ls is a set of categories positioned in a lattice. This is adequate for competitive analysis — where do Git, SVN, Mercurial sit relative to each other?

At Sc3+ (operational): Ls becomes a GRAPH of coupled instances. Not just "14 systems positioned" but "14 systems coupled to each other, to developers, to users, forming a network."

6.2 Network properties

At high scope, landscape analysis can reveal:

• Hub identification — which entities are most heavily coupled (GitHub as a hub)
• Cluster structure — tightly-coupled subsystems (the JavaScript ecosystem as a cluster)
• Coupling asymmetry — directed dependencies (developers depend on libraries; libraries don't depend on specific developers)
• Network dynamics — how the coupling graph evolves (new entrants, migrations, deprecations)

7. Coupling at Different Scopes

7.1 Abstract coupling (Sc0-Sc2)

Coupling between categories is a structural relationship. "Developers couple to version control through CLI" — this is a structural claim about a class of interactions. No physical mediation needs to be traced.

Conceptual coupling is real coupling at abstract scope: two mathematical structures can be coupled through shared properties. Two ideas in a cognitive architecture can be coupled through association. These couplings exist at Sc0 without any physical dimension.

7.2 Mediated coupling (Sc3+)

Coupling between specific instances has a mediation path — the sequence of domains the interaction traverses. For physical domains, this path includes physical substrate.

A keypress (Sc4, physical domain):

Cognitive → Organism → Hardware → Computing → Entity system → App arch
  → (return path through hardware and organism)

A mathematical insight connecting two fields (Sc0, abstract domain):

Theory A → shared structure → Theory B

No physics. Pure abstract coupling.

The methodology handles both. The coupling PATH only needs tracing at Sc3+ for physical domains.

8. Existing Frameworks as Partial Instantiations

Every major strategic/analytical framework maps to a subset of Layer 4's primitives at specific scope:

These frameworks aren't wrong — they're partial. Each one covers a subset of the full applied analysis at a specific scope and framework resolution. Our methodology is the general case they all partially instantiate.

9. The Methodology's Power Boundary

9.1 Where analysis ends and building begins

The methodology's structural analysis is powerful at Sc0-Sc1. It weakens as scope increases. This isn't a flaw — it's the nature of the tool.

The Sc1→Sc2 transition is the methodology's power boundary. Above it: analyze. Below it: build and test.

9.2 Scope determines the validation method

Each level has its own validation method. Using the wrong method at the wrong scope wastes effort:

• Analyzing at Sc3 (trying to structurally derive performance characteristics) doesn't work
• Prototyping at Sc0 (building something to test whether "substrates have ~6 primitives") is overkill
• Measuring at Sc1 (benchmarking to decide SDK architecture) answers the wrong question

9.3 Scope descent for experiments

When a Sc0-Sc1 analysis produces a claim that needs validation at a lower scope, the experiment is a scope descent:

Sc0 claim: "Extension interactions are type-agnostic"
    ↓ (descent to Sc2)
Sc2 experiment: "Build a generic history viewer. Test with 3+ entity types."
    ↓ (if validated, descent to Sc3)
Sc3 validation: "Does it perform acceptably?" → measure

Scope-lock the experiment. Don't descend from Sc2 to Sc3 until the Sc2 question is answered. If you start optimizing performance (Sc3) before confirming the architecture works (Sc2), you risk optimizing the wrong design.

The three experiments from the SDK session are scope descents:

1. Generic history view: Sc0→Sc2 (highest value — tests fundamental structural claim)
2. Self-describing presentation: Sc1→Sc2-3 (tests architectural proposal)
3. Workspace transfer: Sc1→Sc3 (tests physical transfer of state)

Priority follows scope distance: the shortest descent (Sc0→Sc2) gives the most structural information per effort.

9.4 The three state layers ARE scope levels

The interface/coupling analysis found three state layers. They map directly to scope:

Workspace sync between devices IS scope-mediated transfer:

1. Desktop instance (Sc3) → abstract workspace state (Sc1) — extract what's scope-independent
2. Transfer at Sc1 — the interaction state travels
3. Abstract workspace → phone instance (Sc1 → Sc3) — re-instantiate on new hardware

What survives the round trip = what's at Sc0-Sc2. What's lost = what's at Sc3+. The "adaptation" problem ("what does the phone do with sort preferences it can't fully honor?") is: re-instantiating Sc1 state on Sc3 hardware that has different capabilities. The phone applies what it can and ignores what it can't.

10. Sub-Level Analysis and Transition Exploration

10.1 When to zoom in

Coarse resolution (primitive-presence, ~6 levels per primitive) is sufficient for most analytical work — structural comparison, landscape positioning, trajectory planning, context bottleneck identification. Sub-level decomposition adds cost (analyst effort, detail management) and should be done only when it adds value.

Zoom in when:

• A phase transition is poorly understood ("how does R0→R2 actually work?")
• A bottleneck needs internal diagnosis ("which sub-step within X0→X2 is blocking?")
• Conditional dependencies may exist ("does advancing A past level x require B at level y?")
• The mechanism matters for prediction ("what environment enables this transition?")
• Two domains appear independent at coarse resolution but may be coupled at fine resolution

Stay at coarse resolution when:

• Comparing systems across the landscape ("where does Git sit relative to Mercurial?")
• Identifying context bottlenecks ("which context primitive is the binding constraint?")
• Planning trajectory at strategic scope ("what should we build next quarter?")
• The transition is well-understood or designed (no hidden mechanism to discover)

10.2 How to decompose a transition

Step 1: Identify what changes. Which primitives advance during this transition? Which bridge primitives co-vary? Which context primitives shift?

Step 2: Decompose the advancing primitives into sub-levels. For each primitive that advances, identify intermediate configurations that are qualitatively distinct. Use domain-specific knowledge (molecular biology for biological transitions, design history for designed transitions, neural/cognitive science for cognitive transitions). Aim for 4-10 sub-levels per advancing primitive.

Step 3: Map dependencies at sub-level resolution. For each sub-level, ask: what must already exist for this sub-level to be reached? Look for conditional partial-level dependencies: Dep(A ≥ x, B ≥ y). These are the constraints that shape the product corridor.

Step 4: Construct the product corridor. The walk through the transition is not a single-primitive advance — it's a multi-coordinate path through a product sub-lattice. Map which coordinates change at each step. The corridor is the set of positions where all sub-level dependencies are satisfied.

Step 5: Identify internal phase transitions and bottlenecks. Where does the tangent set |T(P)| change discontinuously within the transition? Where does the walk rate slow down? The slowest sub-step is the internal bottleneck. Phase transitions within the transition identify the mechanism of the coarse transition.

Step 6: Check for structural patterns. Does the transition contain an autocatalytic spiral (two primitives co-advancing through feedback)? A crystallization event (a structural variable freezing)? A pre-separation fusion (two entities that separate during the transition)? These patterns, if present, have specific signatures and implications (see methodology.md §2.5).

10.3 Forward walks vs reverse walks

Forward walks (traditional): Start from the current position. Compute the tangent set. Choose a move. Advance. Repeat. Good for trajectory planning and design opportunity discovery.

Reverse walks (convergent reconstruction): Start from a known endpoint. Work backwards through structural constraints to reconstruct the trajectory. Good for historical analysis and understanding genesis events.

When to use which:

Combining forward and reverse: For poorly understood transitions, run both. The forward walk identifies all possible sub-levels; the reverse walk from the known endpoint constrains which path was actually taken. Where forward and reverse walks CONVERGE on the same corridor, confidence is high. Where they diverge, there's genuine uncertainty about the mechanism.

10.4 Multi-constrained system analysis

When analyzing systems constrained by multiple connected lattices simultaneously (product lattice positions), Layer 4 analysis should address all constraining dimensions:

The three-constraint model for any system:

1. Internal coherence — dependencies within the domain's lattice (Step 4)
2. Cross-domain coherence — bridge and realization constraints from connected lattices (§4.5)
3. Context feasibility — context domain constraints on which moves are achievable (§7.2)

A move is available only if all three constraints are satisfied. The tangent set T(P) at any product-lattice position is the intersection of moves permitted by all three.

Bottleneck identification: For each blocked move, determine WHICH constraint blocks it:

• Internal: "this primitive depends on another primitive that hasn't advanced yet"
• Cross-domain: "the bridge hasn't reached the level needed to support this advance"
• Context: "the environment doesn't support this advance yet (insufficient resources, wrong conditions)"

The bottleneck type determines the remedy:

• Internal bottleneck → advance the prerequisite primitive first
• Cross-domain bottleneck → invest in bridge development
• Context bottleneck → wait for context change, or move to a different context (if possible)

10.5 Landscape analysis during transitions

At coarse resolution, the landscape (Ls) is typically treated as static within a single analytical pass. At sub-level resolution within a transition, the landscape itself TRANSFORMS — and the transformation can be part of the mechanism.

Biology's genesis: the landscape goes from empty (no biological peers) to populated (protocell populations with selection) at R1.7 — DURING the R0→R2 transition, not at its completion. The landscape emergence is part of the mechanism (vesicle-level selection solves the parasite problem, enabling the code to expand).

When analyzing transitions, track Ls at each sub-level. The landscape may:

• Appear (genesis: empty → populated)
• Transform in character (chemical microenvironments → protocell populations → free-living cells)
• Enable a sub-step that would otherwise be blocked (selection requires a landscape)
• Constrain the walk rate (landscape competition determines how fast exploration proceeds)

11. When to Use What

11.1 The three-document relationship

11.2 Quick reference: what to do at each scope

I'm doing strategic analysis (Sc0-Sc1): → Use the methodology's full structural toolkit. Position the manifestation. Identify context bottlenecks. Compare against landscape. Plan trajectory. This is where the methodology is MOST powerful.

I'm making architectural decisions (Sc2): → The methodology can PROPOSE architectures and IDENTIFY concerns. But it can't VALIDATE designs. Build a small prototype. Test the specific claim. Scope-lock the experiment.

I'm debugging or optimizing (Sc3-Sc4): → The methodology can tell you WHICH quantities matter (based on lattice position) and WHERE to look (based on coupling path). But it can't predict VALUES. Measure. Profile. Observe.

I'm stuck between scopes: → You're probably mixing scope levels. Separate the questions by scope. Answer the Sc0-Sc1 questions with analysis. Answer the Sc2 questions with prototyping. Answer the Sc3+ questions with measurement. Don't try to use analysis to resolve design choices, or measurement to resolve strategic questions.