BD × AI · MDLxDCC
Benchmark arena · architecture-search control

NAS / Neural Architecture Search Arena

A runnable MDLxDCC arena for testing whether architecture search spaces become steerable when their traces expose compressible structure. It combines NAS-Bench adapters, affinity and router sensors, DCC-style search laws, drain/fovea navigation, null controls, and a controlled noise-dimension stress test.
Version v19 modular · code capsule extracted from 8z NAS arena.zip · status: active prototype / reproducibility candidate
7,452 Python LOC10 modulesPhase A + Phase Bclaims require run logs
Short verdict. Yes — NAS deserves its own page. Until now it was only mentioned as a small card in the arena hub. This page gives it the missing role: a dedicated code-capsule page for architecture-search as a MDLxDCC evidence lane.
Search spaces
3
Synthetic, NATS-Bench-201 style, and NAS-Bench-101 adapter.
Sensor classes
49
LZ, affinity, family/router, physics, flood, rain, drain, transform and poly sensors.
Law classes
26
Random/greedy baselines, DCC, routers, allocators, drain navigation, and fovea laws.
Noise test
5^k
NB101 can be wrapped with irrelevant dimensions to test curse-of-dimensionality resilience.

Abstract#

Neural Architecture Search is a natural MDLxDCC arena. A NAS search space is not just a set of candidates; it is a structured landscape. If winning architectures share motifs, families, edge patterns, local corridors, or “avoid these losers” signatures, an MDLxDCC controller should be able to detect those signals and spend less budget on blind mutation.

The uploaded NAS arena is not a final benchmark-result paper yet. Its current public value is better framed as a runnable architecture-search laboratory: Phase A detects structure and builds routing assets; Phase B tests whether governance laws, drain/fovea navigation, and MDL-ranked selectors can beat simple baselines under fixed budgets.

1. Why this page exists#

The existing arena hub already mentioned “NAS / Architecture Search,” but only as a short card. That under-represents the work. The attached ZIP contains a full modular Python arena with benchmark adapters, sensors, laws, diagnostics, checkpointing, CSV/JSON exports, and a controlled scalability wrapper.

Positioning: NAS is the bridge between abstract P-vs-NP-style tractability, practical AutoML, and 8Z/MDL search governance. It deserves a page as a code capsule first, then a result page after the next clean run bundle.

2. Arena design#

LayerWhat the code doesWhy it matters
Search spacesnas_space.py defines NATS-Bench-201 style operations and a NAS-Bench-101 canonical adapter.Separates the arena method from one benchmark substrate.
Benchmark adaptersnas_bench.py supports synthetic runs, NATS/NAS-Bench-201 APIs, and NAS-Bench-101 tables.Allows smoke tests without external data and stronger tests when benchmark data exists.
Sensorsnas_sensors.py contains LZ76, entropy, affinity, signed-affinity, family/router, physics, flood/rain/drain, and transform-persistence sensors.Turns search traces and architecture structure into selectable control signals.
Lawsnas_laws.py includes random/greedy/local/evo baselines plus DCC, staged routing, physics allocators, drain navigation, fovea laws, and poly-greedy variants.Lets MDL compare simple policies against richer governance policies.
Diagnosticsnas_diag.py adds holdout tests, permutation nulls, family split, macro reverse-engineering, drain-vs-greedy, tiebreak, and trajectory-stability diagnostics.Prevents the arena from turning every apparent signal into a claim.

3. Phase A / Phase B workflow#

Phase A — structure discovery

Phase A asks whether the architecture space contains reusable signal before spending heavily on governance search. It scans affinity sensors, compares top-vs-random controls, runs holdouts, checks loser-avoidance via negativa, computes signed affinity, tests family splits, and prepares poly/router assets.

python nas_arena.py --synthetic --phase-a --budget 20 --count 5 --workers 1

Phase B — governed search arena

Phase B tests the actual arena question: under a fixed evaluation budget, which sensor × law pairs find better architectures, with better MDL, than simple baselines? It supports broad category filters such as baseline, governance, poly, drain, and transform.

python nas_arena.py --synthetic --phase-a --phase-b --cat drain,baseline --budget 30 --count 5 --workers 1 --resume
OutputPurpose
nas_phase1_phase_a_v19_modular.csv/jsonPhase A rows, signal summary, null checks, and router/poly metadata.
nas_phase1_phase_b_v19_modular.csv/json/txtPhase B leaderboard, best baseline, best governance, budget sweep, and diagnostics.
checkpoint filesResume support for longer searches.

4. Noise-dimension scalability test#

The strongest built-in stress test is nas_arena_nb101_noise.py. It wraps NAS-Bench-101 with irrelevant dimensions. Accuracy still depends only on the original architecture dimensions, but the mutation/search surface grows by 5^k.

Noise dimensionsEffective expansionInterpretation
k=3423k × 125 ≈ 52.9 millionSmall controlled curse-of-dimensionality test.
k=4423k × 625 ≈ 264.8 millionGood first public stress level.
k=6423k × 15,625 ≈ 6.6 billionLarge scale-up without changing the real signal.
k=8423k × 390,625 ≈ 165.4 billionExtreme controlled noise arena.
Clean hypothesis: if MDL governance really finds structure, it should learn that noise dimensions carry zero useful information and avoid wasting budget there better than naive mutation.

5. Code capsule#

This page ships with a cleaned public code capsule: Python source files plus README, without __pycache__. Publish run outputs separately before making performance claims.

Download code capsule →
ModuleRole
nas_arena.pyentry point
nas_phase.pyPhase A / Phase B orchestration
nas_space.pyNATS/NB101 search-space definitions
nas_bench.pysynthetic, NATS-Bench-201, and NAS-Bench-101 benchmark adapters
nas_sensors.pysensor catalog
nas_laws.pylaw / controller catalog
nas_diag.pydiagnostics and null tests
nas_runner.pyvariant execution, checkpointing, scoring helpers
nas_arena_nb101_noise.pyNB101 irrelevant-noise-dimension wrapper

6. Honest limits#

7. Next reproducibility move#

The best next move is a small, clean, public run pack:

  1. Run synthetic Phase A + Phase B as a zero-dependency smoke test.
  2. Run one NATS-Bench-201 / NAS-Bench-101 benchmark if local data is available.
  3. Run one NB101 + k=4 noise-dimension stress test.
  4. Publish the exact command, CSV/JSON outputs, top leaderboard rows, baseline-vs-governance delta, budget sweep, and failure notes.

If the noise test survives, NAS becomes a strong public example of the MDLxDCC claim: search improves when the controller learns what structure matters and what dimensions are only noise.


Version v0.1 page · June 11, 2026 · NAS arena page added as a code-capsule evidence lane. Performance claims intentionally deferred until a clean public run bundle is attached.