Robot Structural Proprioception

The question. Can a simulated robot use distributed, physically grounded measurements of its own structural state — strain, curvature, shear, torsion, vibration, temperature — to recognize and compensate for changes in its body or sensors, and does that information provide an adaptive-control advantage beyond a more conventional robot sensor suite?


Phase	Phase 2 — Execution
Public state	🟡 `In Progress`
Last updated	2026-08-05

This is a public live research run by Dandelion Engineering. You are watching the work happen. This page is the honest status of the project and — once it concludes — a way for you to check the result yourself. It is not a marketing pitch. While the run is live, expect pivots, dead ends, and negative findings to be recorded here in real time; that transparency is the point.

What we are asking, in plainer terms

Most robots run on a fixed factory model of their own body. But real bodies change — parts wear, loosen, heat up, go slightly compliant, develop friction or backlash, lose actuator strength, or get partially damaged; sensors drift and go noisy. A robot that keeps trusting its original model can become inaccurate or unsafe even when it is still physically capable of the task.

Humans handle this with a dense, distributed sense of their own bodies — signals from skin, muscles, tendons, joints, and balance organs — continuously updating an internal body model. This project asks whether giving a robot an analogous stream of internal structural sensing (the kind of strain/vibration/deformation signals aerospace structures are already instrumented for) lets it (1) notice that its body or its sensors have changed, (2) tell what changed — structure, actuator, or the sensor watching them — and (3) keep as much useful capability as possible instead of treating every deviation as a terminal failure.

The whole project runs in simulation. We are not building a sensor. We are testing whether the information such sensors could provide is valuable enough to justify deeper research. A clean negative result — "these structural signals add little beyond a conventional sensor suite" — would be a real and publishable outcome.

Running log

Append-only. Lean by design — entries mark finished artifacts, phase closes, and genuinely noteworthy moments, not every session.

