Curiosity is All You need

Start with a question you can test. Can a small network recognise a pattern, classify a measurement or predict a useful label? Define the input, the expected output and how you will measure success. Then build a small experiment before collecting more data or increasing the model size.

What you train in this application

Weei runs a compatible WebAssembly model on participant devices. The coordinator creates the job, distributes assignments, combines returned weights and saves checkpoints. The model defines how inputs are decoded, how learning works and which metrics it reports. The workspace gives you controls for the job and a view of its progress.

You need both the model and its data. A CSV, a folder of images or a Python training script alone is not a runnable Weei training job. For a first experiment, use a small CPU model with a documented data reader and a held-out validation set. Reinforcement learning is another route: an experience model can generate its own data, as described in Your first RL project.

What a dataset is

A dataset is a collection of examples. For supervised learning, an example pairs an input with a target: a measurement with a category, a message with a label, or a question with an expected answer. The examples should reflect the task you want the trained model to perform.

For example, a small point classifier might learn which of three regions contains a coordinate:

{"features":[0.12,0.81],"label":2}
{"features":[0.74,0.16],"label":0}

This JSONL layout is an example of a format you can implement in a model. It is not a universal Weei format. The model must explicitly read it and declare a matching format ID; another model may require binary records, token IDs or a different layout.

How to collect useful examples

1. Write the task definition. Specify input fields, units, label meanings and a success metric. Decide how ambiguous examples will be labelled.
2. Gather representative data. Use your own measurements, appropriately licensed public data, simulations or human-labelled examples. Include ordinary cases and cases the model could confuse.
3. Clean and review. Remove duplicates, fix inconsistent labels and check missing or invalid values. Keep a record of where the data came from.
4. Separate training, validation and test data. A starting split can be 80% / 10% / 10%. Keep related records, such as examples from the same person or session, in one split. For time-dependent tasks, split by time when appropriate. Do not use the test set to choose settings.
5. Convert using the model’s preparation tools. Apply the same encoding and preprocessing to every split. Fit preprocessing on training data, then reuse it for validation and testing.
6. Write self-contained training chunks. Each must be readable independently. Generate a manifest from the final files, with their actual names, byte sizes, SHA-256 hashes, format IDs and example counts.

AI-generated examples can help test the pipeline or create a controlled synthetic task. Review their labels and variety. Good results on generated examples alone do not establish performance on real inputs.

Files to prepare

File	Purpose
model.wasm	The executable model implementing Weei WASM ABI 1, including training and weight export.
dataset-manifest.json	For the simple dataset route, a JSON array with one entry per training chunk: id, fileName, bytes, sha256, format and exampleCount.
Training chunks	All files named by the manifest, encoded for this model. Select these under Training files.
Validation data	Optional held-out examples. The model must support evaluation. Kept on the coordinator’s device.
Model package files	When using a package rather than a plain chunk list, select its manifest.json and every required auxiliary file. Optional GPU execution needs the matching shader archive.

The example below requests the simpler CPU route: a WASM model, a plain dataset manifest, training chunks and validation data. It does not require a GPU archive or an initial checkpoint. Hashes and sizes must be calculated after the real files have been generated.

A request you can give an AI coding assistant

Use an assistant that can create files and run a compiler. Replace the sample task with your own once the first pipeline works. The request asks for actual artifacts and verification, rather than a description of a package.

Build a complete, reproducible CPU training example for Weei AI Training.

First read the current public documentation:
https://weei.io/documentation/widgets/distributed-training/
https://weei.io/documentation/get-started/
Use only documented contracts. If a required ABI detail is not specified,
identify the missing detail and ask for it; do not invent a signature.

Task: classify two-dimensional points into three regions with a small
trainable neural network. Use synthetic points with a fixed random seed
and an explicitly defined labelling rule. This is a pipeline demonstration.

Deliver the following as real files in one output directory:
1. model.wasm, compiled from the included source. Implement Weei WASM ABI 1:
   memory, alloc, free, resultLength, getModelInfo, createInitialWeights,
   loadModel, train, getUpdate and getMetrics, using the documented JSON
   requests and responses. Add evaluate and declare evaluation support
   according to the documentation. Do not depend on WASI or unsupported imports.
2. A documented JSONL data reader for records such as
   {"features":[0.12,0.81],"label":2}. Choose a format ID and declare it in
   getModelInfo.dataFormats. Implement actual parameter updates in train;
   do not return constant metrics or unchanged weights as fake training.
3. 4,096 training examples in 16 independent chunks of 256 examples,
   512 separate validation examples, and 512 separate test examples.
   Generate unique examples with disjoint splits and the same schema.
4. dataset-manifest.json: a plain JSON array for TRAINING chunks only.
   Every entry must contain id, fileName, bytes, sha256, format and
   exampleCount. Calculate byte counts and lowercase SHA-256 hashes from
   the final files; do not use placeholders. Respect the model's limits.
5. A held-out validation file supported by evaluate. Declare loss and
   accuracy metrics with their correct minimize/maximize directions.
   Count uniqueExamplesForFedAvg separately from repeated local passes.
6. Source code, pinned build instructions, a data-generation script,
   and a verification script that checks all manifest entries, hashes,
   byte sizes, record counts and split separation. Keep model metadata,
   weight layout and float32-le weight serialization consistent.
7. A short file-selection map for the Weei UI: Model WASM, Dataset / model
   package manifest, Training files, and Validation dataset. List training
   settings supported by this model and a command to rebuild everything.

Use CPU execution and FedAvg for the first run. Do not add WGSL, invent a
package schema or rename a Python/ONNX file to .wasm. Training chunks
must be individually readable by the model. No test data in training.

Compile the module and run the artifact checks. Where possible, test
the documented ABI, demonstrate a real weight update and evaluate on
held-out data. Report exactly which checks passed. If a compiler or a
runtime check is unavailable, say so; do not call an untested bundle ready.
Provide the files as an archive if your environment supports it.

Review the generated sources and verification output. A manifest with plausible-looking hashes is not evidence that the files match. Successful compilation checks the module format; a short run in the workspace checks the integration.

Run the job in Weei

1. Open Workspace → Setup and wait for Training API to show Ready. Select model.wasm, the generated dataset-manifest.json, every training chunk, and the optional validation file.
2. Choose dataset passes, local epochs and batch size supported by your model. Start with a small run and FedAvg. In Training execution, choose CPU for this example and apply the device settings.
3. If validation is available, enable Schedule validation and choose an interval. Click Create job and read any returned file or model errors.
4. In Training, connect to other available peers and invite them. Each participant reviews and accepts the invitation. You can also train on the coordinator alone with Coordinator participates in training selected.
5. Click Start. Check participant progress, actual backend and execution diagnostics. Pause and resume when needed; API errors explain actions unavailable in the current state.
6. Open Results. Compare training and validation metrics across checkpoints. Download the checkpoint you want to retain; browser storage is not a backup.

A dataset pass covers all training chunks; a round is one assignment per active participant followed by aggregation. They are different counters. For final assessment, use the untouched test set with a compatible evaluator. Playground capabilities depend on the model: a point classifier does not automatically support text generation.

Keep the data, build settings and selected checkpoints together so you can repeat the experiment. Change one factor at a time and compare against the same baseline.

Model contract ↗ · Dataset manifest ↗ · Training requirements