Back to blog

2026-05-20

Tension Telemetry as a Receipt

Why tension, relaxation steps, graph size, and outputs belong in the experiment record.

A TS claim should not end at a paragraph. If the system says a graph relaxed, the receipt should show what moved: initial tension, final tension, active nodes, edge pressure, update count, seed, runtime, and the exact limit of the setup.

This is the reason tension telemetry is treated as first-class evidence. Text can explain what happened, but telemetry tells another engineer where to look. It turns a claim from a surface statement into a substrate trace.

Take the local relaxation line. The important part is not that the result sounds impressive. The important part is that the reported tension changed from 156.216618 to 11.862658 inside a fixed toy setup. That lets the proof note say something narrow and auditable: local updates reduced graph tension under these constraints. The limit is equally important: this is a quadratic constraint graph, not a full-scale benchmark.

For TensionLM, the same principle applies to language-model work. If sigmoid tension attention is useful, the receipts should include matched softmax comparisons, pairwise tension fields, fixed prompts, checkpoint hashes, and failure cases. The strongest version of the claim is not bigger language. It is better routing from observed behavior to internal pressure.

What exists now is a public format for receipts and a project map that points toward replay. What is still missing is the boring production-grade layer: standardized JSON outputs, exact commands, commit hashes, and public artifacts for every serious claim.

tensiontelemetryreceipts