flight-lines

name

flight-lines

description

Navigate problems along lines of flight by composing operations from arbitrary domains. Operations are deterritorialized capacities—they don't belong to their origin domains. Mycorrhizal signaling + ham radio protocols + rare book dealer networks can compose into a single assemblage. Use this whenever a problem has multiple parallel concerns, when domain-standard approaches feel exhausted or constraining, or when you sense a problem wants a different kind of solution than its obvious category provides. The composer maintains parallel work-paths, constantly revising as new structure emerges.

Flight Lines

Theoretical Ground (compressed)

Knowledge gets stratified into domains—epidemiology, jazz theory, mycology, contract law. Useful for organizing expertise, but not fundamental boundaries. They're territories.

Beneath the strata are operations: deterritorialized capacities that got captured by a domain through historical accident. "Sentinel surveillance" isn't essentially about disease—it's a capacity: strategic monitoring of high-signal nodes in a sparse search space. "Reharmonization" isn't essentially about jazz—it's changing underlying structure while preserving surface continuity.

The conventional move stays within domain boundaries: dating advice for dating problems, language pedagogy for language problems. That's navigating along the strata—safe, predictable, limited. Lines of flight are movements that escape stratified territory. When you recognize that one domain's operation addresses the same structural constraint as a problem in a completely different domain, you're accessing operations on a plane of consistency where domain labels don't constrain what composes with what.

You already know the Deleuze. This document means it operationally, not decoratively. The rest is procedure.

Key insight: Operations compose on structural fit, not semantic coherence. An assemblage of mycorrhizal networks + ham radio + rare book collecting is domain-incoherent but can be structurally coherent for a given problem.

The Operation Card

This is the central object. An operation is not a concept, metaphor, or analogy. It is a specific capacity, and you certify it by filling out a card. If you can't fill every field with something concrete, you have a metaphor wearing a trenchcoat — discard it.

OPERATION: <name> (origin domain: <domain>)
- ACTS ON:    <input structure — described structurally, not by domain>
- PRODUCES:   <output structure>
- PRESERVES:  <invariants that hold under the transformation>
- TRANSFORMS: <what necessarily changes>
- EXECUTE:    <concrete procedure — actual actions, not "be more X">

The EXECUTE field is the lie detector. "Broadcast specific criteria through existing contacts and let matches come to you" is executable. "Apply mycelial thinking to your network" is not.

The card is also a typechecker. An operation only enters an assemblage if (a) its card is complete and (b) its ACTS ON structure matches the structural constraint you're trying to address. Two operations conflict if one's PRESERVES is the other's TRANSFORMS over the same structure. Check this explicitly before composing — don't assert structural coherence, test it.

The Compositional Method

Not a linear pipeline. An ongoing process with parallel paths and constant revision: probe, act, sense, respond — not analyze, plan, execute.

1. Map the Terrain

Don't ask "what kind of problem is this?" (that seeks a stratum to stay inside). Ask: "What are the parallel concerns, and what structural property makes each one hard?"

Most non-trivial problems have multiple concerns running in parallel. Surface them, then for each, name the constraints. A structural constraint is a property that creates difficulty independent of domain framing:

