lamm-mit/MetaMaterialsDiscovery

Agent-built computational laboratories for hierarchical metamaterial fracture

This repository archives three autonomous research runs in which Fable 5.1 (used through Claude Code), built and used computational laboratories to investigate hierarchical metamaterial deformation and failure. Each run began with the same scientific prompt and five reference images. The agent developed an interpretation of the architecture, implemented a mechanics model and interactive application, conducted simulations, developed prediction strategies, and produced a scientific report with supporting data and visualizations.

The release contains executable scientific models, applications, research records, and simulation outputs. It is hosted as a Hugging Face model repository to distribute the large research archive; it does not contain the weights of Fable 5.1. The computational instruments and their recorded experiments are the objects being shared.

Scientific approach: models building models

The experiment studies how an AI agent can construct a physics-based research instrument and then use that instrument to investigate a scientific question. The supplied images served as architectural inspiration: the task asked the agent to infer transferable principles of hierarchy, branching, connectivity, disorder, interfaces, and load paths. They were not registered views for direct geometric reconstruction.

The central mechanics question was how hierarchical organization affects stiffness, peak load, work to failure, damage localization, and the transition between abrupt and progressive fracture, while controlling the amount of material. The prompt also required explicit model assumptions, numerical checks, reproducible geometric variation, predictions for later designs, and exportable research outputs.

Within each autonomous run, Fable 5.1 operated through Claude Code to:

1. Interpret the prompt and images and choose a hierarchical design representation.
2. Implement a geometry generator, mechanics solver, fracture algorithm, and browser application.
3. Check the implementation and plan computational experiments.
4. Generate designs, simulate their response, and investigate candidate mechanisms.
5. Develop predictions and evaluate them against subsequent simulations.
6. Write a report and preserve code, parameters, results, figures, and geometry exports.

The three runs are repetitions of the same research brief. Their generated models and research choices differ, allowing comparison of both the scientific implementations and the conclusions they support. The language model was used to construct and operate these instruments; training a new foundation model was not part of the experiment.

Repository structure

The three run directories are under data/. Each contains the shared prompt and reference images, together with the generated research archive.

README.md
data/
├── Run 1/
│   ├── prompt.md
│   ├── image_grid_*.png          # Five reference images
│   └── RESULT Run 1/             # Generated research outputs
├── Run 2/
│   ├── prompt.md
│   ├── image_grid_*.png
│   └── RESULTS Run 2/
└── Run 3/
    ├── prompt.md
    ├── image_grid_*.png
    └── RESULTS_Run 3/

The generated research outputs are in RESULT Run 1, RESULTS Run 2, and RESULTS_Run 3, respectively. These names are case-sensitive; Run 3 uses an underscore after RESULTS. The shared prompt and all five input images were verified to be byte-identical across the three original run folders.

The original autonomous studies and the later human-directed analysis are separate phases of the research. The discussion of later reuse below provides scientific context; it does not imply that additional follow-up archives are included in these three run directories.

Start with the applications and reports

The links below point to each run's application and report using the directory names in this release. Download an application and open the HTML file locally to use it.

Run	Interactive application	Original report
Run 1	Hierarchical Fracture Lab	Report PDF
Run 2	HMF Studio	Report PDF
Run 3	Hierarchical Fracture Lab	Report PDF

The original shared prompt specifies the requested capabilities and research procedure. Each results folder also contains its own README.md with detailed reproduction instructions.

What is inside each results folder?

The agents organized their deliverables differently. The following paths are relative to the corresponding original results folder.

Material	Run 1	Run 2	Run 3
Application and source	app/, app/src/	app/, app/src/	app/, src/
Simulation records and plans	study/	study/	data/, tools/
Individual simulation outputs	study/runs/	study/runs/	data/runs/
Numerical checks	validation/	validation/	data/validation/, tools/validate.js
Analysis and processed results	analysis/	analysis/	analysis/, data/processed/
Scientific report and LaTeX	report/	report/	report/
Figures	analysis/figures/, report/figures/	figures/	figures/
Visualizations and geometry exports	screenshots/, movies/, stl/	screenshots/, movies/, stl/	screenshots/, movies/, stl/
File inventory and provenance	manifest.json	manifest.json	manifest.json

Simulation records include parameters, random seeds, geometry, force–displacement histories, fracture events, diagnostics, and derived metrics. The availability and format of detailed state histories vary between runs and designs. STL files are generated geometry exports; their presence does not establish that the structures were fabricated or experimentally tested.

Mechanics models

All three instruments represent hierarchical structures as planar beam networks under quasi-static tensile loading. They solve mechanical equilibrium, identify member or interface failure, update the surviving structure, and calculate the resulting redistribution of load. Nodes carry in-plane translations and rotations.

