06 — crossbar-build

The hardware-transfer arm of 02-memristive-crossbar. This is the portfolio's first sim→hardware crossing: it asks whether 02's idealized in-fabric learning PASS survives contact with a real programmable-conductance device — a memristor crossbar built from discrete memristors, at MVP scale (a few proof-of-concept in-fabric nodes).

Created: 2026-06-23 (as crossbar-fpaa). Reframed: 2026-06-24 — substrate changed from a floating-gate FPAA to a memristor crossbar; renamed 06-crossbar-build (see Why memristors below). Status: scaffolded; Phase 0 (the H5 device gate) is pre-registered and pending its run. No hardware has been bought or programmed yet.

Why memristors (and not the FPAA)

The original brief named a "floating-gate FPAA." Two corrections drove the reframe:

• The only owned FPAA is an Anadigm/Okika AN231E04 — a switched-capacitor array, not floating-gate. Its weights are capacitor ratios held in volatile SRAM and written by the host over SPI. Every weight change is an electronic write → by this project's own audit that is (… × electronic_write) = inference, not learning. It structurally cannot keep the update in the fabric, however well it classifies. (That hardware lives in the separate fpaa-neural-net repo and is not part of this project.)
• A genuine analog floating-gate transistor is not buyable as a discrete part — the analog form exists only integrated (academic FG-FPAAs, or a CMOS fab run). That aspirational route is the sibling 08-floating-gate.
• A discrete memristor is buyable, gives a genuine physical read + physical pulse write (so both audit axes can be physical and "the update stays in the fabric" becomes achievable), and is on-model: 02 is 02-memristive-crossbar; it simulates memristive conductances updated by pulses. A memristor build is the literal hardware realization of 02's sim, not a substitute for it.

Memristors are a poor mass-production bet (cost, device-to-device variability, limited endurance/retention). That is context, not a disqualifier: 06 is a mechanism/transfer test, and a noisy, variable device is the ideal stressor for the verdict question. Two guards keep it honest — MVP scope (a few characterized nodes, not a large array, so a foreclosure measures physics rather than a vendor's yield) and sim-gate-first (don't buy or build until the H5 re-sim at measured device parameters earns it).

The throughline (inherited, sharpened for hardware)

The portfolio question is who computes the update? On a real memristor crossbar that question gets a sharp, falsifiable edge:

Is the weight update computed in the fabric — from physically-measured node states, with the increment applied as a physical conductance write (a memristor pulse) — or is a host PC running the optimizer and merely writing conductances?

A host-computed gradient with a physical write is inference, not learning, and it fails this project's verdict no matter how well the device classifies. Keeping the contrastive update in the fabric is the entire point. Unlike the switched-cap FPAA, a memristor can satisfy this — the pulse write is a physical increment to a stored analog conductance.

What 02 established (the starting line)

• PASS (parity-3): both a half-co-located Manhattan rule and a fully-co-located eqprop rule learn above the device floor under clean training.
• V#4 / read-noise DIVERGENCE: under read noise injected into the training relaxations, the fully-co-located rule (two independent physical reads, dg ∝ Σ s(ΔVⁿ) − s(ΔVᶠ)) forecloses ~100× below realistic read noise, while the half-co-located rule (one physical read) stays robust. The audit's gradient-source axis flips the verdict. See 02's readnoise.py + the synthesis lesson contrastive-update-is-read-noise-fragile.
• Binder = conductance quantization, relaxable ~6-bit → ~4-bit by ν→0 pulse co-design. For a memristor the device-specific risks to measure are read noise (the chief one, per 02's H5) and device-to-device variability; endurance and retention/drift are checked at Phase 1.

The pre-registered staged verdict

A clean FORECLOSE at any gate is a valid, money-saving end (portfolio discipline: foreclosure is a result). Verdicts are frozen in verdict.py before each run.

• Phase 0 — H5 device gate (sim, runs first). Measure a real memristor's actual read noise σ_dev (fraction of conductance span) on a small bench rig (e.g. a Knowm Memristor Discovery board), then re-run 02's H5 sweep at σ_dev on the half-co-located object. classify_h5 PASS iff the half-co-located rule holds SNR ≥ 3 at σ_dev. The fully-co-located rule is expected to collapse (02 already foreclosed it) — confirming that is a consistency check, not a target. If even the half-co-located rule fails at σ_dev → FORECLOSE (or redirect to a non-contrastive update) before buying or building anything.
• Phase 1 — transfer verdict (on H5 PASS). Full device characterization (read noise, write precision/quantization, dynamic range, drift/retention, device-to-device variability) → re-sim at measured parameters → pre-registered PASS / BOUNDARY / FORECLOSE on "does the idealized-PASS survive a real memristor, update kept in-fabric?"
• Phase 2 — build (only on Phase-1 PASS). Program the half-co-located learner on a few memristor nodes and demonstrate parity-3 / XOR learned in-fabric, audited on both axes.

Why this is a sound first build

A memristor/conductance network is a gradient flow by construction — it minimizes power/co-content — so equilibrium-propagation rigor is licensed (cf. the commons lesson gradient-flow-is-the-ep-license; unlike 05's driven net at ρ=−0.076). There is no variational worry to confound the transfer test. The only open question is whether the device's non-idealities (chiefly read noise and variability) break what the math guarantees.

Layout

verdict.py        # FROZEN Phase-0 classify_h5 (substrate-agnostic; +Phase-1/2 to be frozen later)
tests/            # unit tests that brute-force the frozen decision function
docs/superpowers/
  specs/          # the design spec (2026-06-24, memristor reframe)
  findings/       # Observed / Interpretation, filled as phases run

Commons

Before starting work, read ../00-shared-harness/BULLETIN.md and ../00-shared-harness/synthesis/glossary.md. Port the two-axis audit.py from commons/; reuse 02's readnoise.py + coupled.py as the H5 sim reference. Report reusable findings/modules (esp. the sim→hardware transfer lesson family) so the commons can harvest them.