• Sparse signal in noise (most probes are misses)
• Cold start (no existing network to leverage)
• Resource scarcity (limited time, energy, money)
• Information asymmetry (can't assess from outside)
• Temporal dynamics (windows, decay rates, ordering)
• Network topology (fragmented patches, no clear hubs)
• High per-probe cost (each attempt is expensive)
• State flux (the thing you're acting on is itself changing)

2. Strip to Domain-Free Language FIRST

This is the step that makes distant retrieval possible, and it's the step people skip. Before querying for operations, restate each constraint with every domain word removed. Not "I need to find friends in a new city" but "sparse signal, high per-probe cost, asymmetric observability, cold start." Not "my test suite is flaky" but "intermittent signal, non-reproducible state, observability gap between failure and cause."

The abstraction is the wormhole. A constraint stated in its home domain only retrieves operations from that domain. A constraint stated structurally retrieves from everywhere.

3. Query by Deliberate Domain Sampling

The generative core. "Query across everything you understand" is true but unprocedural, so make it procedural: for each domain-free constraint, force one candidate operation from each of several distant domain families before evaluating any of them. A working set of families:

• Biological / ecological (succession, symbiosis, metabolism, immune response)
• Signal / communications (protocols, broadcast, impedance matching, error correction)
• Economic / market (loss leaders, arbitrage, liquidity, price discovery)
• Mechanical / physical (resonance, leverage, phase transition, load distribution)
• Institutional / social (guilds, credentialing, gossip networks, ritual)
• Computational / information (caching, indexing, load balancing, version control) Sampling across families is what prevents the failure mode below. Generate first, evaluate second — don't let the first plausible operation collapse the search.

Anti-pattern — territorialized repertoire. This skill repeatedly uses a handful of operations (sentinel surveillance, mycorrhizal sharing, CQ calls, nurse logs) as teaching examples. Do not reach for them by default. A skill about deterritorialization can grow its own stratum, and the demonstrated set is exactly that stratum. Treat the examples in this document as illustrations of the method, not as your operation library. Any operation you actually use must independently pass the operation-card check for the specific problem in front of you.

4. Compose Assemblages (Parallel Paths)

Don't build one master plan. Open multiple lines simultaneously. For each line, certify operations via cards, check pairwise for invariant conflicts, and assemble. Domain mixing is expected, not anomalous — if your assemblage spans 4+ unrelated families, you're probably generating something novel. Homogeneous assemblages (all one domain) signal you've stayed in conventional territory; fine when that works, a flag when you wanted a line of flight.

5. Execute and Observe

Run operations, generate concrete outputs — specific actions, real artifacts, actual protocols. This is the fidelity test: if you can produce concrete outputs, the composition is working. If you can only produce more description, it isn't.

6. Revise Based on New Structure

Execution changes structure; new structure reveals constraints analysis missed; new constraints suggest new operations. This is the live part of the loop:

• Selective intensification: most lines go nowhere, a few resonate. Intensify those, let others go dormant. Don't optimize everything at once.
• Breakdowns are information. When an operation doesn't quite fit, the friction reveals a constraint you hadn't modeled. "This assumed fixed patches, but my targets are temporally unstable" → you just discovered a temporal-dynamics constraint.
• Operations feed forward. One operation's output becomes the selector for the next, and pulls in adjacent operations (and adjacent domains) you didn't start with.
• Reterritorialization is fine. Not every line must stay deterritorialized. Sometimes you find a new stratum that works. The goal isn't permanent flight — it's the capacity to take a line of flight when the strata aren't serving.

7. Iterate Until Stable, or Until the Question Transforms

The process ends when the assemblage is stable and sustainable, OR when the becoming-work has changed what you're even trying to do — you're now asking a different question. The composer has no fixed end state. It's a way of navigating.

Two Compressed Worked Examples

The point of two is to show the method generalizes across problem classes. Note that neither reuses the other's operations, and the operations are derived freshly, not pulled from a stock list.

A. Technical — A flaky distributed test suite

Concerns: reproducibility, signal attribution, developer trust. Domain-free constraints: intermittent signal; observability gap between failure and cause; high per-probe cost (full runs are slow); state contamination across probes.

Sampled operations (one per family, then filtered by card):

• Sterile technique (biological — surgery/microbiology): isolate each probe from contamination. EXECUTE: hermetic per-test fixtures, no shared mutable state, fresh DB per test. Card passes; ACTS ON = contaminated shared state, exactly the constraint.
• Error-correcting codes (signal): tolerate intermittent corruption by adding redundancy that localizes the fault. EXECUTE: run suspected-flaky tests N times, treat the pattern of pass/fail as a fingerprint pointing at the cause class.
• Bisection (computational): collapse a large search space logarithmically. EXECUTE: git bisect against the first flaky commit to localize introduction. Assemblage: isolate (kill contamination as a cause) → fingerprint (attribute the residual intermittency) → bisect (localize what's left). Invariant check: sterile technique preserves test ordering independence, which fingerprinting relies on — no conflict. Note: zero operations from "software testing." The line of flight went through surgery and information theory.

B. Institutional — A nonprofit losing volunteers faster than it recruits

Concerns: retention, recruitment, identity/belonging. Domain-free constraints: decay dynamics outpacing inflow; cold start for newcomers; weak legibility (newcomers can't read the culture; the org can't read fit).

Sampled operations:

• Nurse logs (ecology): dead structure as substrate for new growth. EXECUTE: departing volunteers' projects become onboarding material for newcomers, so attrition seeds rather than just drains.
• Apprenticeship / guild progression (institutional): legible status ladder that converts vague belonging into visible milestones. EXECUTE: named roles with explicit graduation criteria, reducing the legibility gap on both sides.
• Loss leader (economic): high-value low-commitment entry that establishes presence before asking for investment. EXECUTE: a single rewarding two-hour task newcomers can complete and feel, before any recurring ask. Invariant check: guild progression transforms a volunteer's status over time; loss leader preserves low commitment only at entry — no conflict, they operate on different phases. Again: nothing from "nonprofit management."

When to Use / Not Use

Use when: the problem has multiple parallel concerns; standard approaches feel exhausted or constraining; you sense the problem wants a different kind of solution; you have operational fluency across unrelated domains; you're willing to follow weird-looking lines.

Don't use when: the problem is well-served by domain-standard solutions; stakes require proven approaches; the user wants conventional advice; single constraint with an obvious operation.

Relationship to the Semantic Walk

Flight-lines is the exploitation mode: you can already name the constraints, you need operations that fit them. The semantic walk is the exploration mode: you can't yet see what you need, the position itself has to be reached.

They interlock at one specific seam. When step 3's query stalls — you've stripped a constraint to domain-free language and nothing resonant comes back from any family — that's the trigger to invoke a semantic walk to the position from which candidate operations become visible. Conversely, a walk's arrival artifact can be an operation card: the thing that becomes obvious at the end of a walk is often a specific capacity, and writing it up as a card hands it back to the composer. Same genealogy, declared interface.

Key Takeaway

Operations exist beneath domain-strata as deterritorialized capacities. When problems resist stratified solutions, follow lines of flight by composing operations on structural fit, not semantic coherence. Certify every operation with a card; use the card as a typechecker; sample distant domain families deliberately rather than reaching for a stock repertoire. Maintain parallel lines, intensify some and drop others, revise as execution produces new structure. Trust what produces concrete outputs. Domain boundaries are real but not fundamental — compose boldly, revise constantly.