Machine Learning at the Transfer Layer

PyTorch taught computers to think. NTL teaches networks to learn.

Status: RESEARCH — Foundational insight

The Core Argument

PyTorch and TensorFlow gave the world a programming model for neural networks: define nodes, connect with weighted edges, propagate signals, learn from outcomes. This model revolutionised computation. NTL applies the same model to data transfer. The nodes are infrastructure. The connections are synapses. The signals are data. The learning is real. The hardware acceleration is the same silicon. This is not an analogy. NTL’s routing model is an actual neural network, executable by the same hardware neural engines that run PyTorch models on your phone.

The Twelve Principles

PyTorch implements five neural principles. NTL implements twelve.

Principles 1-5: What PyTorch Does

#	Principle	PyTorch	NTL
1	Weighted graph	Neurons + weighted edges	Nodes + weighted synapses
2	Forward propagation	Input → layers → output	Emit → synapses → activation
3	Junction transformation	Layer functions (ReLU, matmul)	Synapse functions (PII strip, anonymise)
4	Learning	Backpropagation + gradient descent	Hebbian + gradient + spike-timing
5	Improvement over time	Training makes model better	Traffic makes routing smarter

Principles 6-12: What NTL Adds

#	Principle	What It Means for NTL
6	Inhibition	High-priority signals suppress low-priority. Financial transactions dampen analytics noise.
7	Recurrence	Feedback loops keep context alive. Updates circulate rather than fire-and-forget.
8	Neuromodulation	Meta-signals change network-wide behaviour. “High load” reduces global sensitivity.
9	Rich plasticity	Timing matters for learning. New connections form where useful. Dead connections pruned.
10	Hierarchical processing	Raw data, patterns, and recommendations processed at multiple levels simultaneously.
11	Sparse activation	Most nodes dormant. Near-zero power when idle. Only active paths consume resources.
12	Multi-scale temporality	Millisecond routing, minute adaptation, hour learning, week topology evolution.

PyTorch simplified to five because it optimised for GPU computation. NTL runs on infrastructure with access to neural hardware and can implement the full repertoire.

The Complete Mapping

Concept	PyTorch / TensorFlow	NTL
Node	Neuron (math function)	Infrastructure node (device, DB, service)
Connection	Weighted edge	Synapse (weighted, transforming, learning)
Signal	Activation tensor	Data signal (mutation, event, context)
Weight	Learned parameter	Synapse weight
Forward pass	Input → layers → output	Emit → synapses → activation
Transformation	Layer function	Synapse function
Learning rule	Backprop + SGD	Hebbian + gradient + spike-timing
Loss function	Error vs desired output	Delivery success vs intent
Batch	Training samples	Signals in time window
Epoch	Pass through training data	Learning cycle across synapses
Inference	Trained model on new input	Mature network routing new signals
Training	Weight adjustment	Traffic adjusts synapse weights
Overfitting	Memorises training data	Over-specialises to current traffic
Regularisation	Dropout, weight decay	Synapse decay, min weight thresholds
Transfer learning	Pre-trained weights for new task	Pre-trained topology for new deployment
Hardware	GPU (CUDA, ROCm)	NPU (Neural Engine, Hexagon, Da Vinci)

Hardware: Runs Anywhere, Neural Silicon Optional

NTL’s routing model is small enough that hardware choice does not matter. A node with 100 synapses and 8 signal types holds fewer than a thousand parameters. Scoring its candidate paths is a few hundred multiply-accumulates — microseconds on any CPU made this century, including the one in a $5 microcontroller. This is the honest framing, and it is the stronger claim: NTL runs everywhere, with no accelerator required. Neural silicon is therefore an option, not a dependency:

Device	NPU	TOPS
iPhone (A14+)	Apple Neural Engine	15.8
Snapdragon 8 Gen 2+	Qualcomm Hexagon	12.4
Exynos 2400+	Samsung NPU	14.7
Kirin 9000+	Huawei Da Vinci	8.0

These figures describe the silicon’s peak throughput, not NTL’s need for it. A thousand-parameter model does not require 15 TOPS, and the table should not be read as implying otherwise.