Feature	Run 1	Run 2	Run 3
Principal beam theory	Euler–Bernoulli	Timoshenko	Euler–Bernoulli; Timoshenko option also available
Main reference geometry	Normalized unit-square specimen	40 × 60 × 3 mm specimen	40 × 40 × 3 mm specimen
Usual relative density in the main study	0.20	0.25	0.25
Principal raw data location	study/runs/	study/runs/	data/runs/

Euler–Bernoulli and Timoshenko formulations make different assumptions about shear deformation. The runs also differ in their geometry generators, boundary treatments, interface definitions, and other modeling choices. Their dimensional outputs therefore require attention to units and controls before comparison. The archived solver documentation and application physics panels specify the implementation used in each case.

The models use elastic members with irreversible failure and re-equilibration. They provide numerical evidence about architectural load sharing and fracture sequences within these assumptions. Work calculated from a force–displacement history is a structural response measure; it should not automatically be interpreted as an experimentally measured material fracture toughness.

Predictions and holdouts

The agents also developed ways to predict the response of later designs. A holdout design is a design for which a prediction was recorded before its subsequent fracture simulation was used to evaluate that prediction. These tests compare predictions with outputs of the generated mechanics model.

The prediction strategies differ: Run 1 records reasoned estimates and ranges, Run 2 develops empirical relationships involving elastic energy partition, and Run 3 develops a regression using design and mechanics descriptors. Relevant prediction records are:

Run	Prediction record within the original results folder
Run 1	study/predictions.json, study/predictions.md
Run 2	study/holdout_predictions.json
Run 3	data/holdout_predictions.json

Holdout accuracy measures how well these strategies anticipate later simulated responses. Physical validation requires additional evidence beyond agreement with the agent's own simulator. Numerical checks of the solver and evaluation of a predictive regression address different questions.

Scientific findings

The original studies identify recurring roles for material allocation and load-path organization. Width contrast, geometric order, and the arrangement of coarse and fine members affect load concentration, rupture synchronization, and the ability of a surviving skeleton to carry load after local failure. Hierarchy depth alone does not provide a reliable ordering of mechanical performance. The different implementations also produce model-dependent conclusions, including different responses to weakened interfaces.

The preserved Run 3 simulator subsequently supported human-directed, AI-assisted studies of design variation, fracture dynamics, notches, and specimen size. These follow-up studies examine how mechanical capacity, failure progression, and flaw tolerance compete. Greater total work can accompany abrupt force loss, and improved performance in a notched structure can carry costs in intact performance. Hierarchical designs do not uniformly outperform an ordered flat reference across all conditions or properties.

These follow-up experiments belong to the later research phase, rather than the original autonomous runs.

One documented audit concerns the original Run 3 width control: at hierarchy depth two, requested total coarse-to-fine width ratios of 4, 6, and 8 all produced a ratio of 4 because of a generator cap. The original archive preserves this discrepancy. A later width-control repair corrects the control and executes the missing comparison.

Using and reproducing the work

1. Read the prompt and original report. Establish the questions, definitions, units, assumptions, and design identifiers used in the selected run.
2. Open the corresponding HTML application locally. The original applications are self-contained browser tools with geometry controls, simulations, result visualization, numerical checks, and exports.
3. Inspect the recorded evidence. Use the parameter sets, seeds, plans, experiment logs, and raw simulation records to trace a reported result.
4. Reproduce calculations in a working copy. Preserve the original archive and record any changes to the solver, generator, controls, or analysis.

The applications require a modern browser with WebGL. Headless workflows use Node.js; the original Run 1 and Run 3 instructions specify Node.js 18 or later. Analysis scripts use Python with packages such as NumPy, pandas, SciPy, Matplotlib, and Pillow, depending on the run. Movie generation and report compilation additionally use tools such as FFmpeg and LaTeX. Consult each run's README for the exact workflow.

For example, from inside the appropriate original results folder in a local working copy:

# Run 1 or Run 2: execute that run's numerical checks.
node validation/run_validation.js

# Run 3: execute its numerical checks.
node tools/validate.js

These are separate run-specific commands. Batch-study and analysis scripts can regenerate outputs, so their plans and output paths should be checked before execution.

The saved code and parameters support computational reproduction. Repeating the original agent session can produce different software and research decisions even with the same prompt and images. Fable 5.1 is the model designation recorded by the experimenter; exact backend revision, inference settings, and complete session telemetry are not established by the archived artifacts alone.

Citation

Please cite as:

@misc{buehler2026metamaterialslaboratoryswarm,
      title={Artificial intelligence agents autonomously build computational laboratories that reveal design principles of hierarchical metamaterial failure}, 
      author={Markus J. Buehler},
      year={2026},
      eprint={xxxx.yyyyy},
      archivePrefix={arXiv},
      primaryClass={cs.AI},
      url={https://arxiv.org/abs/xxxx.yyyyy},
}