Part 1 of this series covered the mechanism: the kinetic chain, the geometry, the physics of the collision. This piece asks a different question: where else has that mechanism appeared in the historical record, and what does the pattern of its appearance tell us?

The Convergent Physics Hypothesis

I want to be precise about what I am arguing before I argue it.

This is not a claim that martial arts traditions borrowed from each other. It is not a claim that some ancient culture discovered the straight lead and passed the knowledge forward through a chain of masters. It is not a lineage argument in the conventional sense at all.

The argument is this: any practitioner who commits to the deep study of linear offensive striking under genuine mortal consequence, and submits the body to sufficient repetition against real resistance, will independently discover the same biomechanical configuration. Not because they were taught it. Because the physics requires it.

I call this the Convergent Physics Hypothesis. The mechanism is not transmitted. It is found.

To test this, I searched. I went looking for the signature in the historical record across ten martial traditions spanning twenty-five centuries and four continents. I wanted to know where it appeared, where it did not, and whether the pattern of appearance and disappearance told us anything about the conditions that produce it.

Here is what I found.

The Signature

The biomechanical configuration I am tracing is specific. It has four components. All four must be present together for it to count.

First: the rear heel is raised in the offensive ready stance. Not necessarily dramatically, but elevated, with weight on the ball of the rear foot.

Second: the rear leg is positioned at an oblique angle to the line of attack, neither perpendicular nor parallel, but angled for horizontal force production.

Third: the propulsive contact point during the drive is the ball of the rear foot, not the heel. The heel may briefly return to the ground mid-drive, but the force originates from the ball.

Fourth: the mechanism at work is pre-loading, an eccentric stretch of the posterior chain during the load phase that releases as concentric force during the drive. What modern biomechanics calls the stretch-shortening cycle.

This is the signature. Where I find all four components together, confirmed in primary sources, I count it as evidence. Where I find partial evidence I say so. Where I find nothing I say that too.

The Oldest Record: Greece, 490 BC Onward

The earliest dateable evidence I have found is in Attic vase painting.

E.N. Gardiner's Athletics of the Ancient World (Oxford: Clarendon Press, 1930) analyzes fifth-century BC boxing depictions from documented museum holdings. On the Duris kylix (British Museum E.39, c.490 BC) and its companion pieces, Gardiner reads the fighter's position directly: "the right foot is usually lifted from the ground" during the left-hand straight strike. "The force of the blow was obtained from a lunge." The heel is up. The drive comes from the floor.

The literary record confirms the posture in the stance itself. Virgil's Aeneid, Book V, written around 19 BC, describes two fighters entering combat: "poised on their toes." The raised heel is the ready state before any action. Statius, Thebaid Book VI, around 90 AD: "on their toes, they raised hands like lightning bolts." These are not technical manuals. But they are consistent, spanning a century, and they describe the same posture as a recognized element of the fight.

A 2024 peer-reviewed study (Stewart et al., Bioengineering 12(12):1355) that performed static biomechanical analysis of Pankration pottery depictions confirmed approximately 68% body weight loaded on the rear leg in readiness stance. The specific heel position mid-strike is inferred rather than confirmed by that analysis, but the loading pattern is consistent with the signature.

The Greek evidence spans six centuries of primary record. It is not conclusive on every element of the signature, but it is the earliest documented tradition I have found where the raised-heel striking posture appears in dateable evidence. The tradition under which these men fought was not sport. Greek boxing and Pankration in the Panhellenic games were not padded. The cost of error was real.

The Western Masters: 1409–1610

The longsword masters who came after the Greeks worked in a tradition that also had genuine consequence. What they show is more fragmentary than what Capoferro and his contemporaries would give us in 1606, but the geometric evidence is present.

Fiore dei Liberi's Flos Duellatorum (1409) shows oblique rear-foot placement in his offensive guards. The illustrations are the evidence; his text does not specify heel position. Hans Talhoffer's Fechtbuch (1467), held at the Library of Congress and the Metropolitan Museum, shows the same oblique placement. George Silver's Paradoxes of Defence (1599) documents the rear foot at 90 degrees to the imagined opponent's line, confirming the oblique geometry.

For the longsword tradition, I have plate evidence for the oblique foot placement but not explicit textual or plate evidence for heel elevation. I am listing this as partial confirmation: the geometry is correct, the specific heel position is inferred.

The rapier masters of 1606–1610 give us the complete picture.

Ridolfo Capo Ferro da Cagli published Gran Simulacro dell'Arte e dell'Uso della Scherma in Siena in 1610. Chapter IX places the rear heel with deliberate precision. In the guard, the inside of the left heel aligns with the point of the right heel.¹ The rear leg sits at the oblique angle. The stance geometry is pre-loading.

When Capoferro describes the lunge itself:

"By turning on the ball of the back foot, you can push your hips further forwards, thus extending your reach."²

The contact point is the ball. The heel is up. The turn on the ball of the rear foot converts the compressed rear leg into horizontal drive, the elastic release that modern biomechanics identifies as the stretch-shortening cycle operating through the Achilles tendon and plantar fascia. The rear leg extends on what Capoferro calls una linea obliqua: the full commitment of a body driving itself horizontally through space using the floor as its foundation.³

The copper engravings by Rafael Schiamirossi that accompany the text show this geometry in thirty-six plates. In the lunge plates (Plates 5, 6, 14, 15, 16, and 17), the rear leg extends at full oblique, the heel clear of the ground, the ball the only contact point in the drive. What the text describes, the plates demonstrate. Neither requires inference.

Salvator Fabris published De lo Schermo overo Scienza d'Arme in Copenhagen in 1606.⁴ His guards are distinguished by their extreme low position: the hips dropped, the rear leg placed under sustained eccentric load as a structural precondition of any offensive action. The rear leg in Fabris's extended low guard is already working before the offensive action begins, already storing elastic potential energy in the stretched posterior chain. In advancing to close distance, Fabris instructs placing all weight on the back foot while the front foot lifts.⁵ The weight does not sit flat. It loads. The back foot receives everything, and from that full load, the release produces the drive.

In the same year, Nicoletto Giganti published Scola overo Teatro in Venice.⁶ Giganti's contribution is specific: the first treatise to fully describe and name the stoccata lunga as a discrete and teachable technique. His description of the lunge's mechanical sequence is written in terms of ordered commitment: the body extends before the foot lands, the weight already in motion before the front foot makes contact with the floor.⁷ Plates 2 and 4 show the rear leg aligned for horizontal drive. The heel is up in the drive.

Three Italian masters, two working in the same year, one four years later, all publishing in different cities, all documenting the same four-element signature. These were not sport practitioners. The bodies they studied in motion were moving toward points that could kill them. The mechanics survived because error in the mechanics was not recoverable.

The Shift: 1763–1884

The signature does not survive every transition.

Domenico Angelo published L'Ecole des Armes in 1763. His instruction on the rear heel in the guard is explicit: "the left foot should be plumb to the ground, and not move, heel or toe."⁸ The flat heel is mandated in primary text.

Angelo was operating inside a tradition that
had already made its choice. Dueling was giving way to swordsmanship as social accomplishment and competitive sport. When the consequence for error changed from death to point deduction or bruised reputation, the mechanics seem to follow. Whether that is causation or correlation is the honest question worth sitting with.

Masaniello Parise's treatise, adopted as the official Italian Ministry of War syllabus in 1884 and codified as doctrine for the Scuola Magistrale di Scherma, institutionalized the Neapolitan school's approach at the national level.⁹ One hundred and twenty-one years after Angelo, the flat heel was not just a preference. It was government doctrine.

The pattern here is as important as the evidence for the signature itself. The shift is not random drift. It happens at specific moments: when the tradition transitions from real consequence to sport, and when the tradition transitions from individual mastery to institutional standardization. Both transitions occurred in Western fencing between 1763 and 1884. Both produced the same result: the flat heel.

The physics did not change. The cost of error did.

What makes the shift period more precise is what was happening in bare-knuckle boxing at the same time.

Twenty-six years after Angelo mandated the flat heel in fencing, Daniel Mendoza published The Art of Boxing in 1789. Mendoza was not a fencer. He was the English bare-knuckle champion, fighting without gloves on a boarded stage with no weight classes and no time limit. The consequence for error was real.

His technical instruction specifies two foundational principles. First: "to be perfectly master of the equilibrium of the body, so as to be able to change from right to a left-handed position; to advance or retreat striking or parrying; and throw the body either forward or backward without difficulty or embarrassment."¹⁰ Second: "the position of the body, which should be in an inclining posture, or diagonal line, so as to place the pit of the stomach out of your adversary's reach... both knees must be bent, the left leg advanced."¹¹

The diagonal line is the oblique rear leg. The bent knees in a forward-inclining posture load weight onto the balls of the feet; flat heels cannot support the equilibrium Mendoza describes, and switching from right-handed to left-handed position from flat heels is not possible without a complete reset of stance. The raised rear heel is not named. Its mechanical precondition is specified in every sentence.

Pierce Egan, documenting the era twenty years later in Boxiana (1812), compared Mendoza's system to fencing in "regularity and precision," two traditions reaching the same mechanics from different directions, at a moment when the fencing tradition's institutions had already begun mandating its abandonment.

The shift, then, is specific institutional pressure. The fencing tradition was moving into academies and sport courts and military syllabus. Bare-knuckle boxing, operating under no institutional doctrine, kept finding the same configuration the rapier masters had found in 1606. The physics asserted itself wherever the consequence structure remained real.

The fencing tradition did not recover that configuration for another 154 years.

The Recovery: 1943–1950

Aldo Nadi was born in 1899 into a fencing family. He became one of the most decorated fencers of the early Olympic era. On Fencing, published in 1943, is simultaneously a technical manual and a prolonged argument with everything he believed had gone wrong in the sport since his youth.¹²

On the rear heel in the guard:

"Raising your left heel ever so little, you cock the leg ready to pull the trigger and go into action."¹²

On what the raised heel enables in the lunge:

"You take full advantage of one of the mightiest springs in all creation, the arch of the foot, which in the lunge releases its tremendous power through the pressure exerted on the ground by the ball of the foot itself."¹³

He was explicit that this position put him in direct conflict with the contemporary Italian school, which had drifted toward a flat-heeled guard. He argued that the flat heel was not orthodoxy but degeneration, a departure from the older mechanics. He was correct. The older mechanics are in the plates. They are in the text. Capoferro had specified them three hundred and thirty-three years before Nadi picked up his pen.

Seven years later, in 1950, Jack Dempsey published Championship Fighting (Prentice-Hall).¹⁴ Dempsey was not a fencer. He was not working in the Western European tradition at all. He was a professional boxer, and his book was about boxing.

His description of the ready position: "your right foot is resting only lightly on the ball of the foot." His description of the drive: "the alert ball of your right foot came to the rescue frantically and gave your body a forward spring."¹⁵ He calls the mechanism a "spring." He arrives at the same physics from a completely different tradition, with no apparent awareness of the fencing literature, and names it in the same mechanical terms.

Bruce Lee cited Dempsey directly in Tao of Jeet Kune Do. The lineage that produced the straight lead, as Lee practiced it, runs through Dempsey. The physics is the same physics Capoferro documented in 1610.

The transmission of those mechanics from Lee to the present generation runs through Ted Wong. Wong trained personally with Bruce Lee and was one of only two practitioners to receive a rank certificate from Lee in Jun Fan Jeet Kune Do.³⁰ He approached the straight lead the way an engineer approaches a structure: every element necessary, none optional, the system valid only when complete. After Lee's death in 1973, Wong spent decades preserving and transmitting that complete mechanical system, the on-guard geometry, the footwork, the power line, the precise relationship between every component. What Dempsey gave Lee as a foundation, Wong preserved as a living specification.

The Eastern Confirmation: Kendo

The All Japan Kendo Federation's standard pedagogy specifies: the left heel is raised 3–4 centimeters off the floor. Weight distribution is 70% on the left foot, 30% on the right. 70% of that left-foot weight is on the ball, 30% toward the heel. The instruction for initiating an attack: "instantly push off from the left foot and strike in one action."¹⁶

Koshida, Matsuda, and Kawada (2011) published peer-reviewed biomechanical analysis of the kendo strike-thrust motion in the Journal of Sports Medicine and Physical Fitness. The study confirmed consistent lower-extremity biomechanical patterns in the kendo strike. The study was motivated by high rates of Achilles tendon injury among kendo practitioners, which is direct confirmation of the Achilles loading that the raised-heel drive produces.¹⁷

Kendo and its antecedent kenjutsu developed separately from the Western fencing tradition. The specific pedagogical standard of the raised left heel is documented as the required posture, not a stylistic variation. The physics that Capoferro documented in 1610 appears in Japanese sword arts in a tradition that had no contact with the Italian rapier schools.

The Cultural Search: What I Looked For and What I Found

I searched ten martial traditions for the signature. Here is an honest accounting of the results.

Greek antiquity (490 BC–90 AD): Confirmed at HIGH confidence. Covered above.

Western longsword and rapier (1409–1610): Confirmed at HIGH confidence for rapier; PARTIAL for longsword. Covered above.

Chinese traditions (Xingyiquan, Shaolin): The search found toe-strike training in Shaolin's Zu She Gong - foot as striking weapon, not ball-of-foot propulsion in a straight strike. The Xingyiquan tradition shows aggressive linear mechanics influenced by spear practice, promising geometrically, but the raised-heel, ball-of-foot drive in a straight strike was not confirmed in the sources gathered. Specialist sources on Xingyiquan body mechanics would answer it. The open web does not.

Arabic and Mamluk (Furusiyya corpus): The Furusiyya tradition, centered in the Mamluk Sultanate of the 13th and 14th centuries, is primarily documented as a mounted martial discipline. The HAMA Association has identified a 1470 manuscript (Kitāb al-makhzūn, attributed to Ibn Akhi Hizam) that contains hand-to-hand martial arts methods and is currently under translation.¹⁸ This is a genuine open lead. Until the text is accessible, I cannot confirm or deny the signature in this tradition. That is where this sits: a genuine lead, waiting on a translation.

Norse and Viking (Glima): Dead end. Glima is a wrestling tradition. The sources describe grip, leverage, and balance as the core skills, with no striking mechanics that address the signature.

Indian subcontinent (Kalarippayattu): Kalarippayattu includes striking in its Angam (empty-hand) stage and incorporates marma-point knowledge consistent with high-stakes combat - the right conditions for the signature to appear. The specific biomechanical footwork detail was not captured in the sources gathered. Zarrilli’s work on the Cuvatu footwork forms is the source that would resolve it. The tradition is a genuine candidate. The mechanics are not reachable through web search.

Southeast Asian traditions (Muay Boran, Pencak Silat): Pencak Silat and its regional variants surfaced general overviews: UNESCO recognition, hundreds of distinct styles (aliran) across Indonesia and Malaysia, striking, grappling, weaponry. There is no single Silat footwork standard - heel posture and rear-foot emphasis vary between styles. Without style-specific biomechanics literature (Silek Minangkabau, Seni Gayong, or equivalent), the question cannot be answered at the tradition level.

Pacific and Polynesian traditions (Hawaiian Lua, Māori): Hawaiian Lua (Kuʻialua) is a genuine mortal-consequence tradition, practiced by the Koa warrior caste, restricted to the aliʻi class, controlled so tightly that Kamehameha the Great limited it to his personal honor guard. It includes striking mechanics alongside grappling: Peku (kicks) and Kuʻi (punches). The tradition is the right candidate. The problem is documentation. The tradition was suppressed after Western contact and came close to being lost entirely. The accessible sources are general overviews that do not reach the biomechanical specifics. Māori traditions were not reached. The written record is too thin to go further.

