otTINN

Contents

1. Architecture overview

2. Module contracts

3. Model lifecycle

4. Architecture growth: bounded escalation

Growth is not neural architecture search. The planner has a finite deterministic sequence, a maximum of four hidden layers, width 96 and a 32,768-parameter envelope. Resource failures can teach an empirical ceiling so the next attempt may skip an infeasible wide topology and try a deeper-but-smaller one.

256 → 28 → 10
       │
       ├── WIDEN-PRESERVE → 256 → 48 → 10
       ├── further bounded width steps
       └── depth escalation → 256 → 48 → 24 → 10 → ... up to 4 hidden layers

Candidate initialization

• CLONE: identical topology, exact copy.
• WIDEN-PRESERVE: same depth, larger width; old subnetwork is copied so initial behavior is preserved.
• FRESH: depth changes; no false claim of exact identity through inserted sigmoid layers.
• PRUNE-COPY (v0.25): same depth, narrower; structurally salient neurons are retained deterministically. Knowledge is preserved approximately, not mathematically exactly.

5. Complexity-aware promotion without a fitness score

R3 preserves the existing decision semantics but changes the formal interface. The policy no longer consumes scattered validation/complexity values directly in the production path; it consumes one multidimensional signature for ACTIVE and one for CANDIDATE.

measurements
   ↓
ACTIVE Signature     CANDIDATE Signature
        \               /
         \             /
          → comparison ←
          → meaningful improvement
          → Pareto / dominance
          → independent hard gates
          → shadow authority gate
                    ↓
              FINAL DECISION

BF518 latency normalization remains explicit

During normal shadow execution ACTIVE is prepared first and retains first claim on scarce fast Q15 memory. CANDIDATE is prepared second and may be MIXED or NORMAL. That shadow arrangement is correct for safety but is not representative of Candidate deployment after promotion.

shadow execution
ACTIVE      → first Q15 residency priority
CANDIDATE   → remaining residency, often slower

policy deployment view
ACTIVE      → measured ACTIVE latency
CANDIDATE   → temporarily prepared alone, measured as-if-ACTIVE
               then normal ACTIVE-first / CANDIDATE-second state is restored

6. Model Performance Signature

R3 formalizes the concept introduced during the R2 campaign: a model is not assigned a single efficiency or fitness score. It is represented by a multidimensional Model Performance Signature. The signature is the boundary between measurement and policy.

SIGNATURE1 → SIGNATURE2

SIGNATURE1 first made the structure descriptive and proved that BF518 Candidate resource fields could represent deployment rather than shadow placement. SIGNATURE2 then made ACTIVE/CANDIDATE signatures the production policy inputs. Legacy report-based functions remain as regression oracles, but the BF518 endurance decision path is signature-driven.

7. Autonomous simplification and outcome memory

v0.25 closes the opposite side of adaptation: after sustained stability the system may propose a smaller Candidate. R3 retains the conservative trigger and adds SIMMEM1, a compact memory preventing repeated deterministic retries of a simplification already shown to fail from the same ACTIVE baseline.

stable ACTIVE
   ↓  stable ≥ 24,000 + age ≥ 48,000 + cooldown ≥ 48,000 + saving ≥ 5%
planSimplerTopology()
   ↓
PRUNE-COPY
   ↓
normal train → validate → Q15 → shadow → signature policy
   ├── PROMOTE → probation → smaller ACTIVE
   └── REJECT/ROLLBACK
          ↓
   SIMMEM1 remembers parent ACTIVE + target topology + outcome
          ↓
   identical retry blocked until ACTIVE changes

What the controlled Calm Tail test established

The experiment therefore found a current simplification floor empirically: 256-16-10 remained adequate while 256-8-10 did not. The floor was not hard-coded as a winner; it emerged from the ordinary validation/promotion policy.

8. Persistence, reboot and interrupted-write recovery

R3 treats reboot recovery as part of the lifecycle, not as an afterthought. The persistent layer uses A/B endurance state plus durable model catalogs because an unattended embedded target must survive reset at awkward points.

• State v6 persists endurance counters, simplification mode and SIMMEM1 parent/target/outcome data while remaining backward-readable by the hardened loader.
• Catalog/state coherence is checked at boot. ACTIVE/CANDIDATE/PREVIOUS IDs are reconciled with nextModelId before execution resumes, preventing ID reuse after a partial/older state image.
• Training resume restores both controller and TrainingSession state; a recovered PAUSED checkpoint is explicitly resumed before sample training continues.
• Partial restore is fail-safe. Catalog-without-state or state-without-catalog conditions halt rather than silently creating a mixed lifecycle.

otFILE v2.0.2

Persistence testing exposed a low-level line-input defect: the older fgetline() path could leave text without deterministic NUL termination at EOL, causing valid A/B records to be rejected depending on adjacent memory contents. R3 fixes the primitive rather than patching each caller.