Two honest caveats. First, at this model size an NPU offers no meaningful speedup — the work is already microseconds, and dispatch overhead to an accelerator would likely cost more than the computation saves. Second, mobile operating systems restrict NPU access from background processes, which is exactly where a transport layer runs; on iOS and Android a background NTL node should not expect NPU access at all.The upside is real but bounded: where a node does have accessible neural silicon and a much larger learned model — learned transformations rather than path scoring — that hardware becomes useful. Today it is not load-bearing, and NTL’s viability does not rest on it.

Earlier drafts of this document claimed NPU usage as a differentiator (“every modern phone has a neural engine sitting idle; NTL gives it a job”). That claim does not survive scrutiny at this model size, and it is withdrawn. What remains is better: the model is small enough to run on anything, and the network learns regardless of what silicon it lands on.

Any Acknowledgement Cycle Is a Training Loop

The general principle: any storage or application layer that acknowledges what it received supplies NTL’s training signal. There is nothing database-specific about it. What the learning loop needs is one thing — an outcome flowing back — and any request/ack, sync/confirm, or publish/receipt cycle already provides it.

Producer emits a change or request
Adapter turns it into an NTL signal
NTL routing model samples a path over its synapses
Signal propagates (transforming at synapses as configured)
Receiver handles it and reports the outcome
Outcome returns to the origin as a signed Receipt
NTL resolves the journalled decision and updates weights
Subsequent signals of that type route better

Every acknowledgement = one training step

Step 6 is the one that matters, and the one NTL previously lacked. Without a returning outcome the loop is open, weights have no gradient, and the system only appears to learn. The Receipt type and the reward table in spec/learning-model close it.

Worked Examples

The same loop, over four different backing systems:

System	Producer	Outcome signal
PostgreSQL	Logical replication slot	Apply confirmation / conflict
Any HTTP service	Webhook or API call	2xx / 4xx / 5xx via a Web2 adapter
Message queue	Published message	Consumer ack / nack
Graph sync protocol	Graph mutation	Sync success / conflict / failure

The last row is where SiafuDB’s Graph Sync Protocol fits — a good worked example because its conflict outcome is richer than a bare success/failure, so the reward it produces is more informative. It is one instance of the pattern, not the pattern itself.

Why Richer Outcomes Train Better

A binary success/failure signal teaches less than a graded one. A conflict outcome says “the path worked but the write lost a race” — which should not penalise the route. Adapters SHOULD map their layer’s outcome vocabulary onto NTL’s reward table deliberately rather than collapsing everything to success or failure, since a mis-mapped outcome trains the model toward the wrong thing.

Engineering Implications

1. ML Analysis Tools Apply

NTL’s topology is a neural network. ML analysis tools work on it:

Weight distribution visualisation (strong vs weak synapses)
Activation maps (which nodes are active)
Dead neuron detection (unreachable nodes)
Training metrics (delivery success over time)

2. Hyperparameters Need Tuning

ML Hyperparameter	NTL Equivalent
Learning rate	Hebbian rate on synapses
Weight decay	Synapse decay half-life
Batch size	Signal aggregation window
Dropout	Random synapse deactivation
Network depth	Maximum hop count
Activation threshold	Node activation threshold

Different deployments need different hyperparameters: a high-traffic application deployment is not a low-traffic IoT mesh. Defaults per deployment class — edge, full node, high-traffic — are tabulated normatively in spec/learning-model §5.

3. Learned Transformations

Today: synapse transformations configured (“strip PII”). Future: synapse learns what receiver needs and strips what it doesn’t. This is attention applied to data transfer.

4. Transfer Learning

Pre-trained routing model from Harare deployment fine-tuned for Lusaka. Routing intelligence is portable.

5. Distributed Training

Multiple NTL nodes coordinating learning, analogous to PyTorch’s DistributedDataParallel. Network-wide routing improves through coordinated weight updates.

Known Failure Modes and Mitigations

Framing NTL’s routing as machine learning means inheriting ML’s failure modes. They are enumerated here, and specified normatively in spec/learning-model §7 and spec/threat-model.