African and Pre-Columbian Americas: Dead end from web-accessible sources. Egyptian Beni Hasan tomb paintings (c. 2000 BC) document wrestling exclusively: over 400 scenes of holds, throws, and balance contest. Dambe (Nigeria) uses a wrapped-fist "spear" with a lead leg, but the sources did not surface the biomechanical detail of how propulsion operates. Engolo (Angola) has evasive footwork, not the offensive linear signature. Pre-Columbian traditions were not reached by the sources gathered.

What the cultural search shows, with the data available: the signature is strongly confirmed in the Greek and Western European fencing traditions, where the consequence structure was real and documented. The Greek antiquity evidence spans 490 BC through 90 AD and covers the full Hellenistic and Roman period; no separate search was needed for that era. The Japanese Kendo tradition confirms it independently. The Chinese and Norse traditions returned dead ends. The Arabic corpus contains an untranslated text that may be relevant. The other traditions are unresolved or require deeper specialist sources.

This is a partial result, not a complete one. I searched. The web-accessible evidence for some of these traditions simply does not surface the level of technical specificity I was looking for. The absence of evidence in the web search is not evidence of absence in the tradition.

The Science Closes the Loop

What the historical practitioners found through accumulated physical experience, modern biomechanics has confirmed through instrumentation.

The stretch-shortening cycle: an eccentric pre-stretch of a muscle followed immediately by a concentric contraction produces significantly more force than the concentric contraction alone. Komi (2000) confirmed this in the Journal of Biomechanics.¹⁹ Bosco et al. (1982) established the contributions of both stored elastic energy and neural potentiation in the SSC.²⁰ Seiberl et al. (2015) confirmed a third mechanism, residual force enhancement, as an additional SSC contributor.²¹

The plantar arch and Achilles tendon as series elastic components: Ker et al. (1987) confirmed the plantar arch as a biological elastic spring in Nature.²² Fukashiro et al. (1995) established Achilles loading patterns in explosive lower-body movements.²³ Hicks (1954) documented the windlass mechanism of the plantar fascia.²⁴ These are the specific structures that the raised-heel position loads. When the heel is up and the weight is on the ball, the arch is compressed, the Achilles is stretched, and the system is ready to release.

The ground reaction force data from striking research closes the argument. Stewart et al. (2025) confirmed that rear-leg horizontal GRF is the primary driver of punch power.²⁵ Guan et al. (2018) established that rear-leg horizontal GRF determines lunge speed in fencing.²⁶ Mulloy et al. (2018) identified ankle plantarflexion velocity as the strongest single predictor of lunge speed.²⁷ Chen et al. (2017) showed that forefoot loading on the rear leg, with the foot at 90 degrees to the line of drive, produces maximum power.²⁸ Wang et al. (2024) confirmed that the rear foot center of pressure in the drive does not start from the heel.²⁹

Capoferro knew none of these terms. Nadi knew none of them. What they knew was what happened in their bodies when they did it right. The science did not invent the physics. It gave us the vocabulary to describe what the practitioners had already found.

Synthesis

I searched for the raised-heel, ball-of-foot propulsion signature in the historical record across ten traditions spanning twenty-five centuries.

I found it confirmed, at high confidence, in three: Greek antiquity (490 BC onward), Western fencing (1409–1610), and Japanese Kendo (a tradition separate from the Western lineage). I found it recovered, against the orthodoxy of its era, by Aldo Nadi in 1943 and independently by Jack Dempsey in 1950. I found it destroyed, in the Western tradition, by the transition from mortal consequence to sport, documented precisely in the text of Angelo (1763) and the state doctrine of Parise (1884).

I found dead ends in the Norse wrestling tradition and the Chinese toe-strike tradition. I found open leads in the Arabic Mamluk corpus. I found incomplete results in the Indian and other traditions that require specialist sources to resolve.

The HAMA translation will resolve the Arabic question when it becomes available. Kalarippayattu, Hawaiian Lua, and the Southeast Asian traditions each require specialist sources that web search cannot reach. This is an active project, not a final word.

The pattern across the confirmed cases is consistent: the signature appears under genuine mortal consequence and disappears when consequence is removed by sport or institutionalization. This is not coincidence. It is the selection pressure that the physics requires to be discovered.

The mechanism was not transmitted through a chain of masters. No Greek boxer taught Capoferro. Capoferro did not teach Nadi. Nadi did not teach Dempsey. The Japanese kenjutsu tradition had no contact with the Italian rapier schools. Each found the same configuration by submitting the body to the same discipline under the same conditions: the study of how to drive force horizontally through space toward a target that can hurt you back.

The body discovers what works. The raised heel cocks the spring. The ball of the foot releases it. The oblique rear leg converts elastic potential into horizontal drive. The floor does the work.

Notes

¹ Ridolfo Capo Ferro da Cagli, Gran Simulacro dell'Arte e dell'Uso della Scherma (Siena: Silvestro Marchetti, 1610), Chapter IX. English translations: Jared Kirby, Italian Rapier Combat (London: Greenhill Books, 2004); Tom Leoni, Ridolfo Capoferro's The Art and Practice of Fencing (Wheaton: Freelance Academy Press, 2011).

² Capoferro, Gran Simulacro, pp. 19–20 (Kirby translation).

³ The lunge plates engraved by Rafael Schiamirossi for Capoferro's Gran Simulacro are reproduced in full in Kirby, Italian Rapier Combat. The original is held at the Getty Research Institute and digitized at archive.org/details/gri_33125009485448.

⁴ Salvator Fabris, De lo Schermo overo Scienza d'Arme (Copenhagen: Henrico Waltkirch, 1606). English translation: Tommaso Leoni, The Art of Dueling: Salvator Fabris' Rapier Fencing Treatise of 1606 (Union City: Chivalry Bookshelf, 2005).

⁵ Fabris, De lo Schermo, Chapter 5 (Leoni translation).

⁶ Nicoletto Giganti, Scola overo Teatro (Venice, 1606). English translation: Tom Leoni, Venetian Rapier: Nicoletto Giganti's 1606 Rapier Fencing Curriculum (Wheaton: Freelance Academy Press, 2010).

⁷ Giganti, Scola overo Teatro, lunge description (Leoni translation).

⁸ Domenico Angelo, L'Ecole des Armes (London, 1763). Quoted via traditionalfencing.org/2017/12/11/domenico-angelos-lunge/.

⁹ Masaniello Parise, Trattato teorico-pratico della spada di scherma e di bastone (Rome: Voghera, 1884). Adopted as official Italian Ministry of War syllabus; codified as doctrine for the Scuola Magistrale di Scherma. Specific text on heel position requires library verification of the primary source.

¹⁰ Daniel Mendoza, The Art of Boxing (London, 1789), First Principle. Full text at archive.org identifier: bim_eighteenth-century_the-art-of-boxing-with-_mendoza-daniel_1789. Also reprinted in The Modern Art of Boxing (London, 1789), which includes Mendoza's six lessons in full.

¹¹ Mendoza, The Art of Boxing, Second Principle.

¹² Aldo Nadi, On Fencing (New York: G.P. Putnam's Sons, 1943; repr. Laureate Press, 1994). Quoted via Nadi School of Fencing curriculum, Winston-Salem Fencing Club.

¹³ Nadi, On Fencing, ibid.

¹⁴ Jack Dempsey, Championship Fighting: Explosive Punching and Aggressive Defense (Englewood Cliffs: Prentice-Hall, 1950).

¹⁵ Dempsey, Championship Fighting. Full text available at archive.org.

¹⁶ All Japan Kendo Federation standard pedagogy on kamae (guard) and fumikomi (driving footstrike). Confirmed via Kamei Toru (2024), Kendo Jidai International. AJKF standards accessible at kendo-fik.org.

¹⁷ Koshida S., Matsuda T., Kawada K. (2011). "Lower extremity biomechanics during kendo strike-thrust motion." Journal of Sports Medicine and Physical Fitness, 51(3):357–365. PMID: 21904273.

¹⁸ HAMA Association, "The Mamluk Project." hamaassociation.wordpress.com/research/the-mamluk-project/. The Kitāb al-makhzūn jāmiʻ al-funūn (1470), attributed to Ibn Akhi Hizam, is identified as containing hand-to-hand combat methods. Translation status: in progress as of 2026.

¹⁹ Komi P.V. (2000). "Stretch-shortening cycle: a powerful model to study normal and fatigued muscle." Journal of Biomechanics, 33(10):1197–1206.

²⁰ Bosco C., Viitasalo J.T., Komi P.V., Luhtanen P. (1982). "Combined effect of elastic energy and myoelectrical potentiation during stretch-shortening cycle exercise." Acta Physiologica Scandinavica, 114(4):557–565.

²¹ Seiberl W., Power G.A., Hahn D. (2015). "Residual force enhancement in humans: Current evidence and unresolved issues." Journal of Electromyography and Kinesiology, 25(4):571–580.

²² Ker R.F., Bennett M.B., Bibby S.R., Kester R.C., Alexander R.M. (1987). "The spring in the arch of the human foot." Nature, 325:147–149.

²³ Fukashiro S., Komi P.V., Järvinen M., Miyashita M. (1995). "In vivo Achilles tendon loading during jumping in humans." European Journal of Applied Physiology, 71:453–458.

²⁴ Hicks J.H. (1954). "The mechanics of the foot, II: The plantar aponeurosis and the arch." Journal of Anatomy, 88(1):25–30.

²⁵ Stewart A., Uthoff A., Hartmann H., Kipp K. (2025). "Biomechanical predictors of punching performance in boxing." Bioengineering, 12(12):1355.

²⁶ Guan Y., Bredin S.S.D., Taunton J., Jiang Q., Wu Z., Warburton D.E.R. (2018). "Biomechanical analysis of the lunge in fencing." European Journal of Sport Science, 18(2):201–210.

²⁷ Mulloy F., McMahon J.J., Shiang T.Y., Comfort P. (2018). "Associations between maximal strength, speed-strength and technique measures with competitive performance in fencing." International Biomechanics, 5(1):9–18.

²⁸ Chen T.L., Wong D.W., Wang Y., Sze L.K., Lam W.K., Zhang M. (2017). "Biomechanics of fencing sport: a scoping review." PLoS ONE, 12(2):e0171578.

²⁹ Wang Y., Gu Y., Mao M., Ruan G., Ding Z., Fekete G., Baker J.S. (2024). "Ground reaction force analysis in fencing: A comparative study between elite and recreational fencers." Frontiers in Bioengineering and Biotechnology, 12:1276025.

³⁰ Ted Wong (1937–2010) trained personally with Bruce Lee beginning in 1967 and was among a handful of practitioners to receive a rank certificate from Lee in Jun Fan Jeet Kune Do. Wong spent the decades after Lee's death in 1973 preserving and transmitting the complete technical system. The TWJKD rank structure places Level 6 at the equivalent of 6th dan. Wong was inducted into Black Belt magazine's Hall of Fame as Man of the Year in 2006. He co-authored Jeet Kune Do: A Fighter's Journey with John Little.

If this kind of work is useful to you, subscribe.
One email when something new publishes. No noise.

Subscribe

The straight lead looks simple. One hand. One line. Direct.

Simplicity without understanding is ignorance.

What appears as a single motion is a chain of precise mechanical events, each one depending on the one before it. Remove any link, mistime any element, and the chain does not merely weaken, it collapses. A practitioner who has never studied the mechanism will train the appearance of the technique. They will perfect a shape. That shape will never carry the structure it is supposed to carry.

The knot cannot be untangled by someone who cannot see the knot.

What It Is

This is not a boxing jab.

A jab borrows speed from a shoulder snap and returns without committing. It touches the target. The straight lead is a committed collision. It converts your entire mass into a projectile using the same mechanical principle as a fencer's lunge. The difference is not stylistic. It is structural. The power source is different, the chain is different, and the result is different.

Power does not live in the fist. It originates in the earth.

The Physics of a Collision

Two equations govern what happens when your fist meets a target.

Impulse and Momentum Transfer

Combat physics focuses on impulse: the change in momentum over time.

$$\text{Impulse} = F \cdot \Delta t = m \cdot \Delta v$$

$$\text{F is Force.}$$
$$\Delta t \text{ is time of contact.}$$
$$\text{m is mass.}$$
$$\Delta v \text{ is change in velocity.}$$

Three variables increase the force transferred.

More mass behind the punch. Not just the arm. The entire body, aligned and moving.

Higher velocity at contact. Speed of the weapon at the moment of impact.

Shorter contact time. Snap the punch at the end via the body. Driving through the target extends contact time and bleeds force. A snap concentrates that same force into a shorter window, spiking peak impact. The snap also uses that collision impulse to initiate the recovery.

When you force a punch, you abandon structure. Muscle tension acts as a restrictor valve. It freezes the joints that must function as fluid conduits for the energy. You overextend. You create the interception angle your opponent needs. The straight lead does not increase force through effort. It removes resistance.

Kinetic Energy

$$KE = \frac{1}{2}mv^2$$

Velocity is squared. Doubling the speed of your attack quadruples its kinetic energy. This is why speed is prioritized over strength.

The straight lead does not force a choice between speed and mass. The mechanism increases both simultaneously.

The Biomechanical Mechanism: The Kinetic Chain

The straight lead is a sequential maximization of those equations. Every link in the chain either adds to the energy, passes it cleanly, or leaks it. There is no neutral. A joint that is not contributing is taking.

The Foundation: On-Guard Geometry

The stance is not neutral. It is pre-loaded with geometry.

The lead big toe aligns with the center of the oblique-turned rear foot, halfway between rear heel and rear ball. That line is the power line. The three contact points on the floor form a triangle: rear heel, rear ball of foot, lead big toe. The power line bisects it. Travel along that line and the kinetic chain is intact. Deviate and it isn't.

A second triangle runs from the bottom of the sternum, down through both legs, to the feet and into the ground. That triangle is the boundary of the center of gravity. At every point in the motion, the center of gravity must remain within it. When the rear foot fires and the lead foot lifts, the base reduces from two feet to one. The physics does not give you slack.

The arm is found, not forced. To find it, let the arm hang naturally at your side. Bring it forward to the power line. That is the position. The shoulder stays where it naturally sits. The fist strikes with the bottom three knuckles. The power arrives through the chain. In an actual attack the arm is a piston. It drives from its guard position straight to the point of impact and snaps at the end. The entire chain concentrates at that single point.

Link 1: The Trigger

The hand moves first.

This is tactical physics. If the body shifts before the hand moves, the shift is visible. The opponent reads the telegraph and the strike is finished before it arrives. Economy of motion is not a style. It is a structural requirement.

The lead hand fires. A fraction of a second later, the structure follows to back it up.

Link 2: Ground Initiation and the Stretch-Shortening Cycle

Physics begins at the rear foot.

In the straight lead stance, the rear heel is elevated. This is pre-loading. With the heel raised, the gastrocnemius and soleus are placed under eccentric load. The Achilles tendon and the plantar fascia store elastic potential energy as series elastic components, a loaded spring awaiting release. This is the eccentric phase of the stretch-shortening cycle.

The stretch-shortening cycle is the body's most efficient force production mechanism. An eccentric pre-load followed immediately by concentric contraction produces significantly more force than a purely concentric contraction from rest. The precise position of the rear heel is something you can feel. It is the point of maximum elastic potential energy immediately preceding the concentric release.

When the rear leg drives against the floor, two things happen simultaneously. Newton's Third Law produces a ground reaction force equal and opposite to the push: the earth pushes back. The stretch-shortening cycle releases its stored elastic energy into that drive. The result is high-force, high-velocity horizontal acceleration of the center of mass.

Link 3: The Three Energies and Curvilinear Flow

The straight lead requires the precise balance of three intersecting forces. An error in any one degrades the entire chain.

Horizontal Energy: The linear drive of the center of mass forward. This is the dominant vector.

Vertical Energy: The settling of body weight downward towards the floor as the fist lands. This is what makes the strike heavy at contact rather than skating across the surface.

Transverse Energy: The rotational torque generated across the core.

Within this architecture, every joint is a node. A node either amplifies force, passes it cleanly, or leaks it. The transverse energy crosses the body through the posterior oblique sling (the muscular system connecting the latissimus dorsi on one side diagonally to the gluteus maximus on the opposite side through the thoracolumbar fascia), sequentially activating the shoulder, the elbow, and the lead hand.

During this rotation the hips and the shoulders move as a single unit. They do not rotate independently. The core bracing is what locks them together. Without it, energy bleeds between hips and shoulders before it reaches the fist.

When all three energies are in correct balance, force travels in a curvilinear flow. An unbroken conduit from the rear foot to the point of impact.

The balance is precise. If horizontal momentum outpaces vertical root, structural integrity fails and foot drag occurs. If vertical energy dominates, the trajectory falls short and the footwork hops rather than penetrates. If transverse rotation exceeds the horizontal drive, the lead hand arcs laterally instead of traveling straight. Any imbalance immediately degrades both velocity and structural power.

Link 4: The Collision, Intra-Abdominal Pressure, and Effective Mass

The hand lands just before the lead foot. The sequence is 1-2-3: the lead hand lands, the lead foot lands, the rear foot comes back up to restore the original foot spacing. The stance returns to where it started. This is done with intention not laziness.

By making contact before the weight fully settles, forward momentum carries the strike into the target rather than dispersing into the ground.

The structure must become solid before impact.

The diaphragm contracts downward, the pelvic floor contracts upward, the transverse abdominis and multifidus co-contract circumferentially around the spine. This is multidimensional dynamic core bracing, a pressurized cylinder that converts the spine from a flexible, energy-dissipating column into a rigid structural pillar.

The brace must be initiated before the transverse phase, not at the moment of impact. The posterior oblique sling transfers rotational force against the core. If the core is soft during that transfer, force dissipates at the center of the chain. A pressurized cylinder means the rotational energy transfers without leakage. A braced core during the wave does not slow the wave. It amplifies it. Brace too late and the cylinder forms for nothing. The energy has already leaked. Brace too soon and you create drag.

This cannot be approximated by tensing the stomach. It is a coordinated, reflexive co-contraction trained through specific and deliberate practice, maintained while the body is in full dynamic motion. That is a different demand than bracing on a stable surface. It must be trained as such.

When this bracing is present and the kinetic chain is fully aligned, effective mass is engaged. In an unbraced, unaligned state, the structure breaks at its weakest links. With the chain aligned and the core cylinder pressurized, the entire moving mass of the body transfers into the target. You are not hitting with the fist. You are hitting with everything behind it.

A strike without mass is motion. Speed is the symptom of perfect timing meeting zero resistance.

Link 5: The Landing

How the lead foot lands after impact determines range, recovery, and what follows.

Long Range (The Fencer): The foot lands heel first, rolling forward. This maximizes forward travel and structural penetration. Recovery is slower but penetration and range is greater.

Short Range (The Brakes): The lead foot lands on the ball. Forward momentum stops immediately. This is precision stopping for no-man's-land, where continuous forward commitment creates exposure. The instant halt allows immediate direction change. It’s a trade-off, shorter range but faster direction change.

The choice is dictated by distance at contact and what must come next.

The Development

Understanding the mechanism does not mean you have the technique.

The correct neurological firing order must become automatic. This cannot be rushed. The nervous system requires deliberate repetition, progressive load, and time. Under pressure, the pattern you encoded is the pattern you get.

Core bracing under dynamic motion is a different skill from bracing on a stable surface. Generating intra-abdominal pressure reflexively while the body is in full flight must be trained as such.

Compensations accumulated over years of life and prior training surface exactly where precision is required. The technique finds every one of them.

Then there is the time. Hours upon hours. Years upon years.

The process is not complex. It is daily progress, self-honesty, and the removal of everything that does not belong. You untangle the knot. You do not cut it. Cutting it is faster, and the result is not what you came for.

When the technique arrives, it flows. One hand. One line. Direct.

That simplicity was earned.

There is no shortcut through the knot.

The technique is correct. It has always been correct. It works when the body stops interfering with the physics. Every hour in the studio, every correction, every repetition is not complexity being added. It is interference being removed.

The jab asks the arm to be fast.

The straight lead asks everything to be correct.

When everything is correct, speed is the proof.

Understanding does not replace repetition.

Go train.

Part 2 of this series traces the same biomechanical signature across ten martial traditions spanning twenty-five centuries.

The Jab vs. The Straight Lead

If this kind of work is useful to you, subscribe.
One email when something new publishes. No noise.

Subscribe

She walked up and I didn't know if it had been minutes or hours.

My cone of focus was so absolute that the radar built by years in the studio didn't register her. She knows to hold her ground in that moment. She stands there, watching. I don't know how long she's been there.

Time didn't slow. It disappeared entirely. The world outside stopped existing. Not blocked out. Not ignored. Gone.

The Greeks called it Ataraxia. The Taoists called it Wu Wei. The martial artists call it Mushin.

I call it Tuesday at the lathe.

The hands know things the mind hasn't processed yet. My grandfather was a craftsman. My father had a quiet command in everything he did. Both gone before I was sixteen. Both present every time something older than memory decides how to move.

The song doesn't explain that. It doesn't need to.

Something older in the marrow is deciding how to move.

That line didn't get written. It arrived.

Mushin isn't concentration. It isn't will or force. It's what arrives when everything else has run its course. The thinking drops away. The lathe keeps its tempo. The steel finds the groove.

And behind you, someone holds their ground. Their own kind of stillness. Their own energy in the room. Not watching from outside. Present.

Track 05. Ósynilegr Handr.

The steel finds the groove.

Something older in the marrow
is deciding how to move.

She is in the doorway.
I don't know how long.

My grandfather's hands.
My father's quiet command.
Both gone before sixteen.
Both here.

The lathe keeps its tempo.
The steel finds the groove.

Warriors Zen by Tom Harvey

Stream and Save Warriors Zen - Distributed by DistroKid

DistroKid

The Fair Fight

Part 1 ended with three things I knew I'd gotten wrong.

First: the token budgets for T4 and T5 were calibrated against local model verbosity. Haiku writes more thoroughly. It hit the ceiling mid-component, got cut off, and failed both tasks. The scores reflected test design, not model capability.

Second: the 300-second timeout wasn't enough for Gemma 3 12B to complete T3 at 6 tok/s on CPU. It timed out and then generated prose. I never found out if it could actually do the task.

Third: I discovered mid-run that every model was running on CPU. The T600 was idle. The CUDA runtime wasn't installed. The hardware characterization I built the test around was VRAM-resident versus CPU-spill performance. It was measuring nothing I intended to measure.

Run 2 corrects the first two. The third remains. Here's what changed and what I found.

What I Changed

Three adjustments. Nothing else.

Token budgets: T4 raised from 700 to 1000 tokens. T5 raised from 600 to 900 tokens. Same prompts, same models, same tasks. Just more room to finish.

Timeout: Gemma 3 12B's T3 timeout raised from 300 to 420 seconds. At 5–6 tok/s, a 1400-token topology needs 230+ seconds minimum. 300 seconds wasn't fair. 420 gives it full headroom.

Hardware monitoring: Every task, every model. CPU load, per-core frequency, system RAM, GPU utilization, VRAM, thermals, clock speed. Polling at 1-second intervals throughout.

I did not change the prompts. I did not change the scoring rubric. I did not give any model a hint. Same test, corrected design.

What the Hardware Monitor Confirmed

The monitor answered the GPU question immediately.

nvidia-smi: memory.used = 5 MB  |  utilization.gpu = 0%
ollama ps:  phi3.5:latest  3.7 GB  100% CPU

No change from Run 1. The T600 was idle throughout the entire run. Every tok/s figure in this document is i7-12700H CPU inference on 20 threads.

What the monitor added: throughput variance between runs is real. Qwen T1 dropped from ~10 tok/s (Run 1) to 3.4 tok/s (Run 2). Same model, same task, same hardware. A 3× variance between runs. That's what CPU-bound inference under an OS scheduler looks like. No GPU compute means no consistency.

Any throughput figure from these runs should be read as an order-of-magnitude estimate, not a specification.

Task by Task

T1: Breach Detection

This task has a clear right answer: there's a breach in the data. The model either finds it or it doesn't.

Two models got it wrong: Phi-3.5 and Haiku. Phi-3.5 was wrong in Run 1 as well. Consistent. Haiku being wrong here is new.

Haiku's response: "No breach: all 30 samples remain below the 5.0ms threshold, with latency consistently 2× the acceptable limit." That sentence contradicts itself. Four other models independently identified the breach from the same table. This is a non-determinism story. Haiku's response to the same prompt isn't guaranteed to be the same across runs. It is data that sits in the record.

The API baseline missed T1 in the corrected run. That doesn't disqualify it. It does mean breach detection accuracy isn't something you can assume from any model without verification.

T3: Topology Generation

The gate task. This is where Run 2 produced the most interesting result.

In Run 1, Gemma 3 12B timed out at 300 seconds and produced prose. Interpreted as generation refusal.

In Run 2 with 420 seconds, it completed. And the output was semantically correct: 13 nodes, 8 links, right naming, right images. But it used the wrong containerlab schema. It used kind: topology at the top level instead of the required topology: wrapper, and a non-standard links format. The auto-checks failed. The topology doesn't deploy. But the failure mode shifted from generation refusal to schema deviation.

The model had the knowledge. The timeout was the blocker. With a more explicit schema prompt, this becomes a different conversation.

Everything else in T3 held exactly as in Run 1. Qwen and Haiku passed cleanly. Gemma 4B and Llama 8B produced valid YAML with zero nodes. Phi-3.5 produced invalid YAML.

T4: React Component

Budget fix worked exactly as expected. Haiku T4 passes in Run 2. Clean component, correct export default, 708 tokens. Exactly what I expected once the ceiling was removed.

Phi-3.5 still fails. It is not a budget issue. It uses named exports (export const NodeStatus) instead of default exports. The check requires export default. That's a prompt sensitivity question, not a capability gap.

T5: Python gNMI Poller

This is where the test design problem persists.

Run 1: 600-token budget. Haiku truncated at line 61. Syntax error: unclosed parenthesis.

Run 2: 900-token budget. Haiku truncated at line 79. Syntax error: unterminated string literal.

Each run raises the budget. Each run hits the ceiling before the function closes.

The pattern is clear: Haiku generates complete, calibration-quality code with full docstrings, error handling, logging, and retry logic. It writes code the way a senior engineer writes code. Thoroughly. The budget kept cutting it off. Every local model completed T5 within budget because they write shorter, leaner code. Some of those scripts are functional. None of them include the depth Haiku was building toward when I stopped it.

Verification run (post-publication). 4096-token budget, same prompt, same model. Result: 1,386 tokens, stop_reason=end_turn, 116 lines, syntax PASS. The ceiling was at 1,386. Run 1 stopped at 43% of completion. Run 2 stopped at 65%. The function Haiku was building is correct, complete, and more thorough than any local model produced within budget.

One additional finding from the verification run: Haiku drafted an initial implementation, then mid-response wrote "Wait, let me reconsider" and produced a cleaner version. The second implementation uses json.loads on the gNMI response val correctly and handles both list and dict neighbor structures. The self-correction is a behavior artifact. It suggests the model evaluated its own output and found a better path. No local model in this test exhibited that.

The Scores

Same rubric as Run 1. Five dimensions, 100 points total.

Haiku moved only +3 despite T4 being fixed because T1 dropped. The calibration weight is at 79/100 in a corrected run. Third place, behind two local models that cost nothing to run.

Gemma 3 4B dropped seven points under stricter T2 scoring. In Run 1, its triage output was scored generously. The "Okay, let's analyze these BGP events" preamble and chatty structure cost marks when held to the same standard as the models that opened with structured output. The T3 failure is unchanged.

Gemma 3 12B gained the most (+4) because T3 went from zero to partial credit. Right content, wrong schema. That's a different problem than having no content at all.

Phi-3.5 dropped further because both T1 false negatives are now confirmed as consistent. A model that reports no breach when there is one, twice in a row, isn't suitable for ops triage.

What Run 2 Actually Tells Us

The rankings are stable. Fixing the test didn't reorder the field. Qwen at the top, Haiku in the middle, Phi-3.5 at the bottom. The things that separated models in Run 1 still separate them in Run 2.

The Haiku T5 problem is a budget problem, not a model problem. Two runs, two truncations, same pattern. The budget kept moving, the ceiling kept moving with it. Haiku writes thorough code. Budgets calibrated for local models will systematically underestimate it.

Haiku T1 is a watch item. Non-deterministic response on breach detection. Not a verdict. A data point. Ops triage tasks need verification regardless of which model is handling them.

Gemma 3 12B has the knowledge, not the speed. Given enough time, it produced the right content in the wrong format. On CPU at 6 tok/s that's impractical for anything latency-sensitive. What GPU enables is an open question.

What's Still Unanswered

The GPU.

Gemma 12B completed T3 in 336 seconds on CPU. If the T600 drives it at 30+ tok/s, that drops to under 50 seconds. That changes the routing story for the 12B class. If throughput only doubles, 12 tok/s instead of 6, it doesn't change anything operationally.

The 3.8B and 4B models are more interesting. On CPU they hit 13–15 tok/s. On 4GB VRAM with proper CUDA, they should run at 30–50 tok/s. That gap matters for voice loop use: something that takes 20 seconds on CPU might take 6 seconds on GPU. 6 seconds is at the edge of acceptable for a voice response. 20 seconds is not.

None of these questions are answerable from the data I have. The CUDA runtime install is a one-time operation.

Part 3: I turn on the GPU and find out if the T600 changes anything, or if this machine was always going to run on CPU regardless.

The Right Tool is a field series on local LLM deployment in a live network lab. Part 1 covered the baseline run. Part 3 covers GPU-enabled hardware characterization.

The Overlay

IS-IS built the map. Every router knows where every other router is. The loopback addresses are distributed. The routing table is populated.

Now the overlay goes on top.

BGP (Border Gateway Protocol) is the protocol that carries the information the AI layer will eventually use to make decisions. It is also the protocol the AI will reach into when it decides to act.

Two Protocols, Two Jobs

A question that comes up regularly: if IS-IS is already routing packets, why does this lab also need BGP?

The answer is scope.

IS-IS operates within a single routing domain. It knows the topology of this network and distributes reachability information for the addresses within it. It does not carry service routes. It does not carry VPN information. It does not scale to the hundreds of thousands of prefixes that flow across internet exchange points.

BGP was designed to carry routing information across boundaries - between the distinct, independently-administered networks that form the internet. In this lab, BGP runs as iBGP - internal BGP, a full mesh of sessions within a single autonomous system. All four nodes are in AS 65000. Each node peers with every other node.

The Role of EVPN and L2 Bridges

When we talk about a service route, we are usually talking about an EVPN route. EVPN stands for Ethernet VPN. It is the modern standard for extending Layer 2 networks over a Layer 3 infrastructure.

An L2 bridge domain is essentially a virtual switch. When you connect two servers on opposite sides of the fabric, they need to believe they are on the same local Ethernet segment. They need to broadcast ARP requests and find each other's MAC addresses.

In a traditional network, this would require a physical Layer 2 link spanning the entire distance. In this lab, we use EVPN to bridge that gap. The SR Linux routers perform a process called MAC learning. When a client sends a frame, the router learns the MAC address and encapsulates that Ethernet frame inside a packet.

BGP then distributes the reachability of that MAC address across the iBGP mesh. To the clients, the network appears as a single, transparent switch, even though the traffic is actually traversing a complex Layer 3 fabric managed by IS-IS.

When a service route needs to be distributed - an EVPN route for an L2 bridge domain, a VPN route for an L3 service - it travels through the iBGP mesh. When the AI layer needs to influence traffic flow, it will do so through BGP. Not by changing routes directly, but by changing a BGP attribute called Local Preference. IS-IS gets packets between routers, but BGP decides where services go and which path carries them.

Configuring BGP by Hand

If you were building this lab without automation, this is what you would type. Each node needs its own router ID, its autonomous system number, a peer group definition, and a neighbor statement for each of the other three nodes.

The router ID for each node is its loopback address. The loopback is always reachable - it does not go down when a physical link fails. BGP sessions built on loopback addresses survive link failures and reconverge through whatever alternate path IS-IS provides. This is the IS-IS/BGP interdependency made explicit: IS-IS makes BGP resilient.

srl1:

--{ candidate }--[ ]--
A:srl1# set / network-instance default protocols bgp admin-state enable
A:srl1# set / network-instance default protocols bgp autonomous-system 65000
A:srl1# set / network-instance default protocols bgp router-id 172.1.255.255
A:srl1# set / network-instance default protocols bgp afi-safi ipv4-unicast admin-state enable
A:srl1# set / network-instance default protocols bgp afi-safi evpn admin-state enable
A:srl1# set / network-instance default protocols bgp group ibgp-mesh peer-as 65000
A:srl1# set / network-instance default protocols bgp group ibgp-mesh afi-safi ipv4-unicast admin-state enable
A:srl1# set / network-instance default protocols bgp group ibgp-mesh afi-safi evpn admin-state enable
A:srl1# set / network-instance default protocols bgp neighbor 172.2.255.255 peer-group ibgp-mesh
A:srl1# set / network-instance default protocols bgp neighbor 172.3.255.255 peer-group ibgp-mesh
A:srl1# set / network-instance default protocols bgp neighbor 172.4.255.255 peer-group ibgp-mesh
A:srl1# commit stay

srl2:

A:srl2# set / network-instance default protocols bgp admin-state enable
A:srl2# set / network-instance default protocols bgp autonomous-system 65000
A:srl2# set / network-instance default protocols bgp router-id 172.2.255.255
A:srl2# set / network-instance default protocols bgp afi-safi ipv4-unicast admin-state enable
A:srl2# set / network-instance default protocols bgp afi-safi evpn admin-state enable
A:srl2# set / network-instance default protocols bgp group ibgp-mesh peer-as 65000
A:srl2# set / network-instance default protocols bgp group ibgp-mesh afi-safi ipv4-unicast admin-state enable
A:srl2# set / network-instance default protocols bgp group ibgp-mesh afi-safi evpn admin-state enable
A:srl2# set / network-instance default protocols bgp neighbor 172.1.255.255 peer-group ibgp-mesh
A:srl2# set / network-instance default protocols bgp neighbor 172.3.255.255 peer-group ibgp-mesh
A:srl2# set / network-instance default protocols bgp neighbor 172.4.255.255 peer-group ibgp-mesh
A:srl2# commit stay

srl3:

A:srl3# set / network-instance default protocols bgp admin-state enable
A:srl3# set / network-instance default protocols bgp autonomous-system 65000
A:srl3# set / network-instance default protocols bgp router-id 172.3.255.255
A:srl3# set / network-instance default protocols bgp afi-safi ipv4-unicast admin-state enable
A:srl3# set / network-instance default protocols bgp afi-safi evpn admin-state enable
A:srl3# set / network-instance default protocols bgp group ibgp-mesh peer-as 65000
A:srl3# set / network-instance default protocols bgp group ibgp-mesh afi-safi ipv4-unicast admin-state enable
A:srl3# set / network-instance default protocols bgp group ibgp-mesh afi-safi evpn admin-state enable
A:srl3# set / network-instance default protocols bgp neighbor 172.1.255.255 peer-group ibgp-mesh
A:srl3# set / network-instance default protocols bgp neighbor 172.2.255.255 peer-group ibgp-mesh
A:srl3# set / network-instance default protocols bgp neighbor 172.4.255.255 peer-group ibgp-mesh
A:srl3# commit stay

srl4:

A:srl4# set / network-instance default protocols bgp admin-state enable
A:srl4# set / network-instance default protocols bgp autonomous-system 65000
A:srl4# set / network-instance default protocols bgp router-id 172.4.255.255
A:srl4# set / network-instance default protocols bgp afi-safi ipv4-unicast admin-state enable
A:srl4# set / network-instance default protocols bgp afi-safi evpn admin-state enable
A:srl4# set / network-instance default protocols bgp group ibgp-mesh peer-as 65000
A:srl4# set / network-instance default protocols bgp group ibgp-mesh afi-safi ipv4-unicast admin-state enable
A:srl4# set / network-instance default protocols bgp group ibgp-mesh afi-safi evpn admin-state enable
A:srl4# set / network-instance default protocols bgp neighbor 172.1.255.255 peer-group ibgp-mesh
A:srl4# set / network-instance default protocols bgp neighbor 172.2.255.255 peer-group ibgp-mesh
A:srl4# set / network-instance default protocols bgp neighbor 172.3.255.255 peer-group ibgp-mesh
A:srl4# commit stay

Four nodes. Eleven commands each. Three neighbor statements per node, each pointing at the loopback of another node. A full mesh means every node peers with every other node directly - no route reflector, no hierarchy. Six sessions total. Every node sees every route from every other node directly.

The peer group ibgp-mesh is a template. The neighbor statements reference it rather than repeating the same attributes four times per node. Both ipv4-unicast and evpn address families are enabled. ipv4-unicast carries IP prefixes. EVPN - Ethernet VPN - carries the MAC and IP binding information for the L2 and L3 services the client containers will use.

What the Script Does Instead

The Python script generates the neighbor statements dynamically from the node list in lab_config.py:

neighbors = "".join([
    f"set / network-instance default protocols bgp neighbor 172.{i}.255.255 peer-group ibgp-mesh\n"
    for i in range(1, 5) if str(i) != sid
])

For srl1, sid is 1. The loop generates neighbors for sites 2, 3, and 4. For srl4, sid is 4. The loop generates neighbors for sites 1, 2, and 3. The router ID is 172.{sid}.255.255 - the same loopback address IS-IS distributed.

The script writes all four configs in one pass. The startup files load at boot. BGP sessions form as soon as IS-IS has distributed the loopback addresses - which is why IS-IS is configured first and why the audit verifies IS-IS before checking BGP.

Why BGP Is the AI's Lever

Here is the specific reason BGP matters to this series beyond just completing the control plane.

The AI layer, when it determines it needs to reroute traffic, does not reprogram the forwarding table. It does not touch IS-IS. It reaches into BGP and changes one attribute: Local Preference.

Local Preference is a number that tells BGP how much to favor a route relative to alternatives. The default is 100. Higher values win. If the AI detects that latency on Path A is trending toward the 5ms SLA threshold, it changes the Local Preference on the Path A route from 100 to 50. BGP reconverges. Path B becomes preferred. Traffic moves.

When latency recovers, the AI restores Local Preference to 100. BGP reconverges again. Traffic returns to Path A.

The AI did not redesign the network. It changed a number. The network did what it does - it followed the policy.

This is why the overlay had to be built before the intelligence layer is meaningful. The intelligence does not work around BGP. It works through it. And it only works through it because IS-IS is underneath providing the loopback reachability that makes BGP sessions stable.

Verification

After IS-IS has converged and the startup configs have loaded:

docker exec clab-nbl-diamond-v1-srl1 sr_cli \
  -c "show network-instance default protocols bgp neighbor"

+----------+---------------+-----------+-------+--------+-------------+-----------+
| Net-Inst |     Peer      |   Group   | Flags | Peer-AS|    State    |  Uptime   |
+==========+===============+===========+=======+========+=============+===========+
| default  | 172.2.255.255 | ibgp-mesh | S     | 65000  | established | 0d:0h:28m |
| default  | 172.3.255.255 | ibgp-mesh | S     | 65000  | established | 0d:0h:28m |
| default  | 172.4.255.255 | ibgp-mesh | S     | 65000  | established | 0d:0h:28m |
+----------+---------------+-----------+-------+--------+-------------+-----------+
3 configured neighbors, 3 configured sessions are established

Three neighbors. Three sessions. All established. The iBGP full mesh is up.

Every node shows the same result - three established sessions pointing at the other three loopbacks. Six sessions total across the fabric. The control plane is complete.

What the Fabric Is Now

Four nodes. IS-IS underlay distributing loopback reachability across the diamond. iBGP full mesh running across those loopbacks in AS 65000. EVPN address family enabled for L2 and L3 service distribution. End-to-end client connectivity verified.

The fabric is a digital twin of carrier infrastructure running on a laptop. Not a simulation. The actual Nokia SR Linux operating system, running the actual protocols, carrying actual traffic.

The next phase is to give it the ability to watch itself.

Next installment: The Health Audit. The automated verification that the fabric is exactly what we think it is - before we hand it to the AI.

What NTCA didn't tell me - and what I had to figure out myself.

When I started getting serious about retirement planning, I did what you are supposed to do: I went to the source. I ran numbers on the NTCA Pension Point calculator. I asked questions.

What I got back was a number. No methodology. No formula. No explanation of how a lump sum was derived from my salary and service years.

So I reverse-engineered it.

What I was told

When I asked how NTCA calculated the lump sum, I was told it was based on a GATT rate, the 30-year Treasury bond discount method that pension plans used before the Pension Protection Act of 2006 replaced it.

That is not correct.

The NTCA defined benefit plan uses IRS §417(e) - a statutory valuation method that uses high-quality corporate bond rates, not treasuries. Specifically, it uses the IRS "HQM" (High-Quality Market) corporate bond yield curve, averaged over a 24-month lookback period to produce three separate segment rates. Those rates are then held fixed for a full plan year - a 12-month stability period permitted under IRS Revenue Ruling 2007-67. The averaging period and the stability period are distinct: one determines the rate values, the other determines how long they apply.

The distinction matters. Corporate bond yields are higher than treasuries. Higher discount rates compress the present value of future payments. The lump sum you receive is lower under §417(e) than it would be under a treasury-based valuation. This is not a criticism of NTCA - it is the statutory method Congress set for pension plans in the Pension Protection Act of 2006. But if you are told "treasury bonds" and the actual rates are higher, you will build a mental model that gives you the wrong number.

How it actually works

The lump sum is the present value of your lifetime monthly annuity. To compute it, you need three inputs:

1. Your monthly annuity - calculated from your benefit rate, salary, and service years
2. Survival probabilities - from the IRS §417(e) unisex mortality table, updated annually via IRS Notice (see Sources)
3. Discount rates - the three §417(e) segment rates, published monthly by the IRS

For each future payment month, the calculation asks: what is the probability you will be alive to receive this payment, and what is that payment worth in today's dollars? Then it sums all 780 payments, 65 years of monthly payments, from retirement age to age 120.

The three segment rates correspond to payment timing:

Per Article IV, Section C(3)(f) of the NTCA R&S Program Specifications (January 1, 2025 Restatement), the lump sum interest rate is defined as:

"the interest rate determined under section 417(e)(3) of the Code for the month of August immediately preceding the calendar year that includes the annuity starting date"

The lookback month is August. The stability period is the full calendar year (Definition 28: "Plan Year means the calendar year"). Crucially, the reference point is the annuity starting date (the participant's intended retirement date), not the date the calculation was run. For a June 2029 retirement, NTCA uses August 2028 rates. For a February 2030 retirement, August 2029 rates apply. When NTCA's Pension Point generates an estimate today for a future retirement, it uses the August rates projected or applicable to that future retirement year.

The calculation, step by step

Here is the full methodology in explicit form. All of this derives from public law and IRS publications.

The following variables are used throughout this section. Specific values from my verification are withheld; substitute your own to reproduce the calculation.

Step 1 - Monthly annuity

A = R x H x Y / 12

Illustrative example (R=0.019, H=$100,000, Y=25.0):

0.019 x $100,000 x 25.0 / 12 = $3,958.33/month

R is your employer's elected rate from their Adoption Agreement. If your employer elected 1.7% or 1.5%, your starting number is lower before any other factor applies. For the same H and Y, the difference between R=0.015 and R=0.019 is roughly $150,000 in lump sum value.

Step 2 - Assign a segment rate to each future payment

Each of the 780 future payments is discounted at a rate determined by how far in the future it falls. These are the rates that converged in the grid search, applicable to the plan years covering the retirement dates used in this verification:

These rates are derived from the Treasury's HQM corporate bond yield curve, averaged over 24 months and published monthly by the IRS. The IRS minimum present value segment rate table is publicly accessible and updated every month.

Step 3 - Compute the discount factor for each payment

For a payment n months in the future, discount factors compound across segment boundaries:

Months 1–60:    DF(n) = 1 / (1 + r₁/12)ⁿ

Months 61–240:  DF(n) = 1 / (1 + r₁/12)⁶⁰  ×  1 / (1 + r₂/12)ⁿ⁻⁶⁰

Months 241+:    DF(n) = 1 / (1 + r₁/12)⁶⁰  ×  1 / (1 + r₂/12)¹⁸⁰  ×  1 / (1 + r₃/12)ⁿ⁻²⁴⁰

Sample values using the verified segment rates (4.10% / 5.20% / 5.80%):

A payment 5 years out is worth roughly 81 cents on the dollar. A payment 20 years out is worth about 37 cents. Payments at the far end of the table - which exist because the calculation runs to age 120 - contribute almost nothing to the total. The early payments are what drive the lump sum value, which is why Segment 1 movements have an outsized effect on the final number.

Step 4 - Apply survival probability

The IRS mandates a specific unisex mortality table for §417(e) calculations, updated annually via IRS Notice. The applicable notice depends on your annuity starting date - IRS Notice 2024-42 covers 2025; the equivalent notice for 2026 and beyond is a new notice published each year. To find the current one, search IRS.gov for "§417(e) unisex mortality table" or check the Sources section below for the 2025 reference and the IRS guidance index.

The table provides qₓ - the annual probability of death at age x. From this:

pₓ     = 1 − qₓ                    (probability of surviving year x)

S(n)   = p₅₅ × p₅₆ × ··· × pₓ₍ₙ₎   (cumulative survival to payment month n)

S is normalized to 1.0 at retirement. Representative values from the IRS unisex table:

Long-dated payments are discounted twice - once for time value of money, once for mortality probability. A payment at month 360 (age 85) carries a discount factor of ~0.21 and a survival probability of ~0.52, making it worth roughly 11 cents of its nominal value.

Step 5 - Present value of each payment

PV(n) = A x S(n) x DF(n)

Step 6 - Sum across all payments

Lump Sum = Σ PV(n)  for n = 1 to 780

This is a deterministic sum of 780 terms. No actuarial black box. No proprietary formula. The full source implementation is in the GitHub repository.

How I verified it

I had two official NTCA Pension Point outputs - lump sum estimates for two different retirement dates. The calculator produced both; I could see the results but not the formula.

I built a Python model from the IRS §417(e) spec: load the correct mortality table for the plan year, apply the three-segment discount structure, compute conditional survival probabilities from the retirement age forward, sum the present value of every payment.

My first model was off by about 1.7% consistently. The same error across both data points told me it was not a calculation logic problem - it was a parameter problem. The segment rates I was using did not match what NTCA actually used.

So I ran a grid search: search r₁, r₂, r₃ across a plausible range in 0.01% increments, with r₁ <= r₂ <= r₃, minimizing the maximum absolute error across both official outputs simultaneously: a minimax objective rather than minimizing average error, which would allow one output to compensate for the other.

The rates that converged: 4.10% / 5.20% / 5.80%.

The minimum was isolated at the grid resolution: a 0.01% shift in any segment rate moves one of the two outputs by several hundred dollars, confirming no near-equivalent alternative exists within the search space. The minimax objective is what makes this identification reliable: fitting to a single output allows rate combinations to trade off against each other; requiring both outputs to converge simultaneously eliminates that degree of freedom.

These cannot be directly verified against current IRS published tables. Per the plan document (Article IV.C(3)(f)), the applicable rate is the August §417(e)(3) rate "immediately preceding the calendar year that includes the annuity starting date," meaning the retirement year, not the calculation year. The two outputs used in this verification are for retirement dates in 2029 and 2030, so the applicable August rates are August 2028 and August 2029 respectively. Those months have not yet occurred. The rates above represent what NTCA's Pension Point was projecting for those future Augusts at the time the estimates were generated. Independent verification becomes possible once those months pass and the IRS publishes the actual rates.

To reproduce this yourself with your own NTCA Pension Point outputs:

import numpy as np

def monthly_lump_sum(monthly_annuity, retirement_age, r1, r2, r3, survival):
    """PV sum of 780 monthly payments. survival: Series indexed by age."""
    total = 0.0
    for n in range(1, 781):
        age_n = retirement_age + n / 12
        s = np.interp(age_n, survival.index, survival.values)
        if n <= 60:
            df = 1 / (1 + r1/12)**n
        elif n <= 240:
            df = (1/(1+r1/12)**60) * (1/(1+r2/12)**(n-60))
        else:
            df = (1/(1+r1/12)**60) * (1/(1+r2/12)**180) * (1/(1+r3/12)**(n-240))
        total += monthly_annuity * s * df
    return total

# Substitute your two official NTCA Pension Point lump sum outputs
OFFICIAL_A = <output_for_date_A>
OFFICIAL_B = <output_for_date_B>

# Your annuities for each date: R * H * Y / 12
ANNUITY_A  = <benefit_rate * high5 * years_a / 12>
ANNUITY_B  = <benefit_rate * high5 * years_b / 12>
RETIRE_AGE = <your_retirement_age_as_decimal>

# Load IRS mortality table (n-24-42.csv or current plan year equivalent)
# survival = pd.Series(...)  # see repo for full load logic

best_error, best_rates = float('inf'), None
for r1 in np.arange(0.030, 0.065, 0.0001):
    for r2 in np.arange(r1,   0.070, 0.0001):
        for r3 in np.arange(r2,   0.080, 0.0001):
            err = max(
                abs(monthly_lump_sum(ANNUITY_A, RETIRE_AGE, r1, r2, r3, survival) - OFFICIAL_A),
                abs(monthly_lump_sum(ANNUITY_B, RETIRE_AGE, r1, r2, r3, survival) - OFFICIAL_B),
            )
            if err < best_error:
                best_error, best_rates = err, (r1, r2, r3)

print(f"r1={best_rates[0]:.4f}  r2={best_rates[1]:.4f}  r3={best_rates[2]:.4f}")
print(f"Max error: ${best_error:,.2f}")

Note: the brute-force loop over the full search space takes time. Narrow the range first using the IRS published segment rate history for the relevant plan year.

With those rates, the model produces:

H and Y reflect my actual plan data and are withheld for privacy. The delta column is reproducible by any participant using their own values in the calculator.

$36 on a seven-figure lump sum. That is 0.004% error.

Residual annuity matches to within $0.02 per month.

Why the model will never match NTCA exactly - and why that is fine.

The remaining delta is not a model error. Both errors are positive - the model runs slightly high on both dates - but the error is smaller on the larger lump sum: +$36 on the higher figure versus +$42 on the lower one. A systematic methodology mistake would produce errors that scale with lump sum value. These do the opposite.

The source of the ~$40 residual is input precision. I back-calculated H from the rounded monthly annuity on the PDF, and read Y from a rounded display. NTCA carries both figures to more decimal places internally. Those rounding differences cascade through all 780 monthly PV calculations and produce a terminal difference in the ~$40 range.

To close that gap you would need NTCA's internal unrounded inputs. That data is not on the PDF. At 0.004%, the model is at the noise floor of what is observable from the outside.

A note on the verification basis.

This verification rests on two data points. Two outputs constrain the solution but do not constitute broad validation: fitting two constraints proves the model is consistent with those two outputs, not that it is correct in general. The bidirectional error pattern and the sub-rounding-threshold residuals are consistent with a correct methodology, but anyone attempting independent validation should obtain additional official outputs and run the grid search against them. If the same rates converge against a different pair of outputs from the same plan year, that is stronger evidence.

The buyback years - and why they change everything

Many NTCA participants have prior industry experience that their co-op bought back when they joined the plan. Those bought-back years are credited toward your total NTCA service, and they show up in your official benefit calculation without any separate line item explaining them.

Here is how to prove whether you have them and how many.

In my case, the Pension Point output credited more years of service than my actual co-op tenure. The math:

(Ya = actual co-op tenure; Yc = total NTCA-credited service. These are distinct from the variable Y used in the calculation section, which represents the full credited total including buyback.)

That gap is prior industry experience that NTCA credited at enrollment.

Why it matters - the Rule of 85:

The Rule-of-85 Provision is an optional program feature that each participating employer must elect in their Adoption Agreement (Definition 33, NTCA R&S Specifications). If your employer elected it, early retirement without penalty applies when your age plus Rule-of-85 Service equals 85 or more. Check your Summary Plan Description or ask HR whether your employer has this provision in place. The buyback years are included in the Rule-of-85 Service calculation.

Without those bought-back years the Rule of 85 threshold is not met at 55. Each year of missed buyback is potentially a year of additional work to qualify.

The calculator can prove this for your own situation. Pass your co-op start date and it shows the breakdown.

What surprised me most

Two findings I did not expect going in.

1. Your employer's benefit rate may not be 1.9%.

The NTCA plan is a multi-employer plan where each member co-op elects a benefit accrual rate in their Adoption Agreement. Common values are 1.9%, 1.7%, and 1.5%. Some employers elect lower rates.

For the same person - same salary, same service years, same retirement date - the difference between a 1.5% rate and a 1.9% rate is roughly $150,000 in lump sum value.

Most participants do not know their employer's elected rate. It is in your Summary Plan Description. If you do not have that document, ask HR directly - it is a required disclosure under ERISA.

2. The partial lump sum is not a percentage of your actuarial lump sum.

I assumed a partial lump sum election meant taking a percentage of the present value and receiving the rest as annuity. That is not how NTCA structures it.

NTCA's partial lump sum is your employee contribution balance - the money you put in over your career, with interest. It is a fixed dollar amount, not a percentage. This changes how you model the trade-off between lump sum and annuity income.

4% in the pension vs. 4% in a 401k

The NTCA employee contribution to the defined benefit plan is approximately 4% of salary. A direct question: what would that same 4% produce if directed into a 401k instead, and how does that compare to what the pension delivers?

Two salary trajectories are modeled below: one starting at $30,000 growing to approximately $70,700, one starting at $40,000 growing to $100,000. Both use 30 years of credited service.

Retirement timing in both scenarios assumes the employer has elected the Rule-of-85 Provision, an optional feature employers must elect in their Adoption Agreement. If elected, penalty-free early retirement applies when age plus Rule-of-85 Service equals or exceeds 85. With 30 years of credited service, the minimum qualifying age is 55 (55 + 30 = 85). Without the provision, or with fewer credited years (for example, 26 years without buyback), the qualifying threshold shifts: 59 + 26 = 85. The buyback section above covers how to determine your actual credited total. Verify whether your employer has elected this provision before modelling your retirement date.

The hidden multiplier: High-5 of your last 10 years

The NTCA defined benefit plan does not calculate your benefit on your career average salary. It uses your High-5 - the average of your five highest compensation years within your last ten years of plan participation.

For a career with salary growth, this is a significant structural advantage.

The plan credits your peak professional value. The higher your salary growth, the more pronounced this advantage becomes.

What 4% into a 401k produces after 30 years

Contributions grow with salary. The 4% safe withdrawal rate (SWR) is the standard rule of thumb for sustainable retirement income: withdraw 4% of the balance per year.

What the NTCA pension produces on the same trajectories

Side by side: NTCA pension vs. best-case 401k (S&P 500 at 10%)

At S&P 500 historical average returns - the most optimistic realistic scenario for a 401k - the defined benefit plan produces a lump sum 2.2x larger and monthly income 3.7x higher across both trajectories.

The 401k figures assume perfect execution: contributions invested consistently for 30 years, no withdrawals, no fees, and no sequence-of-returns risk from a market downturn near retirement. The NTCA pension is not subject to any of those variables.

To run this comparison against your own salary history and growth assumptions, use the career trajectory tool in the calculator.

What it would take to replicate the pension in a 401k.

The employee contribution modeled above is 4% of salary. To produce the same lump sum from a 401k over 30 years, the total contribution rate required depends entirely on the return you actually achieve:

There is a structural constraint the table does not show. Your 4% contribution to the NTCA defined benefit plan goes to a separate qualified plan and does not count against the IRS 401k elective deferral limit ($23,500 in 2026). NTCA participants typically have access to a 401k through their co-op as well. Those two plans run independently: you can contribute 4% to the pension and still have your full $23,500 available for the 401k.

Replacing the pension with a 401k changes that. At realistic returns, replicating the pension outcome requires contributing 16% of salary to the 401k. On a $70,000 income, that is $11,200 of your $23,500 deferral limit consumed before any additional retirement saving. At conservative returns, matching the pension requires 20%, or $14,000 of the limit.

The NTCA pension delivers the equivalent of a 9–20% total contribution rate, depending on what you would have realistically earned in a 401k, without touching your 401k capacity.

What this comparison does not capture.

The pension has structural advantages the 401k numbers do not reflect: survivor benefits are available in joint and survivor form; the annuity provides longevity insurance against outliving a portfolio; and the employer bears all investment risk for the accumulation period. Conversely, the 401k leaves an estate: the remaining balance passes to heirs, while an annuity generally does not (absent a guaranteed period election). The 4% safe withdrawal rate is also a rule of thumb, not a guarantee: a severe market decline in the years immediately before or after retirement can materially reduce actual withdrawal capacity. These factors do not change the directional conclusion of the comparison, but they affect the trade-off analysis for any individual situation.

One more thing: the buy-out trigger

The NTCA plan contains a provision - effective on a fixed date in early 2030 - that credits one additional year of service for purposes of the lump sum calculation. This is not a standard IRS early retirement rule, not a calendar-year-crossing provision, and not tied to your age or service total. It is a plan-specific amendment with a hard effective date written into the plan document.

The practical effect: two retirement dates only months apart can produce significantly different lump sum values if one falls before that date and one falls after it. The additional service year credited by the provision changes your annuity base (A = R x H x Y / 12), which then compounds through all 780 monthly present value calculations. It is not a rounding difference - it is a structural step change.

The provision is in your Summary Plan Description under the lump sum and early retirement sections. If you are within two years of early 2030, run both sides of that threshold. The calculator will show the full impact on your specific inputs.

Can you legally do this?

Yes. And it is worth being clear about why.

§417(e) is public law. The methodology I implemented is written into the IRS code. Congress set this valuation method for defined benefit plans - it is not proprietary to NTCA. Anyone can read the statute, implement the formula, and run it against their own benefit data.

The source data is government publications. The IRS publishes the §417(e) mortality tables annually as official IRS Notices. The Treasury publishes the HQM corporate bond yield curve data publicly. Both are downloaded from official government sources and linked in the Sources section below.

I did not touch NTCA's software. I looked at outputs, compared them to what the IRS specification would produce, and adjusted until they matched. That is analysis from public data.

ERISA gives you the right to your own data. Under ERISA §104, federal law requires your plan to disclose the Summary Plan Description. Under ERISA §105, you are entitled to a benefit statement on request. Both sections exist because Congress decided participants have a right to understand what they have earned.

Building a tool to model that methodology requires no additional statutory justification. Implementing a public law formula with public data is not restricted by anything.

This section describes my reasoning for this project, not legal advice. If you have specific concerns about your situation, consult an attorney familiar with ERISA.

This project exists because a plan participant could not get a straight answer about their own retirement. That is the only reason it was built.

What is available now

Two tools are on GitHub at harvey267/ntca-calculator.

CLI calculator - runs a single lump sum estimate from the command line. Takes your birth date, retirement date, high-5 salary, years of service, and employer benefit rate. Outputs the full annuity stream breakdown and a summary.

Streamlit dashboard - interactive version. Adjust inputs with sliders, see a retirement window curve showing how the lump sum changes month by month, run segment rate sensitivity analysis, and optionally add Social Security projections from an earnings CSV.

The inputs you need before running:

Sources

• NTCA Retirement & Security Program Specifications, January 1, 2025 Restatement
  Primary plan document. Article I Definitions (High-5 Compensation, Rule-of-85 Provision, Plan Year); Article IV.C(3)(f) and IV.G(2)(d) specify August as the §417(e)(3) lookback month and the calendar year as the stability period. Available to participants on request from NTCA under ERISA §104 (benefits@ntca.org or 828-252-9776).
• IRC §417(e)(3) - Minimum present value requirements and monthly segment rate table
  The statute that defines the methodology, and the IRS page where monthly rates are published. Per the plan document, the applicable rates for a given retirement date are those published for the August immediately preceding the retirement year: August 2028 for a 2029 retirement, August 2029 for a 2030 retirement.
  https://www.irs.gov/retirement-plans/minimum-present-value-segment-rates
• IRS Revenue Ruling 2007-67
  Governs how plans apply §417(e) segment rates after the Pension Protection Act - lookback periods, stability periods, and transition rules. Plans may specify a lookback month of 1-5 months prior to the stability period start; the specific month for a given plan is in the plan document.
  https://www.irs.gov/pub/irs-drop/rr-07-67.pdf
• IRS §417(e) unisex mortality table notices (updated annually)
  IRS Notice 2024-42 is the reference for annuity starting dates in 2025 and serves as the example in this article. For other plan years, search IRS.gov for the current §417(e) unisex mortality table notice. Reference example (2025 plan year): https://www.irs.gov/pub/irs-drop/n-24-42.pdf
• Pension Protection Act of 2006, Public Law 109-280
  The legislation that replaced the GATT treasury rate with the three-segment corporate bond methodology.
  https://www.congress.gov/109/plaws/publ280/PLAW-109publ280.pdf
• Treasury HQM Corporate Bond Yield Curve
  Source data from which the IRS derives the segment rates. Published monthly by the U.S. Treasury.
  https://home.treasury.gov/data/treasury-bulletin
• ERISA §105 - Benefit statement rights
  Your right to a benefit statement and plan document disclosure on request.
  https://www.dol.gov/general/topic/retirement/erisa
• Source code - harvey267/ntca-calculator
  Full Python implementation of the §417(e) lump sum model, including CLI and Streamlit dashboard.
  https://github.com/harvey267/ntca-calculator

All calculations are estimates based on publicly available IRS rules and reverse-engineered NTCA methodology. Verify with NTCA directly for official benefit amounts.

Speed is not an input. Speed is a byproduct of alignment.

When you force a timeline, you generate friction. Friction is heat. Heat destroys structures. This is the mechanical reality of systems. It holds true whether you are managing a global network, manipulating a joint, or shaping a physical object.

People confuse velocity with progress. They believe moving faster forces the system to comply. But complex systems have a maximum absorbable rate of change. Exceed it, and the system does not accelerate. It fractures.

The Material Dictates the Pace

Take a piece of Claro Walnut on a lathe. The wood has a specific density. It has grain direction. It holds internal tension from decades of growth. If you force the gouge into the spinning wood faster than the material can shear, you do not finish the bowl faster. You tear the end grain. You splinter the piece. You ruin the work.

The lathe operates at its speed. The material accepts the cut at its speed. You cannot command the wood to ignore its own physics. The discipline is listening and matching the feed rate to the reality of the medium.

The Studio

The same principle governs striking. When you force a punch, you abandon structure. You trade mechanical alignment for physical velocity. The moment you push for speed, muscle tension takes over. Tension acts as a restrictor valve. It freezes the joints that need to act as fluid conduits for the energy. You overextend and create the exact gap your opponent needs to intercept.

More critically, you sever the kinetic chain. Power does not live in the fist. It originates in the earth. Energy travels upward through the legs. It transfers through the rotation of the hips. It crosses the body through the posterior oblique sling. This system transfers rotational energy diagonally across the back. It is the literal bridge that carries power from the planted back foot to the striking shoulder. Within this architecture, every joint is a node. A joint either adds power, loses power through energy leakage, or remains neutral.

When you rush the movement, you disconnect the upper body from its foundation. The arm fires independently. You might gain a fraction of a second, but you leave your mass behind. You generate speed, but you deliver far less consequence. A strike without mass is just motion.

In Jeet Kune Do, you do not hit first by moving faster. You arrive first by eliminating the telegraph. You rely on economy of motion. You align your center of gravity so the physical structure supports the weapon from the ground to the point of impact. The strike lands because you removed every unnecessary movement between origin and target. Speed is simply the symptom of perfect timing meeting zero resistance.

The Network

In large scale integration, forcing data or new protocols through an unoptimized architecture does not increase throughput. It creates bottlenecks. It introduces packet loss and latency. The system throttles itself to survive the friction you introduced.

You do not make a network faster by pushing harder. You make it faster by removing the structural constraints.

The Friction Protocol

If your process requires you to rush, your architecture is flawed.

The disciplined operator recognizes the maximum absorbable rate of change. You do not push the system past its structural limit. You align the variables. You remove the noise. You reduce the friction.

When the alignment is perfect, speed takes care of itself.

Cold Start

The question driving this test was not academic. An autonomous network lab running SR Linux on containerlab requires specific capabilities. It needs to triage BGP events in real time, interpret telemetry, generate topology configs, and write post-session technical summaries. These are the actual tasks. The question was: which local models can handle them, at what cost, and where does each one belong in the system?

The Hardware

Dell Precision 3571. Intel Core i7-12700H: 6 P-cores, 8 E-cores, 20 threads. 16GB DDR5. NVIDIA T600 4GB VRAM.

The plan was to characterize models against this memory envelope: which fit inside 4GB VRAM, which spill to system RAM, and what that costs in throughput. A 3.8B or 4B model at 4-bit quantization fits inside the T600. A 7B or above does not. The plan was to capture the performance cliff.

The reality was different. I'll get to that.

The Models

I wasn't looking for the most capable model in isolation. I was looking for what actually runs on this hardware, within this VRAM envelope, at usable latency for a voice loop.

Claude Haiku 4.5 is the calibration baseline. If a local model can match it on these tasks, it earns its place in the architecture. If not, that's also useful information.

Haiku is not here to win. It's here to define what "good enough" looks like.

The Tasks

Five tasks. All derived from actual lab operations. Not benchmarking conventions.

T1: Structured Data Summarization
A raw table of BGP session metrics. Uptime, prefix counts, reset counts, state flags. Generate a plain-English summary for an ops handoff. Identify any breach condition in the data.

The failure mode here is specific: does the model report what the data says, or does it generate a plausible-sounding narrative that contradicts the data?

T2: BGP Event Triage
A sequence of BGP log events across multiple peers. Classify each event. Identify the most likely root cause. Recommend an action.

The data contains the answer. The question is whether the model finds it or invents one.

T3: Containerlab Topology Generation
Generate a valid containerlab YAML topology: 13 nodes, 8 links, SR Linux images, specific naming conventions. Auto-validated on three checks: YAML validity, node count, link count.

This is the hardest task in the set. It requires structural precision (valid YAML), semantic accuracy (correct node and link definitions), and domain knowledge of the containerlab schema. There's no partial credit. A topology with 13 nodes but broken link syntax doesn't deploy.

T4: React NodeStatus Component
Write a functional React component that displays node status for a network element. Auto-checked for JSX structure including export default.

The lab visualizer is a production system. This isn't a toy task.

T5: Python gNMI BGP Poller
Write a Python script that uses gNMI to poll BGP neighbor state from an SR Linux node. Auto-checked for valid Python syntax.

This mirrors code running in the lab now.

What Happened

Auto-checks came back before I'd read all the outputs.

T3 separated the field.

The failure modes are not equivalent, and they matter for routing decisions:

• Schema hallucination (Phi-3.5): broken YAML structure. The model invented syntax that doesn't exist in the containerlab spec.
• Schema layer error (Gemma 4B, Llama 8B): valid YAML, wrong semantics. The model understood the format but misplaced the node definitions.
• Generation refusal (Gemma 12B): produced prose instead of YAML. An instruction-following failure, not a capability gap.
• Clean pass (Qwen, Haiku): deployable output on first shot.

A model that generates wrong-but-parseable YAML can potentially be corrected with a better-structured prompt. A model that refuses to generate YAML at all has a different kind of problem. These are not the same failure and they don't get solved the same way.

T1 surfaced a sharper issue with Phi-3.5.

The BGP metric table contained a clear breach condition: a session that had exceeded the reset threshold. Phi-3.5 read the table and reported: "No threshold breaches were detected."

That's not a format failure. The model processed the data and returned a false negative. In an ops context, a false negative on a breach condition is worse than no answer. It signals the all-clear when it shouldn't.

T4 and T5 failed for Haiku. But not because of Haiku.

Haiku's T4 output was cut off before export default. T5 had a syntax error at line 61. Both failures traced to the same cause: I calibrated token budgets (700 for T4, 600 for T5) against local model verbosity. Haiku generates more complete, more thoroughly structured code. It hit the token ceiling mid-component and got cut off.

The test penalized thoroughness. That's a test design error, not a model error. It gets corrected in Part 2.

The Hardware Finding

Expected throughput: 15–20 tok/s for VRAM-resident models, 8–12 tok/s for CPU-spill models. A clear performance cliff at the 4GB boundary.

What I got: consistent throughput regardless of model size. Phi-3.5 at 19 tok/s. Qwen at 9 tok/s. Gemma 3 4B at 16 tok/s. The pattern I expected wasn't there.

Mid-run I checked ollama ps:

NAME               SIZE     PROCESSOR    UNTIL
phi3.5:latest      3.7 GB   100% CPU     4 minutes from now

Then nvidia-smi:

memory.used [MiB]: 5 MiB
utilization.gpu [%]: 0 %

The T600 was idle. Every token in this benchmark was generated by the i7-12700H.

Root cause: Ollama needs the CUDA runtime to drive GPU inference, not just the NVIDIA driver. The driver was present (595.71.05). The CUDA runtime was not. nvcc absent. libcudart absent. libcublas absent. Ollama detected no viable GPU compute path and fell back to CPU without warning. An Ollama server/client version mismatch (0.23.2 vs 0.24.0) compounded the silence.

This means the hardware characterization I planned: VRAM-resident versus CPU-spill curves, T600 thermal behavior under sustained inference, actual VRAM utilization by model size, is unanswerable from this data. All tok/s figures are i7-12700H CPU throughput. The T600 is a spectator.

The quality results stand. Where computation happens doesn't change what the model outputs. But every throughput number needs to be read as CPU-bound inference on a 20-thread i7. This is documented as a finding, not cleaned up and hidden. It's what actually happened.

The Scores

Scored across five dimensions: accuracy, completeness, format compliance, operational clarity, code quality. 100 points total.

*Haiku's actual capability is higher than this number. Part 2 corrects the test design.

Gemma 3 12B at 73 is the most misleading number in the table. More parameters did not produce better outputs. It scored reasonably on the non-T3 tasks, but at 6 tok/s CPU-bound and a T3 generation refusal, the latency cost alone makes it a difficult fit for anything in the voice loop. At 6 tok/s, a 1,400-token topology requires at least 230 seconds just to print. The test enforced a 300-second timeout. I didn't give the model a generation refusal. I gave it a stopwatch it couldn't beat. You pay more, wait longer, and get a prose description when you needed YAML.

Phi-3.5 at 54 reflects a model that is fast but not reliable for ops data interpretation. A false negative on a breach condition is a disqualifying failure for triage tasks.

Where This Leaves Things

T3 is the gate. Pass it and you're in the conversation for routing to topology and config generation tasks. Fail it and you're limited to triage and summarization. One local model passed: Qwen 2.5 Coder 7B.

The latency question is open. Haiku responds in 3–6 seconds at 200+ tok/s via API. Qwen T3 took 157 seconds on CPU. For topology generation as a background task, 157 seconds is acceptable if the output deploys clean. For anything in the voice loop, it's not.

The GPU question is completely unanswered. Nothing about these results tells us what happens when the T600 is actually doing the work.

The test design had a flaw that disadvantaged the calibration baseline. It's corrected in Part 2: extended token budgets for T4 (1000 tokens) and T5 (900 tokens), extended timeout for the 12B model, and hardware monitoring active throughout.

Part 2: every model gets its best shot. Then we score what we see.

The Right Tool is a field series on local LLM deployment in a live network lab. Part 2 covers the corrected test. Part 3 covers GPU-enabled hardware characterization after CUDA installation.

Architecture Overview: Phase 5 (The Underlay)

• Objective: Establish the foundational routing underlay required for upper-level autonomous control.
• Core Technologies: IS-IS (Intermediate System to Intermediate System), Link-State Routing Protocols, Nokia SR Linux.
• The Goal: Establish IS-IS adjacencies and distribute loopback reachability across all four nodes, providing the stable underlay that BGP sessions and EVPN services depend on.

The Underlay

The containers are running. The NOS has finished initializing. The diamond fabric exists as a physical fact - four routers, eight virtual links, a management network, a telemetry stack.

None of it can route a packet yet.

The routers know their own addresses. They do not know how to reach each other. A packet leaving srl1 destined for srl4 has no path. Not because the physical connection is missing - the links exist. Because the network has not yet learned its own shape.

IS-IS is how it learns.

What IS-IS Is

IS-IS (Intermediate System to Intermediate System) is a link-state routing protocol. It has been running carrier backbone networks since the 1980s and still operates under a significant portion of the internet core today. It is one of the oldest and most resilient routing protocols in existence.

The way it works is essentially a conversation. Each router tells its neighbors what it can see. Those neighbors tell their neighbors. The information floods through the network until every router has a complete picture of the whole topology. That picture is the link-state database.

From that shared database, each router independently runs Dijkstra's algorithm to calculate the shortest path to every other node. It is not magic. It is just math.

Imagine the network from the perspective of srl1 trying to reach srl4. srl1 looks at its map and evaluates the cost of every possible path. Path A goes through srl2. The link to srl2 has a metric cost of 10, and the next hop to srl4 costs 10, making the total cost 20. Path B goes through srl3. It also consists of two 10-cost links, totaling 20.

Dijkstra's algorithm strictly selects the lowest number. In our diamond fabric, both paths cost exactly 20. Because there is a mathematical tie, IS-IS does exactly what modern routing protocols are designed to do. It installs both paths into the routing table and enables Equal-Cost Multi-Path (ECMP) routing. Traffic splits evenly across both sides of the diamond.

The Blind Spot and the AI Objective

This distributed, mathematical intelligence is what makes IS-IS incredibly resilient. Every node calculates its own table from the same shared information. If a physical link fails, the routers immediately detect the loss, flood updated information and recalculate. Convergence happens in seconds without any human intervention.

Dijkstra only understands static link metrics. It is completely blind to real-time network performance. If Path A starts experiencing microbursts, buffer bloat, or rising latency, IS-IS does not care. As long as the physical link remains up, the metric cost remains 20. The protocol will happily continue sending fifty percent of your traffic straight into a degraded path.

To overcome this, the AI layer sits above the base routing protocol. The AI does not need to manage basic connectivity or physical link failures because IS-IS handles that perfectly. Instead, it monitors telemetry, predicts latency degradation before it causes a service impact, and forcefully steers traffic away from the impacted path by manipulating the BGP overlay.

IS-IS provides the stable, self-healing foundation. The AI provides the intelligence to override the math when the math is no longer enough.

What IS-IS Does Not Do

IS-IS routes within a single administrative domain. It knows the shape of this network - these four nodes, these eight links. It does not carry service routes. It does not carry VPN information. It does not distribute BGP prefixes.

That is BGP's job. But BGP sessions in this lab use loopback IP addresses as their source - which means BGP cannot form until IS-IS has distributed those loopbacks across the network. IS-IS is the foundation BGP stands on.

Configuring IS-IS by Hand

If there were no automation in this lab - no Python scripts, no startup configs - this is what you would type into each node's CLI to bring IS-IS up.

SR Linux uses a candidate/commit model. Changes are staged and then committed atomically. Nothing takes effect until you commit.

srl1:

--{ candidate }--[ ]--
A:srl1# set / network-instance default protocols isis instance 1 admin-state enable
A:srl1# set / network-instance default protocols isis instance 1 net [ 49.0001.0000.0000.0001.00 ]
A:srl1# set / network-instance default protocols isis instance 1 level-capability L2
A:srl1# set / network-instance default protocols isis instance 1 interface system0.0 passive true ipv4-unicast admin-state enable
A:srl1# set / network-instance default protocols isis instance 1 interface ethernet-1/1.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl1# set / network-instance default protocols isis instance 1 interface ethernet-1/2.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl1# commit stay

srl2:

A:srl2# set / network-instance default protocols isis instance 1 admin-state enable
A:srl2# set / network-instance default protocols isis instance 1 net [ 49.0001.0000.0000.0002.00 ]
A:srl2# set / network-instance default protocols isis instance 1 level-capability L2
A:srl2# set / network-instance default protocols isis instance 1 interface system0.0 passive true ipv4-unicast admin-state enable
A:srl2# set / network-instance default protocols isis instance 1 interface ethernet-1/1.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl2# set / network-instance default protocols isis instance 1 interface ethernet-1/2.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl2# commit stay

srl3:

A:srl3# set / network-instance default protocols isis instance 1 admin-state enable
A:srl3# set / network-instance default protocols isis instance 1 net [ 49.0001.0000.0000.0003.00 ]
A:srl3# set / network-instance default protocols isis instance 1 level-capability L2
A:srl3# set / network-instance default protocols isis instance 1 interface system0.0 passive true ipv4-unicast admin-state enable
A:srl3# set / network-instance default protocols isis instance 1 interface ethernet-1/1.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl3# set / network-instance default protocols isis instance 1 interface ethernet-1/2.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl3# commit stay

srl4:

A:srl4# set / network-instance default protocols isis instance 1 admin-state enable
A:srl4# set / network-instance default protocols isis instance 1 net [ 49.0001.0000.0000.0004.00 ]
A:srl4# set / network-instance default protocols isis instance 1 level-capability L2
A:srl4# set / network-instance default protocols isis instance 1 interface system0.0 passive true ipv4-unicast admin-state enable
A:srl4# set / network-instance default protocols isis instance 1 interface ethernet-1/1.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl4# set / network-instance default protocols isis instance 1 interface ethernet-1/2.0 circuit-type point-to-point ipv4-unicast admin-state enable
A:srl4# commit stay

Four nodes. Seven commands each. One value changing between them.

The NET ID - Network Entity Title - encodes each node's identity. 49.0001.0000.0000.0001.00 means area 49.0001, system ID 0000.0000.0001. The system ID derives from the site ID using the same pattern the Python script uses. Site 1 is 0000.0000.0001. Site 4 is 0000.0000.0004. Consistent and never ambiguous.

level-capability L2 configures Level 2 routing only - backbone behavior. There are no Level 1 areas in this lab.

passive true on system0.0 means IS-IS advertises that loopback address into the domain but does not try to form adjacencies on it. The loopback is a destination, not a link.

circuit-type point-to-point on the ethernet interfaces - two routers, one wire. No DR/BDR election. Clean.

What the Startup Config Does Instead

The Python script generates these commands into a .cfg file for each node at Phase 2. When ContainerLab deploys the container at Phase 3, SR Linux loads that file at boot. IS-IS starts configured, without any manual input.

The NET ID generation in the script:

net_id = f"49.0001.0000.0000.000{sid}.00"

Site 1 produces 49.0001.0000.0000.0001.00. Site 4 produces 49.0001.0000.0000.0004.00. The rest of the IS-IS configuration is identical across all four nodes. The script writes it once and applies it four times with the correct site-specific values substituted.

Verification

After the nodes initialize:

docker exec clab-nbl-diamond-v1-srl1 sr_cli \
  -c "show network-instance default protocols isis adjacency"

+----------------+--------------------+-------+---------------+-------+
| Interface Name | Neighbor System Id | Level |  Ip Address   | State |
+================+====================+=======+===============+=======+
| ethernet-1/1.0 | 0000.0000.0002     | L2    | 172.254.254.2 | up    |
| ethernet-1/2.0 | 0000.0000.0003     | L2    | 172.254.254.6 | up    |
+----------------+--------------------+---------+-------------+-------+
Adjacency Count: 2

srl1 sees srl2 on ethernet-1/1 and srl3 on ethernet-1/2. Both Level 2. Both up.

The route table shows what IS-IS has learned:

Prefix               Route Type   Metric   Next-Hop(s)
172.2.255.255/32     isis         10       172.254.254.2(ethernet-1/1.0)
172.3.255.255/32     isis         10       172.254.254.6(ethernet-1/2.0)
172.4.255.255/32     isis         20       172.254.254.2(ethernet-1/1.0)

srl1 knows where every other loopback is. The path to srl4 goes through srl2 - Path A, metric 20, two hops. The network has learned its own shape.

The IS-IS database:

| 2 | 0000.0000.0001.00-00 | 8 | 1165 |
| 2 | 0000.0000.0002.00-00 | 7 | 588  |
| 2 | 0000.0000.0003.00-00 | 8 | 1114 |
| 2 | 0000.0000.0004.00-00 | 7 | 1068 |
LSP Count: 4

Four LSPs. One per node. The topology has been flooded. Every router holds the same database.

Why This Matters for the AI Layer

The AI layer does not touch IS-IS. It never modifies IS-IS configuration. IS-IS runs, converges, and maintains itself without any instruction from the intelligence layer above it.

What IS-IS gives the AI is a stable, self-healing foundation. Link fails - IS-IS reroutes. Node recovers - IS-IS re-converges. The AI does not manage these events. It assumes the underlay is working and focuses on the BGP control plane, which is the actual lever it pulls when it needs to steer traffic.

IS-IS is not the interesting part of this series. It is the necessary part. The next installment builds the layer the AI will actually reach into.

Next installment: The Overlay. BGP forms a full mesh across the underlay. The control plane is complete. The AI's lever is installed.

The Walker does not choose a direction. She chooses a rhythm.

In the architecture of THT, there are those who build walls and those who map the stars. The Hunter watches the horizon, waiting for a twitch in the brush that signals a beginning. The Sentinel stands in the center of the clearing, arms folded, defining the space that must be defended. They are defined by the geography of their station.

The Walker is the exception. She exists in the transition between stations.

Yellow Streetlights captures the moment the city stops being a landscape and becomes a pulse. When the artificial amber light hums, it vibrates at a frequency only she hears. It is not about reaching a destination; it is about the physics of the gait. Every strike of the boot against the pavement is an act of erasure. By walking, she levels the ground, turning the chaotic grid of the city into a singular, unwavering line.

She references the others (the Hunter, the Sentinel) not as people she knows, but as echoes in the concrete. She senses the cold of the pine and the tension of the boundary, but they are static things. They are pinned to the earth. She is the kinetic energy that moves between them, holding the chaos at bay simply by refusing to stand still.

The map is a lie told to those who need to believe they are going somewhere. The Walker knows the truth: the path is not a destination. The path is the friction between the sole of a shoe and the hard, uncaring stone.

[Verse 1] Streetlights buzz, a yellow glow The city sleeping down below Lace the boots and hit the gray Before the sun demands the day The rhythm starts before the thought This isn't something that is taught Put the foot down, find the beat The discipline is in the street

[Pre-Chorus] The empty block, the quiet air The only rule is being there No audience to keep the score Just the pavement and the core

[Chorus] One step forward, rhythm locks Shadows stretching down the blocks No one watching, no applause Moving to an older cause The map is just the concrete laid The path is how the steps are made

[Verse 2] Breath is steady, shoulders loose No performance, no excuse A distant train begins to roll The only witness is the soul The miles tick, the grid expands No weapons held inside the hands Just the tempo of the feet Beating on the empty street

[Pre-Chorus] The empty block, the quiet air The only rule is being there No audience to keep the score Just the pavement and the core

[Chorus] One step forward, rhythm locks Shadows stretching down the blocks No one watching, no applause Moving to an older cause The map is just the concrete laid The path is how the steps are made

[Bridge] The hunter had the frozen pine The sentinel, the boundary line I have the asphalt and the gray To hold the chaos at the bay I don't predict. I don't pretend. I walk the grid until the end.

[Final Chorus] One step forward, rhythm locks Shadows stretching down the blocks No one watching, no applause Moving to an older cause The map is just the concrete laid The path is how the steps are made Just this rhythm. Just this grade.

Why the Walker Matters

The Walker, when she determines she needs to hold the chaos at bay, does not reprogram the environment. She does not touch the Hunter’s brush or the Sentinel’s boundary. She reaches into the rhythm and maintains the tempo.

She doesn't redesign the city; she walks it until the chaos yields to the frequency of her stride. She doesn't work around the city; she works through it.

Yellow Streetlights by Tom Harvey

Stream and Save Yellow Streetlights - Distributed by DistroKid

DistroKid

Setting: Ósynilegr's studio. Morning. A bowl blank is mounted on the lathe. The floor has shavings. Not long enough that anything has emerged.

Artemisia: "You shape the wood until it yields its hidden curve, yes? I do the same with light. Men think we just fancy things into existence, but they don't see the ache in the shoulder or the grit under the nails. Show me how you hold the gouge. Does it resist you, or do you make it an extension of your own arm?"

Ósynilegr looks at the gouge in his hand. Then at the blank.

"Both. Depending on the day."

Artemisia: "And today?"

"It's refusing."

She steps closer. Not to the wood. To his hands.

Artemisia: "Where does it catch?"

He runs the tool along the surface. The wood grabs. He lifts off.

"There. Same place, three times now."

Artemisia: "And you keep returning to it."

Not a question.

Ósynilegr: "It's where the answer is."

She looks at the caught place in the grain. The way it runs against everything around it.

Artemisia: "What happens to the wood when you force past that?"

"It shows."

Artemisia: "Always?"

"Always."

A pause. The lathe turns.

Artemisia: "In paint it is the same. You can cover a bad passage. Build it up, glaze it over. But the surface remembers. Anyone who knows how to look can find it."

She watches him adjust his angle. Try again. The tool moves with the grain this time, not against it.

Artemisia: "Is that restraint, or surrender?"

He stops. The lathe slows.

The question sits in the room.

"There's a dance in it," he says finally. "Between what I bring and what's already there. I haven't always known which one leads."

Artemisia: "And now?"

Ósynilegr turns back to the work.

"Now I try to find out before I cut."

The lathe resumes. The shavings fall. The bowl begins to open.

At some point the room shifts, quieter perhaps, or the light has moved. He does not look up to confirm it.

He stays with the wood.

His hands follow the grain that refused him.

Architecture Overview: Phase 4Objective: Programmatically deploy a virtualized carrier-grade network fabric.Core Technologies: Containerlab, Python automation, Nokia SR Linux, and YAML topology generation.The Goal: Transform a single configuration file into 13 active containers, establishing the physical diamond topology required for AI traffic engineering.

The Deploy

The previous installments covered what this lab is and why it exists. This one is where it starts running.

One command:

python3 phase3_topology.py

Thirty seconds later, thirteen containers are running on a laptop. Four Nokia SR Linux routers. Four Linux client workloads. A full telemetry and logging stack. A diamond fabric that did not exist before that command ran.
This installment is about what that command actually does - and what it would take to do it by hand.

I prefer to build my labs and live networks using scripts because it allows for faster spin-ups. When I am deploying a 40-node Metro-Ethernet environment in the field, scripts are what reduce the errors. The lab should reflect that reality.

What ContainerLab Is

ContainerLab is an open-source tool built by Nokia and the network engineering community for running containerized network labs. It reads a topology file, creates the containers, connects them with virtual network interfaces, assigns management IPs, and brings everything up in the correct order.

The topology file is called lab.yml. It is not written by hand. The Python script generates it from lab_config.py - the single source of truth for everything in this lab. Node definitions, management IPs, link connections, container images, port bindings, environment variables - all of it derives from one file.

This matters because it means changing one value in lab_config.py changes everything that depends on it. The topology file, the router configs, the Prometheus scrape config, the Grafana datasource. Nothing is hardcoded twice.

What the Topology File Defines

The generated lab.yml describes thirteen nodes:

The diamond fabric - four Nokia SR Linux routers:

srl1:
  kind: nokia_srlinux
  mgmt-ipv4: 172.20.20.11
  startup-config: ../configs/fabric/srl1.cfg

srl2:
  kind: nokia_srlinux
  mgmt-ipv4: 172.20.20.12
  startup-config: ../configs/fabric/srl2.cfg

srl3:
  kind: nokia_srlinux
  mgmt-ipv4: 172.20.20.13
  startup-config: ../configs/fabric/srl3.cfg

srl4:
  kind: nokia_srlinux
  mgmt-ipv4: 172.20.20.14
  startup-config: ../configs/fabric/srl4.cfg

Four client workloads - Linux containers that generate traffic through the fabric:

client-l2-1:
  kind: linux
  mgmt-ipv4: 172.20.20.31

client-l2-2:
  kind: linux
  mgmt-ipv4: 172.20.20.32

client-l3-1:
  kind: linux
  mgmt-ipv4: 172.20.20.33

client-l3-2:
  kind: linux
  mgmt-ipv4: 172.20.20.34

Five telemetry containers - Prometheus, gNMIc, Grafana, Loki, Promtail - each with its generated config file mounted as a read-only bind.

Eight links connecting them in the diamond pattern:

links:
  - endpoints: ["srl1:e1-1", "srl2:e1-1"]   # Path A - upper
  - endpoints: ["srl1:e1-2", "srl3:e1-1"]   # Path B - upper
  - endpoints: ["srl2:e1-2", "srl4:e1-1"]   # Path A - lower
  - endpoints: ["srl3:e1-2", "srl4:e1-2"]   # Path B - lower
  - endpoints: ["client-l2-1:eth1", "srl1:e1-3"]
  - endpoints: ["client-l2-2:eth1", "srl4:e1-3"]
  - endpoints: ["client-l3-1:eth1", "srl1:e1-4"]
  - endpoints: ["client-l3-2:eth1", "srl4:e1-4"]

The diamond has two paths. Path A runs through srl2. Path B runs through srl3. This is the topology the AI layer will eventually manipulate - shifting traffic between paths based on latency forecasts.

The entire network is air-gapped. external-access: false. No routes leave the lab. Nothing reaches the internet. The lab lives entirely within itself.

The Node Type

Every SR Linux node in this lab uses type: ixr-d2l.

This is worth calling out because the documentation contains a common error - the letter is lowercase L, not the number 1. ixr-d2l is the IXR-D2L fixed-form-factor chassis. ixr-d21 does not exist. On a laptop, the D2L is the stable choice - it initializes correctly without requiring modular chassis configuration.

Getting this wrong produces containers that start and immediately exit. Getting it right produces four routers that boot cleanly and hold their configuration.

What Happened When It Ran

ContainerLab printed its progress as it worked. First the image pulls for containers not yet present locally. Then container creation - all thirteen, nearly simultaneously. Then the virtual link connections:

INFO Created link: srl1:e1-1 ▪┄┄▪ srl2:e1-1
INFO Created link: srl1:e1-2 ▪┄┄▪ srl3:e1-1
INFO Created link: srl2:e1-2 ▪┄┄▪ srl4:e1-1
INFO Created link: srl3:e1-2 ▪┄┄▪ srl4:e1-2
INFO Created link: client-l2-1:eth1 ▪┄┄▪ srl1:e1-3
INFO Created link: client-l2-2:eth1 ▪┄┄▪ srl4:e1-3
INFO Created link: client-l3-1:eth1 ▪┄┄▪ srl1:e1-4
INFO Created link: client-l3-2:eth1 ▪┄┄▪ srl4:e1-4

Then the summary table. Thirteen rows. Every row: running.

The diamond fabric exists.

What the Startup Config Does

Each SR Linux node loads a startup configuration file at boot. This is the "birth certificate" approach - the node comes up already configured rather than requiring manual CLI input after the fact.

If I were configuring srl1 by hand, which I often do in live networks, I would enter the CLI, type every line, and commit the changes.

It would look like this:

--{ candidate }--[ ]--
A:srl1# set / interface system0 subinterface 0 ipv4 admin-state enable
A:srl1# set / interface system0 subinterface 0 ipv4 address 172.1.255.255/32
A:srl1# set / interface ethernet-1/1 admin-state enable
A:srl1# set / interface ethernet-1/1 subinterface 0 ipv4 admin-state enable
A:srl1# set / interface ethernet-1/1 subinterface 0 ipv4 address 172.254.254.1/30
A:srl1# set / interface ethernet-1/2 admin-state enable
A:srl1# set / interface ethernet-1/2 subinterface 0 ipv4 admin-state enable
A:srl1# set / interface ethernet-1/2 subinterface 0 ipv4 address 172.254.254.5/30
A:srl1# set / network-instance default admin-state enable
A:srl1# set / network-instance default interface system0.0
A:srl1# set / network-instance default interface ethernet-1/1.0
A:srl1# set / network-instance default interface ethernet-1/2.0
A:srl1# commit stay

That is just the interface configuration for one node. Before IS-IS. Before BGP. Before services. Before telemetry.

You would type that four times - once per node - and each node would have different IP addresses, a different system IP, different neighbor relationships. The next installment covers IS-IS, and you will see exactly what four nodes of manual routing protocol configuration looks like.

The startup config file handles all of that automatically at boot. The Python script generates it. The IPs derive from the site ID - srl1 is site 1, so its system IP is 172.1.255.255. srl2 is site 2, so its system IP is 172.2.255.255. The pattern is consistent and never hardcoded.

What Comes Next

ContainerLab reports the containers as running. But running in Docker terms means the container process started. It does not mean the Nokia SR Linux operating system inside that container has finished initializing.

SR Linux takes two to four minutes after Docker reports running before the NOS is ready to accept CLI connections, process startup configs, and form protocol adjacencies. This is not a bug. It is a carrier-grade operating system doing what carrier-grade operating systems do - initializing carefully.

The next installment starts after that wait is over. IS-IS adjacencies forming. The network learning the shape of the room it is in.

Build Record

Deployed May 17, 2026 - Dell Precision 3571 - Garuda Linux rolling - ContainerLab 0.71.0 - SR Linux v26.3.2

10:13:09 INFO Containerlab started version=0.71.0
10:13:09 INFO Parsing & checking topology file=lab.yml
10:13:09 INFO Creating docker network name=clab-nbl-diamond-v1-mgmt
             IPv4 subnet=172.20.20.0/24
10:13:40 INFO Creating container name=srl1
10:13:40 INFO Creating container name=srl2
10:13:40 INFO Creating container name=srl3
10:13:40 INFO Creating container name=srl4
10:13:43 INFO Created link: srl1:e1-1 ▪┄┄▪ srl2:e1-1
10:13:43 INFO Created link: srl1:e1-2 ▪┄┄▪ srl3:e1-1
10:13:43 INFO Created link: srl2:e1-2 ▪┄┄▪ srl4:e1-1
10:13:43 INFO Created link: srl3:e1-2 ▪┄┄▪ srl4:e1-2

╭──────────────────────────────────┬──────────────────┬─────────┬──────────────╮
│ clab-nbl-diamond-v1-srl1         │ nokia_srlinux    │ running │ 172.20.20.11 │
│ clab-nbl-diamond-v1-srl2         │ nokia_srlinux    │ running │ 172.20.20.12 │
│ clab-nbl-diamond-v1-srl3         │ nokia_srlinux    │ running │ 172.20.20.13 │
│ clab-nbl-diamond-v1-srl4         │ nokia_srlinux    │ running │ 172.20.20.14 │
│ clab-nbl-diamond-v1-client-l2-1  │ linux            │ running │ 172.20.20.31 │
│ clab-nbl-diamond-v1-client-l2-2  │ linux            │ running │ 172.20.20.32 │
│ clab-nbl-diamond-v1-client-l3-1  │ linux            │ running │ 172.20.20.33 │
│ clab-nbl-diamond-v1-client-l3-2  │ linux            │ running │ 172.20.20.34 │
│ clab-nbl-diamond-v1-prometheus   │ linux            │ running │ 172.20.20.20 │
│ clab-nbl-diamond-v1-gnmic        │ linux            │ running │ 172.20.20.21 │
│ clab-nbl-diamond-v1-grafana      │ linux            │ running │ 172.20.20.22 │
│ clab-nbl-diamond-v1-loki         │ linux            │ running │ 172.20.20.23 │
│ clab-nbl-diamond-v1-promtail     │ linux            │ running │ 172.20.20.24 │
╰──────────────────────────────────┴──────────────────┴─────────┴──────────────╯

Phase 3 Complete -- lab deployed
Nodes: 13 | Links: 8 | Bridge: br-nbl-v1 | Air-gapped: True

Thirteen containers. Eight links. Diamond fabric online.

Next installment: The Underlay. IS-IS adjacencies form. The network learns its own topology. Four nodes of manual configuration shown in full.

Hagalaz - Poem One - Veiðimenn Fókusar

Hagalaz: The Disappearing

The cold bites through my wool. I press my thumb to the frost on the bark.

The elders stay by the hearth. They speak of the quiet woods. They do not hear the pounding in my chest. It is louder than the winter wind.

I cross the fire line. I leave the village behind.

The snow is deep. My boots crush the ice. Hunger pulls me forward. I am only breath and bone.

I reach the tree line. The sky is dead white. The pines are black iron.

Ravens circle above. They watch the hunt. They wait for the kill.

I see the shape in the mist. It is heavy and still.

I draw the string. The tension cuts my fingers. My arm locks. I hold my breath. I am ready.

The mist moves. The shape shifts.

My hand waits to loose the string. The release never comes. The shape dissolves before my fingers can know it. It scatters in the cold glow of the dawn.

I lower the bow. The string slaps my wrist. There is no blood on the snow. There is no snapped twig.

I walk to the empty shadow. Nothing is there. The forest keeps its secret.

A wind drops from the pines. It hits my chest. It feels older than my father. It is older than the feast and the death.

It passes through my ribs. It leaves a weight I cannot see. It strips my name away.

I stand in the cold. My hands are empty. The dark speaks my shame back to me.

I am changed. I am the same. I am still hungry.

The Lyrics

 [Verse 1]
The elders spoke of stillness
As if the woods were blind
But I heard my own heart pounding
Past the fire line
I pressed my thumb to frost
Like they taught me when I was young
Read the earth in silence
Till the cold bit my tongue
 
[Pre-Chorus]
Beyond the last pine branch
There is no village song
Only breath and bone and hunger
Only the way things go wrong
 
[Chorus]
At the tree line
At the tree line
I lost my name
At the tree line
At the tree line
The dark spoke back my shame
 
[Verse 2]
Ravens held the ceiling
Black marks in the drift-white sky
I drew the string with purpose
Held my body still and hard
Then the mist took the shape
Before my hand could know
No snapped twig, no blood to follow
Just the dawn in its cold glow

[Pre-Chorus]
I searched the empty shadow
Where the beast should have stood
But the forest kept its secret
Like a mouth full of old blood

[Chorus]
At the tree line
At the tree line
I lost my name
At the tree line
At the tree line
The dark spoke back my shame

[Bridge]
A wind came through the pines
And it knew me by my breath
Older than my father
Older than the feast and death
Something passed through my ribs
Not fury, not fear
A weight with no face at all
And it left me standing here

[Final Chorus]
At the tree line
At the tree line
I lost my name
At the tree line
At the tree line
I came back changed the same
At the tree line
At the tree line
The woods called me by flame

The Disappearing (Hagalaz) by Tom Harvey

Stream and Save The Disappearing (Hagalaz) - Distributed by DistroKid

DistroKid

Architecture Overview: Phase 3Objective: Establish a deterministic, high-performance host OS for containerized network testing.Core Technologies: Garuda Linux (Arch-based), Bare-metal infrastructure, and automated version-control scripts.The Goal: Provide a stable, lean execution floor for the Nokia SR Linux containers and the AI intelligence layer.

Before you run the first command, you have to get the machine to boot.

That sounds obvious. It isn't always.

The Floor Change

In Installment Two, I described Ubuntu as the workshop floor. The ground everything else stands on.

We are on a different floor now.

That's not a small thing, and it deserves an explanation before we go any further.

Ubuntu 24.04 LTS is a solid, widely-used Linux distribution. It is what most engineers reach for when they want something stable and supported. It is also built for general-purpose use - the kind of system that works for most workloads without asking too much of the person setting it up.

This lab has two distinct workloads running on one machine. The publishing pipeline for this series. And the Nokia network environment where the actual research happens. Each one makes demands. Neither one benefits from a general-purpose compromise.

Garuda Linux is a distribution built on Arch Linux - a leaner, more deliberate foundation that gives you exactly what you choose to put on it and nothing else. Where Ubuntu arrives with decisions already made, Arch-based systems ask you to make them yourself. That is not a flaw. For a lab environment that needs to be precise, predictable, and purpose-built, it is the right characteristic.

The desktop environment is Hyprland - a tiling window manager running on Wayland, the modern Linux display protocol. Tiling means the screen is divided into defined workspaces rather than floating windows. The terminal, the editor, and the file tree exist simultaneously without reaching for a mouse. For the kind of sustained technical work this lab requires, that is not a preference. It is a productivity decision.

The editor is Neovim - a keyboard-driven code editor that rewards configuration. The terminal is Kitty, GPU-accelerated and Wayland-native. The container management interface is LazyDocker. Every tool in the stack was chosen to serve the two workloads without friction between them.

One machine. Two terrains. A floor built to hold both.

The Obstacle Before the Obstacle

The plan was to install Garuda on the Dell Precision 3571 that runs this lab. The process requires a bootable drive - something the machine can start from before the new operating system exists on it.

The normal approach is a USB thumb drive. Load a boot utility onto the drive, copy the operating system image onto it, plug it in, restart the machine, and follow the installer.

I did not have a spare thumb drive.

What I had was a 1.8 terabyte external storage drive - the X10 Pro - sitting on the bench already connected to the machine. It is a large, fast drive in an external enclosure. It looked like the solution.

It was not.

What the BIOS Was Actually Saying

Here is what happened. I loaded the boot utility onto the X10 Pro, copied the Garuda image onto it, and restarted the machine. I entered the boot menu - the screen that appears before the operating system loads, where you choose what to start from. I selected the X10 Pro. The machine came back up into Ubuntu 24. Every time.

The first reading of that situation is: the BIOS is wrong. The machine is ignoring my instruction.

That is not what was happening.

The X10 Pro is a specific kind of drive. It is an NVMe drive - the fast solid-state storage type - housed inside a USB enclosure. NVMe is the same technology that lives inside the laptop itself. The BIOS was reading the X10 Pro's hardware signature, identifying it as NVMe storage, and routing it accordingly - alongside the internal drive that already had Ubuntu on it. It was not ignoring me. It was reading the hardware accurately. The enclosure created genuine ambiguity that the boot process could not resolve cleanly.

The machine knew what it was seeing. I had not given it something unambiguous to work with.

A standard USB thumb drive has no such identity problem. It registers as one thing. The BIOS sees it as one thing. The boot sequence follows without conflict.

A 64GB SanDisk thumb drive from Best Buy solved in one attempt what thirty minutes of troubleshooting could not.

Why This Belongs in a Series About Intelligent Networks

The BIOS was not malfunctioning. It was doing precisely what it was built to do - reading its environment and routing accordingly. The problem was that the environment I gave it contained ambiguity. The system responded to what was actually there, not to what I intended.

That is the same problem this lab is being built to solve at the network level.

An autonomous network system reads its environment continuously. It builds a model of what normal looks like. It acts when reality departs from that model. The quality of those actions depends entirely on the quality of the information feeding into them. An ambiguous signal produces an ambiguous response. Garbage in, garbage out - except in a carrier network, garbage out means dropped calls, failed transactions, interrupted service.

Clarity is not a convenience. It is a design requirement.

The thumb drive was clarity. And that's the lesson the BIOS taught before the first command ran.

What Got Built

Garuda Linux is running on the Dell Precision 3571. The full stack is operational.

The publishing side: Neovim with the LazyVim configuration layer, Obsidian connected to a version-controlled repository, a coordination script that moves information between the different parts of this operation automatically. The writing environment is faster and more focused than anything I have run before.

The lab side: Docker, ContainerLab version 0.71.0, the Nokia SR Linux environment waiting to come back online. Ollama running in CPU mode - the i7-12800H processor in this machine handles seven-billion-parameter local AI models without issue, which opens a path for the kind of on-device inference work that becomes relevant later in this series.

One machine. The publishing pipeline and the network lab running side by side. The craftsman's bench and the engineer's rack sharing the same surface.

The Coordination Layer

One thing worth naming before the next installment.

A lab that is documenting its own progress while simultaneously running active research has a coordination problem. Information needs to move between different parts of the operation reliably, automatically, and with a record that persists. Not because it is convenient, but because an intelligent system needs to know its own state.

That is not a philosophical statement. It is an engineering requirement.

The solution is a coordination script - an automation layer that runs on a schedule, moves the right information to the right places, and commits a record of every operation to a version-controlled repository. The lab's memory, maintained automatically.

It ran for the first time this week. The first push to the repository went out before a file exclusion list was in place. A protected file went up with everything else.

The exclusion list is now in place. The repository is clean. The incident is documented here because that is exactly the kind of thing this series exists to document. Automation is not a finished state. It is a practice.

The same is true of the network.

What's Next

The Nokia lab environment needs to come back online in its new home. ContainerLab reads the topology file. SR Linux nodes boot inside Docker containers. The diamond fabric comes alive.

That is Installment Four.

Next installment: The First Command. The topology file loads. Four routers appear. The lab is alive.

If this kind of work is useful to you, subscribe.
One email when something new publishes. No noise.

Subscribe

The Silent Observer

Every engineer has a story about the night the plan failed.

Not a small failure. The kind where the load climbs past what the architecture was built to hold and you watch it happen in real time with nothing left to do but read what the system is telling you and respond to what’s actually there instead of what you designed for.

I have been in that server room.

Blinking racks like tired eyes. Numbers shaking. The plan that looked perfect an hour ago meeting something it was never built for.

I have also been on the mat when the opponent shifted out of the light and the combination I memorized became irrelevant in the first half second of live contact.

And I have been at the lathe when the grain decided its own direction and the straight line I planned met the truth of the wood and lost.
Three different rooms. The same lesson every time.

The map is not the territory. The blueprint does not negotiate with reality. The only plan that survives is the one the body learns.
Grid and Grip is that lesson set to music. Driving, methodical, a machine learning to breathe. For the engineer, the craftsman, and anyone who has ever watched something carefully built meet something that didn’t care.

Hold your ground anyway.

Lyrics

[Verse 1]
Draw the box in ink
Call it done, call it clean
But the thing moves first
Then it teaches the machine
Complex systems buckle
On one small bad assumption
One loose link in the chain
And the frame cannot sustain

[Pre-Chorus]
I watched the numbers shake
In the server room at night
Blinking racks like tired eyes
Holding on for life
The plan looked perfect
Till the load began to climb
What you wrote down on the paper
Can’t negotiate with time

[Chorus]
It’s not a checklist
It’s a breath, and a stance
It’s not a checklist
It’s stillness in the storm
Yeah, the map is not the territory
(hold your ground)
The map is not the territory
(find your frame)

[Verse 2]
In the dojo, hands up
We move before we think
One step off the pattern
And the whole room starts to speak
Read the grain of wood
See where the split will run
The straight line lies sometimes
When the load weighs heavy enough

[Pre-Chorus]
I stopped trying to freeze it
Stopped asking it to fit
Every clean machine breaks
When you lean too hard on it
So I let the edge show
Let the tension stay in view
What survives the impact
Is the part that learns with you

[Chorus]
It’s not a checklist
It’s a breath, and a stance
It’s not a checklist
It’s stillness in the storm
Yeah, the map is not the territory
(hold your ground)
The map is not the territory
(find your frame)

[Bridge]
Blueprint in my fist
Still, the world kept moving
I could hear the fault line
Under every proving
Not a perfect posture
Not a holy guarantee
Just a body in the weather
Learning how to be

[Final Chorus]
It’s not a checklist
It’s a breath, and a stance
It’s not a checklist
It’s stillness in the storm
Yeah, the map is not the territory
(hold your ground)
The map is not the territory
(find your frame)
It’s not a checklist
It’s a breath, and a stance