otFILE::freadline(buffer, size, file, '\n', stripEol=true, &truncated)

properties:
  caller-supplied buffer
  guaranteed NUL termination
  CR/LF handling
  EOF distinction
  truncation detection + remainder consumption
  no per-line heap allocation

The endurance reader uses a fixed SDRAM buffer and rejects truncated records deterministically. Later BF518 boots recovered both A and B as valid, selected the newest sequence and continued from the real catalog/state pair.

9. BF518 memory strategy

10. Why these parameters?

This is the section most likely to be challenged in a review. Values are therefore classified by origin. Implementation-derived values come from what has actually been built and validated; project resource bounds deliberately cap autonomy; engineering heuristics are conservative initial choices and are candidates for revision from long-run evidence.

11. Validation evidence: accelerated regressions plus real BF518 campaigns

12. Non-blocking live status

UART0 remains deliberately minimal. ? is read-only and immediately returns to the loop; ESC performs clean checkpoint/commit/stop.

[STATUS] tick=... world=... monitor=... phase=... heap=...
[STATUS] generation(modelId)=... revision=... topology=... params=... nextModelId=...
[STATUS] roles candidate=... previous=... arch[fail=... next=... cap=...]
[STATUS] simplify[mode=... stable=... activeAge=... sinceAttempt=... attempts=... promote=... reject=... rollback=...]
[STATUS] training[state=... epoch=... sample=... trained=... checkpointSeq=...]
[STATUS] simplifyMemory[parent=... target=... outcome=...]

The query performs no SD write, fsync, allocation or lifecycle transition. The additional training and simplification-memory lines proved useful during reboot/resume and SIMMEM1 validation because they expose whether a Candidate is genuinely progressing and whether a failed shrink target is being remembered.

13. Long-run evidence: R1 → R2 → R3

The endurance campaign evolved from discovering a hardware measurement bias to validating autonomous shrink, persistence hardening and finally a signature-driven policy interface.

R1 — mechanically stable, policy input physically biased

R1 proved that the mechanics and persistence could run long enough to reveal a deeper problem: ACTIVE deployment latency and Candidate shadow latency were being compared under non-equivalent BF518 memory placement.

R2 — corrected deployment comparison, then long survival

R2 kept shadow execution unchanged but measured Candidate latency in an as-if-ACTIVE maintenance condition. The first same-topology retrained Candidates then promoted and survived probation, as predicted by the diagnosis rather than by any relaxed threshold.

Controlled Calm Tail — exercising the branch, not tuning the policy

A temporary laboratory scenario set gain=1, offset=0, noise=0 and target drift off after the aggressive prefix. The simplification thresholds stayed unchanged. This produced real autonomous shrink transactions: 256-28-10 → 256-24-10 → 256-16-10, while 256-8-10 was rejected.

SIMMEM1 and persistence hardening

Repeated 256-8-10 rejects exposed a new lifecycle issue: cooldown alone delayed, but did not prevent, deterministic retries of the same failed shrink. SIMMEM1 now remembers the failed parent→target pair until ACTIVE changes. Reboot testing then exposed and fixed training-resume, nextModelId reconciliation and low-level line-input defects; these changes became BOOTFIX3 + otFILE v2.0.2.

SIGNATURE2 — policy interface validated on the real target

The final R2 development stage formalized the multidimensional signature and then routed production decisions through it. A BF518 one-shot smoke measured ACTIVE latency ≈217.0 µs and a diagnostic 256-24-10 Candidate at ≈263.51 µs deployment latency; the Candidate was MIXED in shadow but FAST in deployment, normalized=1, authority zero, and the signature-driven policy reached the final reason REJECT_ACTIVE_DOMINATES.

R3 — clean production campaign completed

R3 freezes the validated mechanics into one production baseline: normal aggressive world, SIMMEM1, BOOTFIX3, otFILE v2.0.2 and SIGNATURE2. The clean run was executed from a fresh SD so its genealogy and logs were not contaminated by Calm Tail or smoke-test history.

14. Limits, interpretation and next physical step

• The current thresholds are engineering defaults validated for behavior and safety paths, not claimed statistical optima.
• The Semeion-driven synthetic world is a controlled testbed; results do not automatically generalize to every physical process.
• PRUNE-COPY is knowledge-preserving in a practical/structural sense, not function-preserving: removed sigmoid neurons can change the represented function.
• No claim is made that the system discovers a globally optimal neural architecture. It chooses from a bounded deterministic neighborhood and can saturate.
• RTC is intentionally not part of autonomy decisions; sample counters are the authoritative long-run time base.
• The Model Performance Signature is an auditable representation and policy interface, not a learned scalar objective; it does not claim to solve global multi-objective optimization.