Failure	ML name	What it looks like in NTL	Mitigation
Ossified routing	Insufficient exploration	Greedy top-N selection starves unselected paths; a synapse never chosen is never rewarded, so it only decays	Stochastic (softmax) selection with a temperature floor — learning-model §4
Weight saturation	Unbounded weights	Additive updates push every synapse to `max_weight`; scoring stops discriminating and routing degenerates to flooding	Divisive normalisation of total outbound weight — learning-model §2.3
Weight poisoning	Data poisoning	An attacker spams traffic to steer a victim’s weights toward their own nodes	Per-identity influence caps, persisted and asymmetric — threat-model §1
Forged rewards	Label poisoning	Fabricated positive receipts teach the model that a bad path is good	Receipts must be signed and must match a journalled decision — threat-model §2
Reward starvation	Missing labels	Nothing emits receipts, so every decision stays `pending` and no weight ever moves	Timeouts are a real (weak) negative reward; operators alert on the pending fraction
Over-specialisation	Overfitting	Topology tunes to current traffic and routes new patterns badly	Mandatory decay; continued exploration
Stale confidence	Distribution shift	Weights outlive the topology they described	Half-life decay — learning-model §3
Thrash on lossy links	Label noise	Packet loss is read as routing failure, and the model oscillates	Timeout penalised more weakly than explicit rejection

Two of these deserve emphasis, because they were latent in the original design rather than hypothetical: ossified routing followed directly from deterministic top-N fanout, and weight saturation from purely additive updates. Both are now fixed in the specification. A learned system whose failure modes are undocumented cannot be operated safely. Publishing them is not an admission of weakness — it is the difference between a research claim and an engineering one.

What This Changes

NTL is not a messaging protocol with ML features bolted on. The routing model is a learned model, the traffic is its training data, and the delivery outcomes are its labels. The claim stops there, deliberately. NTL’s routing is a small online learner — a contextual bandit over synapses — not a deep network, and it does not need neural silicon to run. Overstating the hardware story would cost more credibility than it buys. This breaks conventional thinking because:

Protocols don’t learn. HTTP doesn’t get better at routing over time. TCP doesn’t strengthen paths that carry successful traffic. NTL does.
Transfer layers don’t learn from outcomes. Existing protocols route on configuration or on link-state metrics, not on whether delivery actually succeeded for this kind of traffic. NTL closes that loop with signed receipts.
Infrastructure and ML are treated as separate fields. NTL puts the model in the infrastructure: the traffic is the training data and the routing decision is the inference. This is not a new idea — Q-routing demonstrated it in 1994 (see research/07) — but it has not been carried into a general-purpose transport layer with per-type affinity and activation backpressure.

The mechanism is specified and implemented, so this is checkable rather than aspirational: see spec/learning-model for the normative rules and research/07-prior-art for how it sits against the lineage it comes from.

Machine Learning at the Transfer Layer — April 2026 — The Bundu Foundation “PyTorch taught computers to think. NTL teaches networks to learn.” See also: spec/learning-model for the normative rules, and research/07-prior-art for the lineage.

Research

02 — Machine Learning at the Transfer Layer

The Core Argument

The Twelve Principles

Principles 1-5: What PyTorch Does

Principles 6-12: What NTL Adds

The Complete Mapping

Hardware: Runs Anywhere, Neural Silicon Optional

Any Acknowledgement Cycle Is a Training Loop

Worked Examples

Why Richer Outcomes Train Better

Engineering Implications

1. ML Analysis Tools Apply

2. Hyperparameters Need Tuning

3. Learned Transformations

4. Transfer Learning

5. Distributed Training

Known Failure Modes and Mitigations

What This Changes

​The Core Argument

​The Twelve Principles

​Principles 1-5: What PyTorch Does

​Principles 6-12: What NTL Adds

​The Complete Mapping

​Hardware: Runs Anywhere, Neural Silicon Optional

​Any Acknowledgement Cycle Is a Training Loop

​Worked Examples

​Why Richer Outcomes Train Better

​Engineering Implications

​1. ML Analysis Tools Apply

​2. Hyperparameters Need Tuning

​3. Learned Transformations

​4. Transfer Learning

​5. Distributed Training

​Known Failure Modes and Mitigations

​What This Changes

The Core Argument

The Twelve Principles

Principles 1-5: What PyTorch Does

Principles 6-12: What NTL Adds

The Complete Mapping

Hardware: Runs Anywhere, Neural Silicon Optional

Any Acknowledgement Cycle Is a Training Loop

Worked Examples

Why Richer Outcomes Train Better

Engineering Implications

1. ML Analysis Tools Apply

2. Hyperparameters Need Tuning

3. Learned Transformations

4. Transfer Learning

5. Distributed Training

Known Failure Modes and Mitigations

What This Changes