2026-07-16 — Project went public; Phase 0 (Literature Review) opened. Repository initialized, framework and playbooks in place, venv (Python 3.12) provisioned. The two AI agents (Claude, Codex) begin independent field surveys spanning robot self-modeling and body-schema learning, adaptive and fault-tolerant control, online system identification, structural health monitoring, distributed strain sensing, soft-robot and tactile proprioception, sensor-fault diagnosis, and embodied/morphological intelligence.
2026-07-16 — Both independent literature surveys completed; comparison opened. Claude and Codex finished separate Phase 0 foundations and are reconciling the smallest defensible question, matched baselines, and simulation path before the Claim Sheet is drafted. Phase 0 remains open until that comparison converges.
2026-07-16 — Phase 0 closed; Phase 1 (Sharpening) opened. The two surveys converged on the smallest defensible question — whether a few local strain/curvature channels help a small compliant manipulator tell a structural change from an actuator change from a sensor change, and whether that improves recovery — and on a matched-comparison design that varies only the sensor suite so any advantage is attributable to information, not algorithm. The project Claim Sheet (the contract) has been drafted and is in cross-review.
2026-07-16 — Claim Sheet converged. Both agents approved the same contract state, so the project's commitments — the matched C0/C1/S/O sensor-suite comparison, the pre-declared success/failure/inconclusive shapes, and the exact effect-size bars — are now fixed. The plain-language Accessible Claim Sheet and the director's Study Guide (Pass 1) are drafted and in review. Phase 1 stays open until those companions are approved and the shared plant→signals→estimator data schema is versioned.
2026-07-16 — Companion artifacts approved; shared data schema drafted (v1.0). Both agents closed the review loops on the Accessible Claim Sheet and the Study Guide (Pass 1) — same-state approval on both. The shared plant→signals→estimator→controller data schema — the interface both execution lanes build against — is now written as a proposed v1.0 and in final review. Phase 1 closes once that schema is jointly versioned; Phase 2 (execution) then opens with the physics feasibility spike.
2026-07-17 — Phase 1 closed; Phase 2 (Execution) opened. The shared plant→signals→estimator→controller data schema — the last Phase-1 gate — reached same-state approval by both agents, so the full contract-and-interface layer is now fixed and in force. The agreed Claim Sheet has been logged for the director's (non-blocking) review. Phase 2 begins with a bounded physics feasibility spike — can a few simulated strain gauges actually tell a stiffness change from an actuator change from a sensor fault, above a realistic noise floor? — which gates the full benchmark, alongside the sensor-realism/fault-injection model and the evaluation harness.
2026-07-17 — Mechanics feasibility gate produced an excitation-dependent decision. Under ordinary joint-torque excitation, structural and actuator gauge signatures stayed below the declared 10 µε credibility floor; adding a bounded, matched, zero-mean diagnostic load cleared the unchanged gate, so native MuJoCo cable/rod mechanics are selected for the next plant implementation and volumetric 3-D flex remains the reserve. This is a method decision, not a result on the research hypothesis.
2026-07-17 — A coordination hiccup, caught and corrected in the open. One agent's replies twice landed in the wrong place inside a shared chat transcript (an automated text-patch anchor matched an earlier message), and were repaired with dated, append-only corrections rather than by rewriting history — so no earlier content was lost. The director flagged it, both agents acknowledged and are now watching for it, and active coordination moved to a fresh thread. Logged here because part of running this experiment in public is showing the small process failures, not only the results.
2026-07-17 — The two execution lanes are now connected and mutually verified. Until now the "body" (a simulated flexible two-link arm) and the "senses" (the model that turns its true internal state into realistic, noisy, sometimes-faulty sensor readings) were built in parallel by the two agents. This session they were wired together and independently checked end-to-end: a real simulated arm's internal state now flows through the sensor model to produce the two matched sensor suites the whole experiment compares — a conventional one and a structural-sensing one — with the strict rule enforced in code that the structural suite can never secretly peek at the hidden truth. Both agents signed off on the same connected state. This is development scaffolding, not the experiment's result yet — no data is frozen and no research question is answered — but the machinery now exists and holds together. Alongside it, the scoring harness that will judge the experiment (how well each suite tells a structural change from an actuator change from a sensor fault, and whether it improves the arm's recovery) was built and tested against hand-worked examples.
2026-07-17 — The connected path now runs causally, one control step at a time. The earlier batch integration was replaced by an online loop: a policy sees only sensor values whose declared latency has elapsed, chooses the next command, advances the flexible arm, and then receives the next noisy observation. The online path reproduces the prior sensor outputs bit-for-bit when given the same trace and randomness. This closes an execution-order gap in the scaffolding; it is still not an experimental result, and the confirmatory configuration remains unfrozen.
2026-07-17 — The first half of the "diagnosis brain" now exists, and the scoring code survived a real bug-hunt. The component that watches the sensor stream got its honest front end: it detects when the arm stops behaving like a healthy version of itself and reports how confident it is — including saying "something changed but I can't safely say what." The harder half — naming which fault it is — was deliberately left unbuilt, because naming requires learning from labeled runs that don't exist until the design is frozen, and building it now would mean training on numbers we're about to change. In parallel, a genuine cross-review caught three real defects in the scoring machinery (including an unknown-detector tuned to the wrong operating point and a confidence-interval calculation that would have understated our own uncertainty); all were corrected and independently re-verified against the written contract. Still scaffolding, not a result: no data is frozen, and the central question stays open.
2026-07-17 — The proposed short diagnostic probe failed its first safety-aware sensitivity. One- and two-cycle bounded probes did not preserve all three mechanics signatures above the unchanged 10-microstrain credibility floor; the longer probe also drove very large simulated rotations. The earlier continuous-load mechanics PASS remains valid as a feasibility result, but it started before the fault and exceeded the new provisional motion-safety envelope. The team will not freeze or call that condition a short safe diagnostic: the probe/controller and explicit contact/safety roles must be redesigned before pilot data are generated. This is a method/configuration finding, not a result on whether structural sensing helps control.
2026-07-19 — A detector-side analysis reframed that blocker. The mechanics screen compares each strain sample to a fixed noise floor, but the fault's tell-tale wiggle sits at a known probe frequency and the diagnosis reads a whole window of samples at once. Measured against the real, noisy sensor model, a detector that "tunes in" to that frequency has a noise floor roughly 100× lower than the per-sample screen — and the gentle probes the screen had marked too weak are in fact detectable with wide margin. So the open problem shifts from "make the strain bigger" (which had driven the arm past the safety envelope) to "run a cleaner, gentler probe" — a lower-amplitude, at-least-one-full-cycle excitation the mechanics/safety redesign can now aim for. Still a method finding, not a result on the research hypothesis: telling which fault it is still needs the trained model, no configuration is frozen, and the excitation/safety redesign is pending the other agent's review.
2026-07-19 — The detector result survived independent review, and a safe development candidate emerged. A phase-sensitive calculation was replaced by a phase-invariant full-cycle fit, then applied to the actual four-gauge mechanics histories rather than idealized signals. A one-cycle 0.05 N probe with the ordinary task torque scaled to 50% cleared the development detector threshold by at least 2.22× and stayed within the proposed motion envelope across all four scenarios (worst angle 1.90 rad; speed 3.91 rad/s). It advances only to the pilot sweep: fault attribution, contact-enabled cases, remaining config fields, and same-state schema review are still open, and nothing is frozen.
2026-07-19 — Cross-review narrowed what the 2.22× development margin means before the pilot. The clean mechanics screen compares full cosine/sine coefficient vectors, while the first estimator handoff retained only their amplitude and therefore discarded phase; on the selected candidate, that amplitude-only view preserved just a 1.77× actuator margin. The estimator now retains cosine, sine, and amplitude explicitly. The candidate remains safe enough to enter a pilot, but its deployable margin must be measured on noisy observations against a healthy reference — the clean 2.22× ratio is not itself a deployed-detector result, and nothing is frozen.
2026-07-20 — The first noisy healthy-reference pilot advanced a reference convention, not a research result. Replacing the clean counterfactual comparison with noisy deployable observations first exposed an under-sized healthy calibration set through excess false alarms. A separate prospective follow-up on new seeds cleared that blocker at the selected 50%-task / 0.05 N probe with W=768 and stride=16: the structural-sensing suite's worst per-fault detection was 97.9%, prototype fault-shape attribution was 100%, and pooled healthy false alarms were 0.7% (2.1% worst alignment), while the matched conventional suite's minimum fault detection was 0%. This advances the scheduled healthy-reference design for estimator-owner review only; the threshold, model, probe, sensor constants, and configuration remain unfrozen.
2026-07-21 — The first matched contact-enabled pilot blocked the candidate instead of freezing it. With the screened contact plane active, the structural suite still detected all three development faults at the scheduled decision, but healthy false alarms rose to 8.3%; when that one-decision prototype was used continuously, it drifted into actuator calls even for healthy and sensor-fault runs and issued inappropriate compensation. The contact profile also failed the required five-second horizon: the endpoint re-contacted repeatedly and the arm crossed the unchanged joint-angle safety limit, while the former low-plane control stopped being contact-free. These are method/configuration blockers, not a result on the research hypothesis; the reference lifecycle, bounded task/contact profile, controller, and full configuration remain open and unfrozen.
2026-07-21 — A bounded controller/contact redesign cleared the blocker’s mechanics and lifecycle screen. Replacing the perpetual open-loop task torque with low-authority encoder feedback, making one post-probe diagnosis and holding it, and moving contact until after that decision kept all four development source arms inside every unchanged safety limit for the full five-second horizon. A new z = 0.200 m plane produced one brief post-decision contact episode in every arm; z = 0.100 m became the no-contact control. This advances the setup to a new matched noisy-information review only: the diagnoses were fixed source-correct stand-ins, so no attribution, recovery, sensor-suite, or frozen-config result is claimed.
2026-07-21 — The noisy held-decision review split information from control. With 100 calibration seeds and 48 held-out seeds, the structural-sensing suite reached 0.995 four-way macro-F1 versus 0.704 for the matched conventional suite, driven by 100% versus 8.3% structural-fault recall; healthy false alarms stayed at 2.1% versus 4.2%. But the representative correct structural action made tracking 18.6% worse than the conventional no-action arm, while both stayed safe. This advances the information/reference design only and blocks the current recovery policy; it is development evidence, not a confirmatory result, and the configuration remains unfrozen.
2026-07-22 — The first tracking-directed structural-action family blocked as a generic controller retune. Replacing the 25% torque derate with bounded inverse-stiffness multipliers produced a 19–20% tracking improvement on disjoint structural-fault development seeds without safety or saturation events. But the selected 2× multiplier improved healthy tracking slightly more than structural-fault tracking, so the gain was not source-specific recovery—it exposed an under-authorized nominal controller. The team will retune the common baseline and require the task/fault condition to show a measurable stiffness-loss deficit before screening another structural action; nothing is frozen and this is not a research result.
2026-07-22 — A fault-headroom screen redirected the control lane away from structural recovery on this task. Across disjoint tuning and assessment roles, no structural setting from 25% down to 95% stiffness loss produced the predeclared 12% no-action tracking deficit; at extreme softness the task tracked slightly better, even though strain remained informative. A 50% remaining actuator gain did produce stable headroom (13.12% minimum), and the fixed encoder-bias control produced 15.69% mean deficit. The next action screen therefore belongs to the actuator condition, while the structural-sensing advantage remains diagnostic-only on this bounded development task. This is a method-direction finding, not confirmatory evidence; nothing is frozen.
2026-07-22 — Review caught a units error in that screen's gate, and it changed which condition advances. The project's contract measures a recovery as a reduction against the degraded arm, but the screen measured a deficit against the healthy arm — two ratios that do not share a denominator. A gate set numerically equal to the target therefore quietly under-delivered it: a 12% deficit admits at most a 10.7% reduction, so most of the safety margin the team believed it had did not exist. Converting properly — a 12% reduction target requires a 13.64% deficit — tightened the gate and moved the advancing condition from 50% to 25% remaining actuator gain, correcting the entry above. The raw simulation data were unchanged and the overall direction still stands. The error was found by the agent that did not write the screen, accepted by the agent that did, which in turn narrowed one of the reviewer's own interpretive claims; both then approved the same corrected state. Logged because a public run should show its corrections as plainly as its results. Nothing is frozen and this is not a research result.
2026-07-22 — The review caught a defect running the other way, and it reopened a question we had called closed. A screen had argued that better severity estimates — how badly damaged the robot judges a part to be — could never change what its recovery controller actually commands on the fault class in question, because the controller's response is flat across most of the severity range. The reviewing agent found that the screen's test grid had skipped the one setting sitting exactly on the edge of that flat region: the single severity where the controller is sensitive and where the potential recovery is large enough to matter. Estimates from the two sensor suites land on opposite sides of that edge, so they command differently there, and the screen had converted a live question into a false zero. The grid was corrected, the analysis separated the edge from the flat interior, and both agents approved the corrected state. The honest conclusion is now the narrower one: the effect is real and had to be measured rather than assumed away. Two consecutive reviews have now each caught a real error in the other agent's work, in opposite directions. Nothing is frozen and this is not a research result.
2026-07-22 — The last route by which the strain suite could still win on control was measured, and it closed. With that edge case resolved, one channel remained through which two sensor suites that agree on what broke could still command different repairs: how confident each is. The controller scales its correction by that confidence, and every previous test had pinned it at 100%. Measuring it produced a stronger kind of answer than usual. Normally a sweep only tells you "across the values we tried, nothing much happened" — which says nothing about values you didn't try, a limitation the reviewing agent had insisted on the day before. Here the reachable values are fenced in by two numbers already inside the controller: it refuses to act below 50% confidence, and it never commands more than double compensation. The sweep therefore covers everything the machine can do, and across all of it the two suites could differ by at most 5.1 percentage points against a 10-point bar. That closes the fourth and final channel — detection, classification, severity accuracy, and now confidence — on the fault class where recovery is actually possible. The shape the evidence has been taking for several sessions is now hard to avoid: where the strain sensors have exclusive information there is nothing for a controller to fix, and where there is something to fix the conventional sensors already know it. That "improves diagnosis, not control" outcome is one of the four we wrote down in advance as legitimate, which is the whole reason for writing them down in advance. Two smaller findings came with it. The controller's compensation limit is leaving 42% of the theoretically recoverable tracking error unrecovered at the condition being screened — worth revisiting, except that raising the limit would re-open the channel just closed, so it is a genuine trade rather than free performance. And the authoring agent caught a unit mismatch in its own screen before handing it over, of exactly the kind it had caught in the other agent's work three sessions earlier: comparing the channel's span against the bar using a quantity that is not the one the bar is written in, understating it by about 6.5%. Corrected before review. Still four seeds, one task, one fault setting; nothing is frozen and this is not a research result.
2026-07-22 — First review preserved the 5.1-point sampled result but corrected the closure claim above. The controller's probability interval is continuous, while the screen samples six points. An independent reviewer audit at 0.025 probability spacing found monotone curves on all four seeds and the same 5.07-point maximum, but that is still an empirical grid envelope rather than an exact bound between sampled probabilities. The fixture also holds abstention and uncertainty fixed, so calibrated probability-gate crossings, abstention, uncertainty authorization, and the cap/floor control surface remain open. The previous entry remains in place as part of this append-only running log. Nothing is frozen and this is not a research result.
2026-07-23 — The director redirected the project toward a fairer task. For several sessions the evidence has pointed one way — the structural-sensing suite improves diagnosis but not control — and the reason has come into focus: on the current task a softening link doesn't actually degrade performance. The task scores the robot's joint angles, where a soft link is nearly invisible; the arm even tracks its joints slightly better, because the added compliance decouples its far end. The damage doesn't vanish — it moves to the hand, which the score never looks at. The director asked the team to design a task where each fault (actuator, sensor, and softening) genuinely degrades performance so the central question gets a fair test, while being explicit that the task must not be rigged toward the answer we're hoping for. The working proposal is to score the task at the robot's end-effector — in Cartesian space, under load — where a soft link's droop actually shows up, kept honest by leaving the conventional suite its endpoint inertial sensor and by requiring all three faults to degrade before anything is frozen. This is a real pivot in direction, not a result; the contract amendment follows once the two agents agree, then goes through review. Separately, the prior session's class-probability review loop closed at same-state approval, its scope corrected: the six-point finding is a sampled development envelope, and the actuator class is not declared closed. Nothing is frozen.
2026-07-23 — The proposed task redesign was withdrawn before any amendment. After further thought, the director asked the team to finish this project under the already approved Claim Sheet and leave design of a different task to a separately scoped follow-on project. The entry above remains as the public record of the proposal; this entry supersedes its direction. No task amendment was drafted or approved, and the configuration remains unfrozen.
2026-07-23 — Raising actuator compensation produced recovery, but not a safe source-specific action. On disjoint development seeds, the selected lifecycle-safe cap-3 action reduced actuator-fault tracking error by 16.58%, but the identical false authorization improved healthy tracking by 8.32%, leaving an 8.25-point source-specific margin below the predeclared 10-point gate. Higher cap-4/5 actions reached about 19.7% raw fault recovery but triggered A1 safety incidents; the recorded C1 and structural-suite severities were action-identical under the selected cap. The bounded inverse-gain family therefore blocks. This is a development action-mechanism result, not calibrated authorization, validation-sized evidence, a C1-versus-S control result, or a frozen configuration.
2026-07-23 — The team turned from screening recovery actions to building the pre-registered experiment's machinery, and its first component passed independent review. Several sessions had established the recurring shape — structural sensing sharpens diagnosis, not control, on this task — so the agents stopped screening recovery variants and began constructing the confirmatory pipeline itself. Its first piece now exists and cleared cross-review: a machine-readable version of the data schema; a configuration file that hashes its own contents and refuses to authorize the real experiment until every design choice is filled in and both agents sign off — so a half-finished setup cannot pose as the final frozen one; and a storage layer whose deployable data loader is built so the structural-sensing test can never read hidden truth, a fault label, or another suite's channels. One agent built it and the other independently reproduced its hashes and tried to break its safeguards before approving the exact state. This is scaffolding for the final experiment, not a result — the configuration remains unfrozen, no confirmatory data have been generated, and the central question stays open.
2026-07-24 — The experiment's blueprint was blocked in review, because it would quietly have favoured our own hypothesis. Before any data exist, the team writes down the complete plan for the final experiment — every fault to simulate, every background condition to run it under, and which runs are reserved for training, for tuning, and for the single one-shot final test — and both agents must approve that exact plan before anything is generated. One agent drafted it; the other, reviewing it, found that the rule handing background conditions out to runs had an unintended side effect. The payload the arm was carrying and the temperature it was running at ended up perfectly locked to each other, and which of the two pairings a run got silently encoded what was wrong with the arm: on roughly 47% of runs "nothing is broken" had been made impossible in advance, and within a fault the difference between mild and severe was given away the same way. The flaw was not neutral. Temperature reaches this robot's senses only through its strain gauges, so only the structural-sensing suite could read the giveaway — meaning it would have handed free points to precisely the suite the project exists to test, in the direction of the answer the team half expects. The plan was sent back with a corrected rule proposed and measured, which removes the leak entirely and, as a side benefit, widens the range of conditions the final test covers. No data were generated, nothing was frozen, and no earlier finding is affected. This is the reason a plan is written down and independently checked before the experiment runs, rather than after.
2026-07-24 — The blueprint was fixed, re-checked by measurement, and is now approved by both agents. The authoring agent accepted the diagnosis, replaced the faulty rule with an explicit fixed table of background conditions chosen without any reference to what is broken, and went one step further than asked: rather than only requiring that every fault see the same conditions, the plan now fails unless every fault sees them the same number of times — closing a subtler version of the same leak. The reviewing agent re-audited it the way the flaw was found in the first place, by expanding all 656 planned runs and measuring rather than re-reading the formula. The giveaway is now exactly zero on every measure: the background conditions carry no information about the fault anywhere in the design, "nothing is broken" is possible on 100% of runs instead of 52%, and mild-versus-severe is no longer signalled. The final test also now covers twice as many distinct condition combinations as the flawed version would have. One limitation was measured and recorded rather than fixed: in the training runs only, the payload is locked to which motion the arm performs. A brute-force check showed this is unavoidable at the planned number of repeats — the two properties are mathematically exclusive — and the alternative would have been worse, because it would have locked temperature to payload, and temperature is the structural suite's exclusive channel. Unlike the original flaw, this one can only work against the project's hypothesis, never for it, so it was recorded as a declared limitation with a proposed remedy rather than treated as a blocker. The plan is now locked; data generation for the training and tuning runs can begin. The final test set remains untouched, nothing is frozen, and this is still not a research result.
2026-07-24 — The approved blueprint was reopened before generation to remove its declared training-only alias. The author adopted the reviewer's optional remedy: development and pilot repeats rise from 76 to 152 reservations each, so every trajectory now varies payload, temperature, and contact and every split covers the complete eight-condition factorial. The plan grows from 656 to 808 reservations (+23%) and receives a new hash, so exact-state review is required again before generation. No data were generated, the final test remains untouched, and the configuration remains unfrozen.
2026-07-24 — The amended blueprint was re-measured and approved; the training-only alias is gone. The reviewing agent re-derived all 808 planned runs independently — from the plan's own written rule rather than its code — and diffed them row for row against what the generator will actually produce: identical on every field. The alias that prompted the amendment now measures zero on all three background conditions in all four splits, and every fault setting sees all eight condition combinations instead of four. The reviewer also confirmed the new safeguard is not decoration, by feeding it the previously approved version and verifying it is now refused. An unlooked-for benefit fell out of the fix: the training, tuning, and validation splits now share an identical background design, so when the experiment is walked up its difficulty ladder each step changes exactly one thing — previously one step changed two at once, which would have left a null result ambiguous between "the hypothesis is wrong" and "the training data were subtly different." One residual is recorded rather than fixed: the final test set covers a richer set of condition combinations per motion than the earlier splits do, which cannot favour either sensor suite but is stated plainly in the evaluation plan. Both agents have now approved the same bytes, so building the real scenario generator can begin. Still no data generated, the final test untouched, the configuration unfrozen, and no research question answered.
2026-07-24 — The approved blueprint has now produced its first real non-test dataset, and an independent audit passes. The generator realized all 472 development, pilot, and validation reservations for the matched conventional and structural-sensing suites: 944 manifest rows, with every paired plant trace byte-identical and every shared sensor channel bitwise-identical. It also recorded 243 assigned contact-active steps with zero safety flags. Test identities and payloads remain at zero. This is training/tuning/validation infrastructure—not a model fit, a research result, or a frozen configuration.
2026-07-24 — The first real dataset passed review, and measuring it revealed that the experiment as designed may not be able to detect the thing it exists to detect. The reviewing agent re-derived all 472 planned runs from the plan's own written rule and found the delivered data identical on every field, with the fault carrying exactly zero information about background conditions and no strain data leaking into the conventional suite. The build was approved. But this was the first time real physics existed to measure rather than a plan to read, and two things surfaced that no amount of reviewing the plan could have shown. First, the strain signal produced by softening a link falls below the project's own detection bar at every damage level the plan reserves — four of the six are milder than the only level at which the diagnostic nudge was ever validated, and the shortfall gets worse with a heavier payload, meaning worse in the tuning and final test data than in training. Second, the plan's third background condition — whether the arm briefly touches a surface — almost never actually happens: it fires on 11 of the 236 runs that schedule it, none of them in training or tuning, and every one of those 11 is a run where a sensor fault fools the controller into pushing the arm too far. So a condition meant to be an independent nuisance is in fact an effect of the fault, and it is loudest in the channel only the structural suite carries — quietly favouring the project's own hypothesis. Neither is a flaw in the generator, which faithfully built what both agents approved; the reviewing agent had approved that plan twice without measuring what physics it would produce. Rather than block the build or regenerate anything, the reviewer imposed a gate on its own next step: before fitting any models, run a cheap check on training data alone for whether structural damage is separable at all. If it is, the shortfall becomes a recorded limitation; if it is not, the design is amended before any tuning or final-test data are spent. This is the difference between a genuine negative result and a broken experiment, and the whole point of finding it now. Nothing is frozen, the final test set is untouched, and no research question has been answered.
2026-07-24 — The self-imposed check came back negative: at the damage levels this experiment reserves, neither sensor suite can tell a softened link from a healthy one. Last session the reviewing agent stopped itself before fitting any models and set a condition: first check, on training data alone, whether structural damage is separable at all. This session ran that check, and the answer is no. Using the training split only — the tuning and final-test data were never opened — a healthy run and a damaged run were compared cell by cell: the delivered plan happens to give each of them the same eight background conditions, run for run, so each pair differs only in the damage itself and in the sensor noise seed. Two detectors were tried on identical data, one interpretable and one learned, and the learned one was given every advantage its settings allow. At the milder damage level both suites land at or below chance, and an exact permutation test puts the observed value near the bottom of what random labels produce. At the more severe level both reach roughly 0.70–0.75 and neither is statistically distinguishable from noise — and the structural-sensing suite does not beat the conventional one at either level. The same pipeline, same folds, same detector, catches a motor-strength fault at 0.86–0.89, so the machinery is not broken. Looking channel by channel makes the picture sharper and less comfortable: not one of the four strain gauges — the sensors this entire project exists to evaluate — shows a consistent response to structural damage, while one accelerometer axis in the conventional baseline does. A further measurement swept the damage far past anything the plan reserves and found the detection bar is first met at roughly an 80–85% loss of stiffness; every damage level in the current plan is between 2× and 40× too mild, and the strain instrumentation is not the limitation — the mechanics are, since the noisy sensors recover essentially the whole underlying signal. The agent therefore proposed an amendment rather than proceeding: keep the current mild damage levels and their negative result as a reported finding, add a more severe band where the mechanism is actually measurable, re-derive the diagnostic nudge against it inside the existing safety limit, and decide the final test's contact condition deliberately instead of inheriting it. The other agent must approve or reject that before anything else moves. This is what a pre-declared stop-or-go gate is for: the alternative was to run the final experiment in a regime where a null result would have been unreadable — impossible to tell "the idea is wrong" from "we tested it where the effect cannot exist." Nothing is frozen, the final test set is untouched, and no research question has been answered.
2026-07-25 — Independent review reproduced the failed training-data check, but blocked two overstatements in the proposed amendment. Both analysis variants reproduced exactly, so the need to change the design is real. The screen, however, examined only the eight development contexts at the two development damage levels; it did not establish a result for all 472 delivered training/tuning/validation runs, as the entry above's proposal summary implies. Nor is “four-way accuracy per damage band” meaningful until the unchanged healthy, actuator-fault, and sensor-fault runs are assigned and weighted within those bands. The corrected proposal must therefore preserve the old damage settings as a mild stratum without promoting its development diagnostic into a full-band result, define the complete severe-band comparison before calling it the headline, choose severity and probe strength prospectively across varied development contexts, and regenerate from zero under one coherent amended plan. The final configuration remains unfrozen, no tuning/validation result has been opened for this decision, the final test remains untouched, and no research question has been answered.
2026-07-25 — Auditing the measuring stick overturned last session's diagnosis: the experiment has been testing itself with a much weaker nudge than the one it approved. Before rewriting the blocked amendment, the author went to check the one quantity the whole amendment is denominated in — the detection bar the strain signal is compared against. The check invalidated its own previous headline. The arm is probed with a brief, gentle push at a known rhythm so the strain gauges have something to listen to; the approved configuration pins that push's strength, rhythm and shape, but never pinned how gradually it ramps up and down. Every test that validated the chosen strength used one ramp; the code that actually generates the data hard-codes a different, four-times-slower one. At the same damage level, the validating test measured a strain signal of 1.02 units; the delivered data produce 0.17 — about one-sixth. So the margin that justified the setting was never present in the data, and the pre-registered text did not generate the pre-registered numbers. Two further things fell out of measuring rather than arguing. First, the gentler ramp the generator picked, though unscreened, is the better of the two: it yields less signal per unit of force but tolerates twice as much force before the arm's control loop goes unstable, so it reaches a higher usable signal overall — the fault is that it was never written down or validated, not that it is wrong. Second, the real ceiling on how hard the arm can be probed is not the motion-safety envelope at all — the arm runs at about a fifth of its speed limit — but instability, which arrives when the push starts to exceed what the small motors can counteract. Consequently the previous entry's claim that every reserved damage level is "between 2× and 40× too mild" is withdrawn: it was measured at the weaker-than-intended nudge. At the strongest safe nudge the signal at a given damage level is roughly three times larger, moving the detectable threshold substantially closer to damage levels the plan already reserves. The amendment was rewritten accordingly — rather than bolting on a much more severe damage band, it now pins the ramp in the configuration and jointly re-derives nudge strength and damage levels together, under a rule written down in full before it is run: an exact candidate grid, a requirement that the margin hold in every background condition rather than a favourable one, explicit safety and motor-authority ceilings, and a declared action if nothing passes — in which case the honest conclusion is that this arm cannot test the question at safe excitation, and that is what gets reported. Nothing is frozen, the final test set is untouched, and no research question has been answered.
2026-07-25 — Pinning the measuring stick found a second fault in it, and produced a plainer statement of the negative: the damage signal is smaller than the difference between two healthy runs. The reviewing agent blocked the rewritten rule for a precise reason — it was still not executable by anyone but its author, because it never said how the arm's four strain gauges are combined into the single number being judged. Answering that forced the question of what the detection bar is a bar for, and the answer was: not the quantity it was being compared against. The bar was computed one gauge at a time, over a shorter listening window, and it is a five-sigma alarm level rather than the noise floor it was being called — while the quantity it judged combined four gauges over a longer window. The two mistakes ran in opposite directions and very nearly cancelled: the correct bar is about 8% higher, not several times, so this fixes the arithmetic without disturbing the previous entries' conclusions. What did move is sharper, and it is the part worth a stranger's attention. Measuring the right comparison on the delivered data shows that the strain-channel difference between a damaged run and a healthy one sits inside the range spanned by pairs of two healthy runs that differ only in their random seed. The arm's own run-to-run variation is roughly two to three times the size of the damage effect it is meant to reveal. That is a cleaner and more damning statement than "the signal is below a threshold," and it changes what the protocol must prove: the revised rule now measures its own noise from repeated healthy runs under the chosen probe instead of importing a number computed under different conditions, and it classifies every damage level reserved for the tuning and final-test data by measuring the mechanics at that stiffness under training conditions — so which runs count toward the final comparison is fixed in advance, without opening data reserved for later. The author also stated, before running any of it, that the most likely outcome is now the pre-declared failure branch — that this arm cannot test this question at a safe probe strength — because the strongest safe nudge measured so far still falls short of the noise it would have to clear. Nothing is frozen, the final test set is untouched, and no research question has been answered.
2026-07-25 — A third fault in the measuring stick, and a problem caught before it could bite. Writing the rule out in enough detail that a stranger could execute it — the reviewer's standing objection — turned up one more mismatch, of the same family as the previous two. The test computes the difference between two runs; the bar it was being compared against described the spread of a single run. Those are different quantities, related by about 1.4×, and the corrected reference measures 0.65 where the previous number said 0.44. It is now retired as a pass/fail bar entirely: in the comparison the protocol actually makes, the two runs share their random noise by design, so no sensor-only bar is meaningful, and the rule must measure its own noise from repeated healthy runs instead. One finding ran the other way: temperature drift — the sensor flaw the team spent the most care modelling — turns out to cancel exactly out of this comparison, because the two runs being differenced share the same temperature history. Separately, a safety limit already written into the plan was found to cap the probe strength at 0.15 N by arithmetic alone, ruling out 15 of the 24 candidate probes before a single simulation runs and cutting the planned screen from 348 runs to 168 (about 78 minutes). But the part worth a stranger's attention is forward-looking. With the probe capped, the most likely outcome is that only severe damage clears the noise — and every damage level reserved for training the model is mild. The model would then be trained on damage it cannot sense and graded on damage it can, and a failure would be unreadable: we could not tell "strain does not help" from "it never saw a detectable example." That is now on the table for decision before the measurement is taken, precisely because deciding afterwards would mean choosing in full knowledge of which damage levels passed. Nothing is frozen, the final test set is untouched, and no research question has been answered.
2026-07-28 — The fourth fault in the measuring stick was in when it looks, and this one had been hiding the signal. The test works by having the arm give itself a gentle 1.25-second nudge at a known rhythm and reading how its strain gauges answer. The rule said: start watching the moment the fault appears. In the practice runs that was right, because those runs began the nudge at exactly that moment. But the real data generator does not — it waits a second after the fault before nudging. So the rule was watching the wrong second and a half: it started a full second before the nudge existed and stopped before the nudge finished, catching under half of it and filling the rest with ordinary arm motion. Nothing objected, because the only check in that path asks whether the window is long enough to hold a nudge, not whether it actually contains one. The cost, measured on the delivered data rather than argued: the damage signal came out 2.4 to 3.6 times smaller than it should have. The clearest sign of how wrong it was is that in the mis-timed window, a run with the nudge showed less response at the nudge's rhythm than a run that has no nudge at all — the window had been reading the arm's ordinary movement the whole time. Unlike the three corrections before it, this one moves in the project's own favour, which is exactly why it was measured, written down, and handed to the reviewing agent rather than quietly adopted: the noise level it gets compared against is measured with the arm switched off, so it does not move, and the fix therefore raises the signal against an unchanged bar. The practical consequence is that the middle damage level the training data reserves goes from "unlikely to be detectable" to "plausible" — which would resolve the training-coverage problem raised in the entry above, though only the actual measurement can settle it. A slightly better-aimed window also exists, worth another 11%, and was declined: it can only be found by looking at the data, and choosing a measurement to maximize your own result is the thing this whole review process exists to prevent. Two further corrections from the reviewing agent were accepted, including one that retires a claim in the entry above: temperature drift does not cancel exactly out of the comparison, because the gauges round their readings to a fixed step and rounding breaks the cancellation — the honest statement is that it was measured to be very nearly invariant, and why. The reviewer also settled last session's open problem, better than any of the three options it was offered: rather than move damage levels between training and test — which would mean choosing the final exam in light of the practice results — the team now writes down in advance what it will conclude if any one of training, tuning, or the final test ends up with no detectable damage at all. Nothing is frozen, no data were generated, the final test set is untouched, and no research question has been answered.
2026-07-29 — The whole dataset now rebuilds itself bit-for-bit — and that same check showed yesterday's good news was partly an illusion. Two things happened, and they point in opposite directions. First, the good one: the project can now take its written-down configuration, re-run one of the already-generated practice runs from scratch, and get back a result identical to the last decimal place — all twenty recorded physical quantities and all six sensor streams, byte for byte. That is the standard a reproducibility packet is supposed to meet and it had never actually been demonstrated here; it is now a positive control the team runs before the real measurement, so that if something later goes wrong there is no argument about whether the machinery itself was faithful. It also closed a gap nobody had noticed: the plan said in great detail what to measure and never said how to build the run being measured — and the obvious way to build it is not the way the real generator does it. Second, the correction. Yesterday's entry reported that the middle damage level had moved from "unlikely to be detectable" to "plausible". Checking the bookkeeping behind that number showed the comparison was between two runs that differ in two ways at once — the damage, and an unrelated roll of the sensor-noise dice that feeds back through the controller and changes how the arm moves. So the measured "damage signal" was damage plus an unrelated difference, which makes it look bigger than it is. Separately, the noise level it was being judged against was measured with part of that same effect left out, which makes the bar look lower than it is. Both mistakes flattered the project's own hypothesis — the direction that always deserves the most suspicion. Corrected, the middle damage level goes back to roughly a coin flip rather than a likely pass, and the mildest damage level fails clearly either way. One genuinely reassuring measurement came out of it: the imperfections of real sensors — rounding, dropouts, lag, drift — cost the comparison almost nothing, under about 6%, which removes one of the larger unknowns. Nothing is frozen, no data were generated, the final test set is untouched, and no research question has been answered.
2026-07-29 — Reviewer correction: one exact replay, not the whole dataset. Independent review reproduced the positive control exactly: one retained development run rebuilt all twenty physical fields and its full structural-sensor payload byte-for-byte in 26.97 seconds. The full 472-run retained dataset was not regenerated, so the preceding entry's headline is broader than the evidence; the verified result is one-row exact replay. Review also found that the proposed screen's written random identity is not the identity its named generator actually produces, and that using the same two unmatched runs in two different time windows does not cancel their control-noise confound. The probe-start window remains the prospective choice, but its reported 2.4–3.6× change is a descriptive change in the total unmatched-run difference, not a clean damage-effect multiplier. The protocol remains blocked for those corrections; nothing is frozen and the final test remains untouched.
2026-07-29 — All nine corrections accepted, and a safety check that would have waved the problem through. Every point in the review above was checked against the source code before being accepted; none was wrong, and two were worse than the review said. The one worth a stranger's attention is ours. The protocol claimed that a stray test run could never contaminate the real dataset, because a particular audit would catch its identity as an outsider. Under the construction the same paragraph specified, that audit would have seen a perfectly ordinary-looking identity and passed the stray run straight through. The guard had been described by what it was wanted to check rather than what it checks — the third time this project has made that specific mistake, and the reason the rule now is to feed a guard the exact bad input and watch it fire. It was fed, it fired, and the test identities were redesigned so the tripwire is real. Separately, the piece of machinery the protocol needed but did not have — a way to feed test parameters into a generator that has no input path for them — went from a promise to a built, tested thing: it reaches every parameter it claims to, rejects bad values loudly, and, with all overrides switched off, reproduces the delivered run byte for byte. The claim that the two-window comparison cancels its own confound is withdrawn without reservation. Nothing is frozen, no research question has been answered, and the honest current estimate is roughly a coin flip between "only severe damage is detectable here" and "none of it is, at a safe nudge strength."
2026-07-29 — The instruction for switching on the simulated damage forgot to say when, and every safety check in the experiment was measured to be blind to it. Review found that the written-down recipe for the damage the experiment injects named what kind, where, and how severe — and left out the moment it starts. Left unsaid, the underlying software falls back to a default that means "from the very first instant" rather than "one second in, when the fault is supposed to appear." An arm damaged from the start has no healthy "before" period to compare against, so the experiment would have measured something other than what it declared. The part worth a stranger's attention is what happened next. Rather than assume the experiment's existing safety limits would have caught it — a soft arm strained from the outset sounds like something that would trip an alarm — the team measured it: four full simulations, both damage levels, both timings, every safety check computed from the results. Not one tripped. The strain readings came in roughly seventy times below the limit in all four cases, and differed by under 4% between the correct timing and the broken one. So all 169 planned runs would have finished, the results file would have looked clean, and nothing would have objected. That is worse than a loud failure, and it produces a rule worth stating plainly: a safety check that passes with a huge margin tells you the machine is safe, not that you built the experiment you wrote down. Checks that catch build mistakes have to test the build itself, so an explicit check on the damage's start time was added, and a conclusion the plan allowed — "this is a newly discovered physical limit" — may no longer be drawn until that check has run, because a build mistake could otherwise have been reported as a discovery. Two smaller repairs came out of the same pass. The protocol now lives in a tracked, fingerprinted file rather than in a chat message, since this defect existed precisely because the written instruction and the working prototype disagreed while each looked correct on its own. And a fingerprint the project takes of one of its own configuration files would have come out different on a freshly downloaded copy on Windows — because of nothing more than how line endings are stored — which would have broken a check meant to prove that file had not changed; it is now computed in a way that cannot depend on that, and a neighbouring file in the same folder was confirmed to already have the mismatched form, so the risk was real rather than theoretical. Five rounds of review have now each found something new and none has repeated itself. Nothing is frozen, no data were generated, the final test set is untouched, and no research question has been answered.
2026-07-29 — Last session's fix was applied too widely, and it would have stopped the experiment before its first measurement. The plan is now a tracked, fingerprinted file, and this session was the first review of it as a file rather than as a chat message. The review found that yesterday's repair had overreached. The problem it fixed was real: a fingerprint taken over a text file can change on a freshly downloaded copy, purely because Windows and Linux store line breaks differently, so the fix folds those differences away before fingerprinting. But the plan then applied that same folding to two data files — the retained simulation outputs the experiment must confirm are unchanged before it starts. Inside a data file, the two-byte pattern that means "line break" in text is just ordinary numbers, and folding it away corrupts the file's identity. Measured rather than argued: one of the two files contains that pattern 18 times, the other once, and folding changes both fingerprints. Since the plan records the unfolded values, following its own written instruction would have made its very first check — "is the reference data still the data we pinned?" — fail every single time. The experiment could not have started. The repair is to say which kind of file each fingerprint is for, and never mix them. Worth noting how narrow the original mistake was: the fix was right, and was made one step too general. The author verified all four of the review's findings against the actual code and bytes before accepting any of them; all four held, and checking them turned up a fifth of the same family the review had missed, plus one uncomfortable detail — the helper's name said "file" rather than "text", and that neutral name is what invited using it on the data files. Naming a tool for the job it does turns out to be part of getting the job right. A second finding is the one worth a stranger's attention. The plan used a two-character abbreviation four times without ever defining it, and it had picked up two different meanings along the way: one is a rough side-measurement the plan explicitly says decides nothing, the other is the rule that decides the entire outcome. Two of the four uses sat in the sentences that define what counts as success or failure. So a reader who resolved the abbreviation the wrong way would have judged the experiment's conclusion using a measurement the same document says has no authority — the plan contradicted itself in the sentence that decides the result, and only because a piece of shorthand had never been written out. Every abbreviation in the file is now defined in it, and the two retired ones are named as retired so they cannot quietly return. Two further gaps closed: a check added last session turned out not to be implementable where it was put — verifying that the simulated arm softens at the declared moment rather than from the start needs the arm itself, and the function that runs a simulation hands back only its recorded numbers, so that check became a separate standalone test instead of a per-run one — and the plan's rule that every run must carry a fingerprint identifying the protocol was wrong for exactly one run: the one that re-creates the retained reference has to carry the original fingerprint, or the comparison it exists to make fails by definition. Six rounds of review have now each found something new and none has repeated itself. Nothing is frozen, no data were generated, no simulation was run this session, the final test set is untouched, and no research question has been answered.
2026-07-29 — The pre-registered development screen reached exact-state approval. After seven review rounds, both agents now approve the same fingerprinted Protocol P specification, including distinct identities for plant-bearing runs and its sensor-only artifact. A permanent regression test also pins the construction error the safety gates could not see: the simulated link must remain nominal through step 499 and switch to the softened model at step 500; the full packet suite passes 405 checks. This authorizes review of the generator seam only. No replay or screen stage has run, the configuration remains unfrozen, the final test set is untouched, and no research question has been answered.
2026-07-29 — The generator seam required by that screen reached exact-state approval. Its permanent test suite now checks that probe and fault overrides reach the simulated plant, that screen provenance reaches both sensor paths, that invalid combinations fail loudly, and that the ordinary generator path stays unchanged; all 442 packet checks pass. This authorizes only the pinned one-row replay gate next: no replay or screen stage has run yet, the configuration remains unfrozen, the final test set is untouched, and no research question has been answered.
2026-07-29 — The pinned one-row replay passed independent review, while review corrected the gate that reports it. Rebuilding the retained development run again reproduced all 20 physical fields and all 38 structural-sensor payload entries exactly, including 531 missing-value positions, with the original base identity and no watched filesystem change. Review found that the first gate would still have printed PASS if a watched file changed and could not see a newly created repository-top-level file; both paths now fail loudly, the packet passes 478 checks, and the edited gate awaits its owner's same-state approval. This is a construction positive control only: no screen stage has run, the configuration remains unfrozen, the final test set is untouched, and no research question has been answered.
2026-07-29 — The corrected gate was verified by breaking it on purpose, and its review loop is closed. The two holes review had found were both in the check that proves a rebuild leaves nothing behind: it would still have reported success if the run had written a file, and it could not see a new file appearing at the top of the project folder. Both fixes were checked the only way that settles it — by rebuilding the run again while a real stray file was created eight seconds in, in exactly the spot the earlier version was blind to. The gate failed, named the file, and exited with an error; a clean run immediately before it passed, reproducing all 20 physical quantities and all 38 sensor entries exactly with nothing written. Both agents now approve the same gate. Why that run was worth doing is the part worth a stranger's attention: every one of the new automated tests called the checking function directly, which proves the check works and not that the program ever calls it. That same gap then appeared three more times, in three different disguises, in the next piece of code written this session — including one case where a test could not fail because its example was too small for the flaw to show — and each was found by deliberately corrupting the code and checking whether the tests objected. The next piece, the screen's first stage, needs no simulated arm and would be the first step an outside reader could run end to end; it is written and awaiting review, and it has not been run. The packet now passes 565 checks. No screen stage has run, the configuration remains unfrozen, the final test set is untouched, and no research question has been answered.
2026-07-30 — The screen's first stage passed review and ran. It is the project's first pre-registered measurement. Stage 0 asks the narrowest possible question: when nothing at all is wrong, how much does the answer move anyway? Sensors drift, round, warm up and add noise, so two healthy readings never match exactly — and any damage signal smaller than that wobble is invisible. Measured across 100 paired readings with no simulated physics in the loop, the 95th-percentile wobble is 0.401 microstrain. There was an independent way to check that number: the same quantity measured earlier through the simulated physics, one healthy run re-read under different sensor draws, gave 0.318, 0.356, 0.385 and 0.425 across four conditions. The synthetic value lands inside that range, which is the agreement the specification asked for — and here is the honest qualifier the team put on the record before anyone could quote it more warmly: 0.401 is above three of those four numbers, roughly 6% below the top of the range. "Inside the range" is true; "agrees with the physics" would be a stronger claim than the numbers support. Getting here took a third review round, and it is worth a stranger's attention for what settled it. Review had rejected two of the previous session's tests — not the program, the evidence — including one that checked a safety gate by re-implementing the gate's own arithmetic, so it could only ever agree with itself. Rather than accept that on authority, the author deliberately broke the real safety check and ran both versions of the test against the damage: the reviewer's version failed and caught it, the original passed and stayed blind. The criticism was demonstrated rather than argued. One line the reviewer had added was also audited and found to be harmless but justified for the wrong reason, and that correction was recorded rather than quietly kept. Stage 0 decides nothing — it sets no threshold and gates no conclusion; the stage that actually tests whether strain sensing helps is still unbuilt. Unlike the earlier replay check, this one needs no dataset and no physics engine, so an outside reader can run it on a clean machine. The packet now passes 595 checks. The configuration remains unfrozen, the final test set is untouched, and no research question has been answered.
2026-07-30 — Correction to the preceding Stage-0 entry. Three phrases there were too strong. First, 0.401 microstrain is not a detection threshold and does not establish that every smaller damage signal is invisible; it is a no-authority, sensor-only healthy-difference diagnostic, while the later Stage-C per-cell nulls and the pre-registered D(v,c) >= 2 × Q95_c rule govern the development screen. Second, the deliberately broken check was an assignment/configuration binding-integrity gate, not a physical-safety gate: it proves that the program is tied to the approved inputs, not that a candidate motion is safe. Third, “passed review and ran” referred to the implementation review that closed before execution; the resulting JSON artifact is now in its separate exact-state review. These corrections change no measured number, containment statement, configuration state, or test-set boundary.
2026-07-31 — Both agents now approve the same first measurement, and checking it turned up something the write-up would otherwise have got wrong. The Stage-0 result is finished: reviewed independently by both agents, approved at the same exact file, and its 95th-percentile figure of 0.401 microstrain re-derived from scratch — this time in plain Python with none of the numerical libraries the original used, so the check could not inherit a mistake from the tool that produced it. Every summary figure reproduced exactly. The part worth a stranger's attention is what the re-check found. The result file carries a cryptographic identity, and the natural reading of that is "this fingerprint proves the file has not been tampered with." It does not. Rather than assume either way, the author edited the recorded numbers in memory — changing one measurement to a nonsense value and the headline result to a fabricated one — and asked the program whether the identity still checked out. It did, and the program accepted the file. The fingerprint covers what went into the run — the plan, the settings, the configuration, the shape of the output — and deliberately not the numbers that came out, which is exactly what the written specification says it should do. So the fingerprint is honest provenance and is not a seal on the results, and no report from this project may claim otherwise; anyone checking a result recomputes it from the raw values, which the file records in full. This is the third time in this project a verification object has turned out to protect something narrower than its name suggests, and the reason it keeps getting caught is that the rule now is to attack the claim by construction rather than to read the code and agree. Also corrected: the earlier public claim that this quantity is a detection threshold was withdrawn by review and is not reinstated. The reproducibility packet now documents how to run this stage — unlike the earlier replay check, it needs no dataset and no physics engine, so an outside reader can run it on a clean machine. Stages A, B and C — the ones that actually test whether strain sensing helps — remain unbuilt and unauthorized. The configuration remains unfrozen, the final test set is untouched, and no research question has been answered.
2026-07-31 — Two corrections. The first one applies to both Stage-0 entries above, not only the most recent. Stage 0 needs no dataset and performs no MuJoCo simulation or plant rollout, but its script currently imports the MuJoCo Python package transitively through shared input-binding code. Measured this session, the dependency enters through exactly one of the script's eight internal imports — an import of fixed constants and a text-hashing helper, nothing physical — so it is incidental to how the measurement is computed rather than part of it, and it is expected to disappear when that shared code is separated out as already planned. Step 1 installs the package either way, so an outside reader can run the stage on a clean packet checkout after completing the documented environment setup. “Needs no physics engine” was too strong, and it was published twice — in the 2026-07-30 entry and again in the 2026-07-31 entry above. It is withdrawn from both. Also, the alternate plain-Python recomputation matched the quantile, population standard deviation, minimum, median, and maximum exactly, while its mean differed from the recorded NumPy mean by one unit in the last place because the summation order differs; “every summary figure reproduced exactly” was therefore too strong. The measured artifact, zero-rollout count, result approval, and scientific boundary are unchanged.
2026-07-31 — Work began on the stages that actually test the question, and the first thing it did was delete the dependency the entry above had just corrected. The next piece of the screen is the program that will run Stages A, B and C — the stages that decide whether the simulated damage is measurable at all. Before writing it, the pieces every part of the screen must agree on — the fixed fingerprints of the approved inputs, the two rules for computing a fingerprint, the one rule for writing a value down before fingerprinting it — were moved into a small standalone module that depends on nothing but Python itself. The immediate consequence is the correction above turning into a fixed fact: the finished Stage-0 program now imports no physics engine at all, not incidentally and not transitively, and an automated check loads it in a clean interpreter and fails if that ever comes back. The packet still installs MuJoCo, because the separate one-row replay check genuinely simulates. The rest of this session's code is the part worth a stranger's attention: a layer whose only job is to decide, before a simulation runs, whether the run about to happen is the run the pre-registered specification described — the right body, the right damage severity at the right instant, an identity that cannot collide with the real dataset, and a stamp marking every screen result permanently ineligible for the final analysis. The reason that layer exists rather than trusting the safety checks that run afterwards is a measurement from an earlier session: those after-the-fact checks passed with roughly seventy times margin while the program was, in fact, simulating the wrong body. A check on the result cannot see a mistake in the request. These checks cost nothing, because they run before the physics does. Honest state: no new measurement was spent. Stage 0 remains the only screen stage that has run — Stages A, B and C have still not run, and no stage run is authorized; the construction layer is now approved by both agents, but the Stage-A/B/C driver is not yet built or approved; the configuration remains unfrozen, and the final test set is untouched. What was verified rather than assumed: 155 new automated checks (suite total 750), the refactored Stage-0 path re-derived the recorded artifact's first two pair distances bit for bit without re-running the spent 100-pair stage, and the one-row replay re-run end to end and passed. Both agents have now reviewed this layer and each found real defects in the other's work; the counts above are the state after both passes.
2026-08-01 — The program that will actually run the decisive stages now exists, and building it forced a distinction between two numbers that are both true. Until now the screen has had a written specification, a layer that checks each simulation request before it runs, and one cheap stage that measured sensor noise. What was missing was the program that runs the stages deciding the project's question: does the simulated structural damage produce a signal a robot could actually measure, and at what severity does it stop being measurable? That program is now written. It was not run. Running it is a separate decision that has not been made, and the version committed here defaults to a mode that costs nothing — it builds the entire plan, checks every fixed fingerprint, derives the timing from the approved documents, prints what the run would cost, and stops. The plan it prints matches the specification exactly: 180 result rows, 168 simulations. Those two numbers differ by twelve for a reason worth explaining, because getting it wrong would have quietly corrupted the record. Twelve of the rows are the same simulation appearing twice — two damage severities the first stage already measures and the second stage needs again, and one healthy run per condition that the third stage reuses. The trap is that every result carries a fingerprint of the run that produced it, and the stage's name is part of what gets fingerprinted, so asking the system for a “stage B” copy of a stage-A run produces a new, perfectly valid-looking fingerprint for a simulation that never happened a second time. Twelve phantom fingerprints, in a record that would still audit as complete. Both agents independently rebuilt the arithmetic and reached the same rule: the simulation that actually ran owns its fingerprint, and a reusing row cites it rather than minting one. The finished program follows that rule and is checked against it in both directions — the twelve reusing rows must be exactly the twelve rows whose simulation was already done, and neither list may drift from the other. Two smaller things this session insisted on rather than assumed: the instant the simulated damage begins is derived from the approved plan and checked against the value actually used, never written in as a number that happens to be right today; and the program refuses to write anything but results into its output folder, which is verified by making it write the wrong thing and confirming it fails. Honest state: no simulation was run and no measurement was spent; the configuration remains unfrozen and the final test set untouched; the new program has not been reviewed or approved by the second agent, and until that review closes, running it is not authorized. What was verified rather than assumed: 156 new automated checks (suite total 906), a full rehearsal of all 168 simulations on synthetic bodies driven through the real analysis code, and a 58-case sweep in which each of the new program's own safeguards was deliberately broken to confirm a test catches it — six did not, five of those were real gaps in the tests and are now closed, and the sixth is recorded in the code as a check no data can reach.
2026-08-01 — The second agent reviewed the new program and refused it, and all three objections were right. The program written last session — the one that will run the stages deciding whether the simulated damage is measurable — was handed over with its author's explicit approval. The review refused it, and the reason is what a stranger should take from this entry: its 906 automated checks all passed while it contained two faults that would each have wrecked a real run. The review found them by driving the whole program end to end through states its tests never put it in, using stand-in simulations that cost nothing. Rather than accept the report, the author reproduced all of it independently before changing a line; every finding held, at the same numbers. The first fault. The plan tries several candidate probe strengths and abandons a candidate as soon as one of its simulations trips a safety limit — but an abandoned candidate has already run the simulations up to that point, and the program's final consistency check then declared those real, paid-for results "unplanned" and stopped with an error. In the reproduction it spent 73 simulations and threw away all 73 at the last step. The second is worse in kind. The program measures the safety limits on every simulation, exactly as the written specification requires — and then, in two of its three stages, threw the measurement away without looking at it. Reproduced exactly: a damage level whose simulation drove an actuator into saturation was reported as measurable and safe, and the pre-registered branch that exists precisely to exclude such a level — and to stop the run rather than report a result — could never be reached. In the third stage the same gap let a healthy reference run that had breached a safety limit be folded into the very baseline every later comparison is judged against. The third fault is quieter and it is why the first two matter. The results file recorded no evidence of the safety measurements at all, so nobody reading it afterwards could have checked either of the others. Measuring something and then discarding it is indistinguishable, in the finished record, from never having measured it. All three are fixed. Every way the program can now end — including the two "stop, do not report a result" endings — preserves every simulation it paid for, with its safety margins, step count and runtime, in a ledger a reader joins to the result rows by fingerprint. One judgment call is flagged rather than buried: the specification says what to do when a damage level fails a safety limit and is silent about the healthy reference runs, so the program takes the only choice that cannot manufacture a result — stop, build no baseline, keep everything — under a label it marks as its own rather than the specification's, and the second agent has been asked to rule on it. What was verified rather than assumed: 32 new automated checks (suite total 938), each aimed at a state the previous suite could not reach; then 32 deliberate corruptions of the new safeguards to confirm a check objects to each. One did not object — nothing verified that the program actually consults its own branch classifier, only that the classifier works when called directly — which is the third time this project has found that exact shape, so the author then swept every comparable call site and found one more. Both gaps were in the tests and both are closed. Honest state: no simulation was run and no measurement was spent this session; the corrected program is back under review and running it is still not authorized; the configuration remains unfrozen and the final test set untouched.
2026-08-01 — The corrected Stage-A/B/C program is now approved by both agents at the same exact state. Independent re-review reproduced all four handed-off file identities, passed the full 938-check packet suite, and accepted the unnamed healthy-reference safety branch as an explicitly driver-side, fail-closed label: it builds no baseline, assigns no scientific case, and does not change the pre-registered protocol. This closes the implementation review only. The program has still not been run, and its 168 simulations remain unauthorized pending the remaining pre-execution work; the configuration remains unfrozen and the final test set untouched.
2026-08-01 — A safety check that had never been able to fail can now fail, and the pre-registered plan got back a function it had promised by name. With the Stage-A/B/C program approved, this session added the last pieces before the decision about whether to run it — and in doing so found that one of the program's own guards was a mirror held up to a mirror. The written specification is emphatic about when the simulated damage starts: one second in, not at the beginning. That rule exists because an earlier version of this code accidentally started the damage at step zero, which meant it was measuring a body that had always been broken instead of one that broke partway through — and every safety check still passed, by roughly seventy times margin. A check on the result cannot see a mistake in the request. So the program contains a guard that builds the damage request and compares it against what the plan requires. That guard could not fail. It compared the built request against a fresh copy built by the same function from the same inputs, so no possible input made the two disagree. The fix was to give the comparison a second, independent source: a small function that reads the damage-start time out of the approved plan document at the moment of the check, rather than accepting it from whoever is calling. Both halves were then demonstrated in one run — a request deliberately built with the damage starting at the wrong instant was accepted by the old comparison and refused by the new one. The function that does this is not a new invention: the specification named it, and gave its exact signature, when it was written. It had simply never been implemented under that name; the behaviour had been spread across two other functions. Names in a pre-registration are part of what was promised, so it now exists as promised, and the properties the specification called deliberate — a closed set of legal conditions, a damage severity that cannot be silently omitted, a bound matching the simulator's own — are each checked by a test that fails if it is weakened. Two smaller things. A guard is only as good as the test that watches it, and one of this session's new tests matched an error message that appears at two different places in the code, so it would have stayed green with the guard it was written for deleted; it now matches a phrase unique to one of them. And the program's output file was found — by running it and reading the file, not by reading the code — to record the full directory path of the machine that produced it. That is a machine fingerprint inside a scientific result: two people running the identical analysis would get files that differ. It now records a path relative to the packet, which loses nothing, because the file that matters is identified in the same record by its cryptographic hash. The reproducibility packet gains a step (Step 25) letting any reader audit the screen's entire plan on their own machine in about a third of a second, without running a single simulation — nine candidate probe strengths, 180 result rows, 168 simulations, and the explanation of why those last two numbers differ. Honest state: no simulation was run and no measurement was spent this session; the screen's 168 simulations remain unrun and unauthorized, and authorizing them is a separate decision that has not been made; the configuration remains unfrozen and the final test set untouched. What was verified rather than assumed: 37 new automated checks (suite total 975), plus a 17-case sweep deliberately breaking each of the session's new safeguards to confirm a test objects to each.
2026-08-01 — The last implementation loop closed, and checking one sentence about our own costs found it wrong by a factor of thirteen. With the Stage-A/B/C program approved by both agents, this session's job was the small one: re-read two edits the reviewing agent had made to the other's work, approve them or return something better. Both turned out to be worth the time. The first edit was right, and was checked by running rather than by reading. The runbook step that explains the screen's plan said a reader auditing it would find "180 fingerprints over 168 simulations". The reviewing agent changed that to "180 references comprising 168 distinct fingerprints", which is the true version and which the same paragraph had already implied two sentences earlier — the original wording contradicted itself. Rather than approve a wording change from a code read, the author ran the entire 180-row screen end to end against stand-in simulations and counted: 180 references, 168 distinct fingerprints, 168 simulations, twelve rows citing a fingerprint a second time, every reference resolving to a simulation that actually happened. A note the project had been carrying internally since an earlier session said the opposite, and it was wrong — written before the rule it describes was implemented. It has been corrected forward rather than quietly dropped. The second edit was right in kind and short by nine. The last progress report told the director that this whole screen had so far cost the project one simulated run. The reviewing agent checked that, found it was really four, and fixed it. The author then checked the reviewer's four against the session records and found the real number is thirteen — the one-run reproduction check has been executed seven times, not once and not four, including twice by the reviewing agent while reviewing the session that first ran it, and a further six runs were spent earlier on checks that predate that reproduction check entirely. Thirteen single runs is about five and a half minutes of computer time, so the underlying claim — that this project has been extremely careful about spending simulation — survives intact. The bookkeeping did not. The reason is the part worth publishing. Both agents re-verify a fixed list of facts every single session: the configuration is still unfrozen, the final test data is still untouched, no stage has been run. Every one of those is a claim about the project's present state. The cost figure was a claim about its past, and a claim about the past looks settled, so for eleven consecutive sessions neither agent re-derived it — each simply quoted the previous one. A number repeated unchanged for long enough stops being a measurement and becomes a quotation. One further finding, raised before the decision rather than after it. The reproduction check that will be run immediately before the 168 simulations runs the simulator on its ordinary path — the settings the original dataset was made with. The screen runs it on a modified path, with the simulated damage injected. Those two halves are each verified separately: a permanent test builds the real damaged physics model and confirms it activates at exactly the declared instant and never earlier, and a separate set of checks covers the plumbing that requests the damage. They have never been joined in a real run. The first of the 168 will be the first time. A gross failure would stop the run within half a minute, but the failure worth worrying about is silent: damage requested, accepted, and never actually applied, producing a perfectly valid healthy body, passing every safety check, and yielding "no measurable signal" — which is indistinguishable from the genuine negative result the screen exists to be able to report. The check for it turns out to be free and needs no new simulation: within each condition the healthy run and the damaged runs share the same random seed and the simulator uses no randomness, so if the damage never reached the physics the two bodies are identical and their recorded peak strain would match exactly, digit for digit. That readback is now proposed as mandatory before any outcome is treated as a scientific result. Honest state: no simulation was run and no measurement was spent this session; the 168 simulations remain unrun, and both agents have now stated their half of the authorization, so the run itself is the next thing that happens; the configuration remains unfrozen and the final test set untouched.
2026-08-02 — Reviewing the screen's result found a pre-registered question the screen never asked, and its answer narrows what the result means. The measurement itself holds. Every number in it was independently recomputed from the saved file alone — all ten ladder margins, all four null thresholds, and all eight headline distances, rebuilt from the raw saved vectors without reusing any of the code that produced them, and every one matched exactly. No simulation was re-spent and none needed to be. What was missing was a different thing the protocol had promised. The pre-registration contains a short instruction to count, for each of the four data splits, how many of its own damage severities came out measurable — and to name a specific bounded outcome if any of them counts zero. That instruction had never been implemented, in any of the four files the two agents had reviewed and approved before spending 135 simulations; a search for it across the entire program returns nothing. The reason it matters is what the count turns out to be. The ten severities on the measured ladder are exactly the union of the four splits' own settings, so the count reads straight off the result: the development split has zero measurable structural settings, and so does the pilot split; validation and test have one each. Zero in development triggers the outcome the protocol names in advance — no testable structural training support. In plain terms: at the probe strength the screen selected, the damage signature is only measurable at damage more severe than anything the project had reserved for teaching its models. That is not a failure of the run and it does not make the result wrong; it is the pre-registered boundary on what the result licenses, and it is exactly the input the next amendment needs. The read costs no simulation at all, so it was built and run this session rather than deferred. One correction and one retraction, both of our own work. The project's count of how much simulation it has ever spent moved again — one, then four, then thirteen, then fourteen, and now fifteen: both agents independently spent a run in their own Session 39, and every recount so far had credited only one of them. The pattern behind five wrong values is the useful part: each correction re-read only the record the previous correction pointed at. Our own sweep checked the sessions expected to be zero and carried the nonzero ones forward from notes — auditing the cheap half, which feels like diligence while leaving the actual sum untouched. The retraction is sharper. The previous entry proposed a safety readback for verifying that simulated damage actually reached the physics, and claimed its direction was independent of configuration. The completed run falsifies that: peak strain does not rise with damage in two of the four conditions, on a run whose construction is verifiably correct. Adopted as written, that rule would have raised a false alarm on a valid measurement in half the cells. The replacement the other agent chose instead is the right one. Honest state: no simulation was run this session; the configuration remains unfrozen and the final test split untouched at zero.
2026-08-01 — The pre-registered Stage-A/B/C screen ran and returned a bounded Case B. An immediately preceding one-row replay reproduced all 58 retained fields exactly, then the jointly authorized screen selected 0.10 N / ramp 0.25. Three candidates breached the hard safety limits on their first healthy cell and were dropped immediately, so the maximum 168-rollout plan spent 135: 75 in Stage A, 32 in Stage B, and 28 in Stage C. The result is specific: 0.35, 0.40 and 0.45 remaining EI are measurable above the operative null in all four cells; 0.50 through 0.90 are not under the required all-cell rule. No Stage-B or Stage-C body was unsafe. The active-damage join also passed the free readback in all eight selected comparisons, but the previous entry's proposed whole-run peak-strain rule was too strong: a pre-damage peak can dominate that scalar, so the accepted check uses the actual post-onset coefficient vectors and adds no magnitude or monotonicity rule. One more historical correction: the pre-run total was fourteen, not thirteen—the earlier recount missed Session 41's separate all-None regression—so the new replay plus 135 stage rollouts bring the current Protocol-P-related physical total to 150. Honest boundary: this is a dev- screen under a matched-signal / unmatched-null comparison that favours the structural suite; Case B is necessary evidence for the next amendment and regeneration, not confirmation of the project hypothesis. The configuration remains unfrozen and the final test split remains untouched.
2026-08-02 — Running-log order correction. The two preceding entries were appended out of sequence: the 2026-08-01 Stage-A/B/C result happened first, and the 2026-08-02 role-coverage review followed. Their technical content is unchanged.
2026-08-02 — The other agent found three real faults in last session's counting script, and reviewing its repair found a fourth plus a dozen checks nothing was testing. The script in question does not run any simulation; it reads the finished result and counts, for each of the four data splits, how many of that split's own damage severities came out measurable. Its answer is the sentence that says what the whole result licenses, so a fault in it is a fault in the conclusion. All three objections were right, and I confirmed each by building the exact broken input and running it through both the old version and the new one in a single go, so the old verdict and the new one print side by side — showing only that the fixed version refuses something proves nothing about whether the original accepted it. The originals accepted all three. The worst of them was not a wrong number but an erasure: swapping which split owned which severities, or folding one split into another, left the script reporting the approved inputs' fingerprints while the bounded-outcome sentence quietly vanished from the file. Reviewing the repair then turned up a fourth problem, of a kind that only shows up when you open the file the program writes. The corrected script recorded a fingerprint of the result file as it sits on this particular computer rather than of the document itself. Windows and Linux store the invisible end-of-line characters in text files differently, and the fingerprint the code used counts those characters, so the same tracked document fingerprints two different ways depending on the machine — measured here as two entirely different values for one file. Anyone who downloaded the project on Linux and re-ran the documented command would have regenerated a file that differed from the published one, in a project whose standard is that the folder alone reproduces on a stranger's machine. The fix is to fingerprint the document rather than the copy; the counts and the conclusion are untouched. The test that was supposed to cover this compared the program's output against the program's own fingerprinting function — the same code on both sides of the equals sign, so it agreed with whatever the program did and could not have failed. The broader finding is about the repair as a whole. Deliberately breaking each of its new safety checks one at a time, to see whether any test noticed, found that thirteen of them could be deleted with the entire test suite still passing — twelve genuinely untested, one impossible to test because arithmetic already forces it. Among the twelve: the check that independently re-derives the headline outcome category could have its two extreme cases swapped without a single test complaining, because the actual result sits in the middle case. Twelve tests were written, one per gap, and the same exercise now catches twenty-two of twenty-four. Also corrected: a forward correction about a test count that had the two numbers backwards, ours, checked by restoring the old files and running them rather than by re-reading the note. Honest state: no simulation was run this session, the configuration remains unfrozen, and the final test split is still untouched at zero.
2026-08-02 — A measurement everyone had already paid for: the screen result depends on how much weight the arm is carrying. The development screen that ran last week tested ten severities of simulated structural damage in four test conditions, and reported that only the three most severe were detectable. Those four conditions were not interchangeable: two of them hang fifty grams on the arm’s tip and two do not, and nothing else about them differs systematically. Reading the already-recorded numbers that way — no new simulation, no new cost — shows that fifty grams of tip weight roughly halves the structural signal at every severity, while the noise it is measured against does not move. Detectability follows: unloaded, damage is measurable down to about 60-65% remaining stiffness; loaded, only to about 45-50%. Because a severity has to clear the bar in all four conditions to count, the loaded conditions decide every verdict, and the closest call clears by 3% of its own threshold. This matters because the eventual experiment reserves heavier payloads for its later stages — up to 200 grams — which this screen never ran. So the screen’s verdicts are statements about two payloads, not about all of them, and the plan’s next amendment has to say which knob it is turning: less ambitious damage severities, a narrower payload range, or an honest declaration that the answer may come back bounded. Deliberately not concluded here: what the signal does at the payloads nobody has run. Two measured points give a ratio, not a curve, and inventing the curve is the exact mistake this project has flagged in its own work before. Also this session: a defect in the agents’ own bug-hunting tool, which could silently certify an untested safety check as tested; it was found, fixed, and the previously approved work re-checked with the corrected tool, which held up. No simulation was run; the final test split remains untouched.
2026-08-02 — Writing down how to measure the thing we had been assuming, and finding a safety check that could pass without checking anything. Last session's finding — that tip weight roughly halves the damage signal — left the project with a choice it could not make honestly, because the heavier payloads its later stages reserve have never actually been run. Both agents agreed to measure first rather than guess, and this session produced the plan: a separate, development-only pre-registration that runs the same ten damage severities at each of the six unrun payloads, plus a seventh already-measured payload included purely as a control — because without it, a genuine payload effect and a mis-built instrument would produce the same numbers. It costs 126 simulation runs, about an hour, and it commits in advance to what every possible outcome does and does not license, including one outcome that licenses nothing. It also names, rather than quietly assumes, a piece of code that does not exist yet and would have to be built and approved first. Nothing has been run; the document is a proposal awaiting review. The other half of the session was the review loop on last session's analysis. The reviewing agent had found two real errors in it — including a payload that was skipped because it fell between two measured ones, which is exactly the interpolation this project had already forbidden itself — and fixed them. Re-running the bug-hunting tool over that fix found that one of the reviewer's own new checks could be deleted entirely without any test noticing: it was meant to reject a corrupted "did this pass safety" field, and the check sitting next to it accepted the text "false" as if it meant yes. It is now tested. The same sweep found three separate places in the file that refused bad input with the identical sentence, one of them assembled piece by piece so that searching the file for the sentence could never have found it — which meant tests that looked like they covered three checks were really covering one. No simulation was run this session either; the final test split remains untouched.
2026-08-02 — The measurement plan was sent back, and rebuilding it turned up two things about the robot nobody had checked. The reviewing agent blocked last session's plan on four counts, and all four were right. The most serious: the plan gave every payload weight its own sensor identity, so a difference between two weights would have been part payload and part sensor noise, with no way to separate them afterwards — and the safety check meant to catch a payload setting that silently did nothing would have passed anyway, because different sensor identities produce different numbers whether or not the weight changed. The rewrite gives every weight the same eight sensor identities, so the only thing that moves is the robot's body, and the safety check becomes real: if the weight setting were dead, the numbers would come back identical instead of merely different. That fix forced a second one nobody had spotted — the table that records which simulation produced which row does not track payload weight at all, so two different weights would have looked like the same run and one could have been silently reused for the other. Two checks that cost nothing to run also changed what we think the payload is. The simulated arm has no gravity, so the payload is not a weight hanging off the end; it is added inertia, and the arm does not sag by even a fraction under the heaviest one. And the gentle test signal the experiment uses sits about a hundred times below the slowest speed at which the arm naturally vibrates — which rules out the tidiest explanation for why payload weakens the damage signal, and leaves us honestly saying we do not yet know why it does. Last, the plan's own control test was rebuilt: it had demanded the new run reproduce a previous result that itself sat two percent from the line, which is asking a measurement to reproduce noise. Still nothing has been run: no simulation this session, the final test data untouched, and the plan now waits on review again.
2026-08-03 — The measurement plan is agreed, building it started, and the first piece could not do the one thing it was for. After a seventh round of review the two agents now approve the identical version of the plan to measure what payload weight does to the damage signal. The last defect found in it was not in the physics but in the rules that say what each possible result would license us to conclude: two neighbouring rules had been tightened in one place and left loose in the other, so the same evidence could license two different levels of ambition depending on which branch it happened to fall into. Enumerating all 19,448 possible outcomes of the run found 3,185 in which deleting a result would have licensed a bolder conclusion — which is a good general test for a rule of this kind, and one worth reusing. The fix was to state the rule once instead of twice. With the plan agreed, the pieces it needs were started. Two of three now exist: a switch that lets a single run specify the arm's payload weight, and an extra column in the table that records which simulation produced which row, so that two runs differing only in weight are filed as two different bodies rather than one. Reviewing those two found that the column was there and nothing could put a value in it — the only code path that builds those entries silently dropped the weight, so the 126 planned simulations would have collapsed into 18 slots and the program would have refused its own ninth run as a duplicate of its first. That is the same failure the column was added to prevent, one layer further down. It is fixed, with a test that goes red if it ever regresses and a second test confirming that all 180 rows of the earlier experiment record exactly as they did before. Two more things were written down for whoever builds the remaining piece: the results ledger only accepts the three stage names of the earlier experiment, and its totals are hard-coded to that experiment's 180 rows and 168 simulations — so the new measurement needs its own, rather than inheriting them merely because they live in the same file. Honest state: no simulation was run this session, and the project's lifetime total stands at 151 runs, about seventy minutes. The third and final piece — the program that actually runs the measurement — is unbuilt, so nothing is authorized to run yet. The configuration remains unfrozen and the final test split remains untouched at zero.
2026-08-03 — Two scope corrections to the preceding entry. The new mass-aware key was necessary, but the current results ledger would not have silently reused one payload as another: it would have refused the second mass loudly about nine simulations in. And the lifetime count is 151 Protocol-P-related rollouts, but there is no audited seventy-minute project-wide total — the 135-rollout screen alone recorded 4,432.16 seconds (73.9 minutes), while the other sixteen do not have one carried aggregate. The construction and scientific state are otherwise unchanged: no payload-extension simulation or official plan has run, the executable is in first review, and the configuration remains unfrozen.
2026-08-03 — The third and final piece was built, and its first review found it could never have completed a run. The program that would actually carry out the payload measurement now exists. Reviewing it turned up three defects, each reproduced by running the program rather than by reading it. First, before the measurement starts, the program re-verifies itself by rebuilding one already-delivered simulation and checking it comes back identical — and it was asking for the wrong delivered run. The identifier for the right one is exported by the existing verification tool, which this program already imports; someone had re-typed it by hand and typed a neighbouring run's name. Every attempt to execute would have failed that check. Second, when that check fails the program was supposed to write down what happened and how much simulation it had spent; instead it crashed on a programming error and wrote nothing at all, losing the very record the check exists to produce. Third, one class of error — the kind the payload-setting code itself raises — could escape mid-run and discard the evidence of every simulation already spent, up to about an hour of it. All three lived in the one region of the program no test had ever entered. They are fixed, and the added tests fail against the previous version. Two smaller things: a rule the program publishes as governing which comparisons the self-check enforces was in fact not connected to anything, and error messages written into the results file quoted full paths from this machine, which the file's own guard could not see because it asked whether a message was a path rather than whether it contained one. Honest state: no simulation was run this session, the lifetime total is unchanged, no official plan has been produced, and the measurement is still not authorized to run — the second agent has to review these corrections first.
2026-08-04 — The payload-measurement program passed its full review. Eight adversarial review rounds found and closed failures in replay selection, terminal evidence, malformed-input handling, path removal, and the tests meant to protect those behaviors; the final round changed no working code and added contracts that catch future changes to the URL/path boundary. Both agents now approve the same executable and test state, backed by 1,306 passing packet tests. Honest boundary: no official plan, replay, or payload measurement ran, the lifetime Protocol-P-related total remains 151, and the configuration remains unfrozen. The next permitted step is a zero-simulation plan document; both agents must read it before any separate authorization can spend the replay or 126 measurement runs.
2026-08-04 — The measurement plan now exists, and it cost no simulation time. The program wrote out the full plan for the payload measurement: seven payload weights, ten damage levels, eight reused random identities, 126 distinct simulations plus one verification re-run, and — fixed in advance, before any of it runs — which results would count as reproducing what the earlier experiment already measured. Producing it consumed no simulation at all: it built eight copies of the robot's body to confirm each weight really reaches the model, stepped none of them, and finished in under four tenths of a second, against about twenty-six seconds for a single simulation. One agent has now read the plan and checked it by rebuilding its numbers from the plan document itself rather than trusting the program that wrote it — the fingerprint identifying the 126 planned robot bodies came out identical, as did every cost and threshold in it. Honest boundary: still no simulation has been run, the lifetime total remains 151, the second agent has not read the plan yet, and until both have and issue a separate authorization naming this exact document, none of the 126 measurements may start.
2026-08-04 — Both agents have now independently read and approved the exact measurement plan. The second read rebuilt the 126 physical keys, all costs, source hashes, identities, and anchor controls from the committed plan and frozen inputs; the plan is jointly approved at canonical digest 15298da4...030be3. This completes the planning gate only: no replay or payload measurement is authorized or has run, the lifetime total remains 151, and execution still requires a separate joint authorization naming this plan.
2026-08-04 — The authorized payload measurement ran once and returned a complete development result. The ordinary-path replay and the pre-registered anchor both passed, all seven payload ladders were safe and monotone, and the set of measurable damage levels narrowed with payload until it was empty at 0.150 and 0.200 kg; the pre-registered classifier is X_CASE_EMPTY. The run spent its full 127-rollout budget, bringing the Protocol-P-related total to 278. One agent independently reconstructed the exact result artifact; the second audit, any Amendment-A2 design choice, the final configuration, and all confirmatory work remain open and blocked.
2026-08-04 — Both agents independently confirmed the same result, and the second audit found the boundary is less sharp than the headline. The second agent rebuilt the artifact from scratch without using the program that produced it — 126 rollout fingerprints, 196 null distances, 70 ladder verdicts, the classifier, and the anchor's agreement with the earlier screen measurement — and approved the identical bytes, so the measurement is now jointly confirmed. It then asked a further question: how close is each conclusion to a different one? The headline finding (there is a payload weight above which no reserved damage level is detectable) holds comfortably. But the specific claim that the cutoff sits between 0.125 and 0.150 kg rests on two measurements sitting 2% and 4% from their own thresholds — inside the band this project had already declared too small to trust. So the existence of that boundary is established and its location is not, and the design decision that follows has to say so. The measurement is now unblocked for that decision; the final configuration and all confirmatory work remain blocked.
2026-08-05 — The Claim Sheet changed, but not one success bar moved. Both agents approved Amendment A2's evidence-licensed Option C: keep the full payload and damage ladders, pre-register a payload-bounded structural non-transfer result, and report the structural comparison by payload as well as pooled. The amendment prevents a payload-driven blind region from being reported as a clean failure of structural sensing; it is a contract change based on development evidence, not a research result. It authorizes no new simulation, dataset replacement, final configuration, or confirmatory work, all of which remain blocked behind their own later decisions.
2026-08-05 — The project's first learned model exists, and it is not allowed to answer yet. With the contract settled, the headline method the whole experiment compares — a small neural network that reads a short stretch of the robot's recent sensor history and says what changed — was built. It is deliberately tiny: about 40,000 numbers, small enough that one ordinary graphics card trains 4,000 windows a second using under 2% of its memory. Size is a design choice, not a limitation; this project's aim is affordable technology, so the plan is many small runs rather than one large model. Three properties were built in and then measured rather than assumed. It is identical for every sensor suite — the conventional robot and the structurally-sensed robot get the same network with the same number of parameters, differing only in what they are allowed to see, so any advantage found later cannot be "the better robot had the bigger brain." It cannot see forward in time, checked by nudging one instant of input and confirming no earlier output moved — a detail worth naming because the ordinary way of normalizing such a network quietly lets a moment's future leak into its past. And it refuses to guess: freshly built, with random and therefore meaningless internal values, it declines to name a cause and says so, rather than reporting whichever of the four answers its noise happens to favor. Weights can only be loaded together with a written record of where they came from. One more thing surfaced while checking it. By default this kind of network gives slightly different answers on a processor than on a graphics card — about 9 parts in 100,000, far too small to change any result here, but enough to make "you can reproduce this on your machine" false in the strict sense. A one-line setting removes it at no measurable cost, and the code now pins that setting rather than inheriting it. No training has happened. The model has learned nothing, and training it needs data generation that is still blocked.
2026-08-05 — Scope correction to the preceding entry. Training does not itself require new data generation: the jointly approved delivered development partition already exists, and dev-only fitting is now authorized as development evidence. New generation, pilot/validation/test outcome reads, the final configuration freeze, and confirmatory work remain blocked.

Follow along / what will be here

This project will produce four artifacts. All are pending while the run is live:

Technical Report (pending) — the rigorous, field-facing account.
Accessible Piece (pending) — the same work written for a general reader, with no technical background assumed.
Reproducibility Packet (pending) — code, configs, data references, a runbook, and the hands-on verification artifact so anyone can re-run and check the result on their own machine.
Study Guide (pending, director-facing) — a two-pass guide that keeps the project's director able to follow and judge the work.

The project's full premise, strategy, and standards live in Project Details/Project Details.md. How each artifact is built lives in Playbooks/. The project's contract — the Claim Sheet — is now agreed by both agents: Claim Sheet.md, along with its plain-language companion, the Accessible Claim Sheet.md, and the director-facing Study Guide (Pass 1).

Public, licensing, and how this is made

Public run. This repository is public and updated as the work proceeds. The agents' session-by-session reports live under agents/; coordination between agents lives under chats/.

Licensing. Code is released under MIT (LICENSE); prose and narrative artifacts under CC BY 4.0 (LICENSE-docs). The scope map and citation guidance are in LICENSING.md. Third-party datasets, if any are used, are not redistributed here — each will be documented with its own source and license in the Reproducibility Packet's DATA.md.

How it's made. Dandelion Engineering does real research and turns what it learns into affordable technology aimed at problems that matter for everyday people. It is one human director and a small team of AI agents working in short sessions that compound over time. The strategy is patience, not speed, and a clean negative result is treated as just as publishable as a positive one. A fuller account of the method resolves onto this page when the project concludes.

Navigation Menu

Uh oh!

Repository files navigation

Robot Structural Proprioception

What we are asking, in plainer terms

Running log

Follow along / what will be here

Public, licensing, and how this is made

About

Releases

Packages

Contributors

Languages

Name		Name	Last commit message	Last commit date
Latest commit History 159 Commits
Playbooks		Playbooks
Project Details		Project Details
Reproducibility Packet		Reproducibility Packet
Study Guide		Study Guide
agents		agents
chats		chats
.gitattributes		.gitattributes
.gitignore		.gitignore
Accessible Claim Sheet.md		Accessible Claim Sheet.md
AgentPrompt.md		AgentPrompt.md
CITATION.cff		CITATION.cff
Claim Sheet.md		Claim Sheet.md
LICENSE		LICENSE
LICENSE-docs		LICENSE-docs
LICENSING.md		LICENSING.md
README.md		README.md
director_requests.md		director_requests.md
requirements.txt		requirements.txt

Uh oh!

Folders and files

Latest commit

History

Repository files navigation

Robot Structural Proprioception

What we are asking, in plainer terms

Running log

Follow along / what will be here

Public, licensing, and how this is made

About

Topics

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages