FREQUENTLY ASKED QUESTIONS
Know what is proven.
Know what is not.
A role-based guide to understanding, trying, building on, and evaluating SweetGold—without confusing a compelling demonstration with a production claim.
For first-time visitors
Understand
What is SweetGold?
A reproducible, auditable multi-agent AI lab built around a seeded bee-colony simulator. It connects simulation, training, matched-seed evaluation, policy promotion, verified distribution, and decision evidence.
Is it just a bee game?
No. The bee world is an understandable reference environment for studying agents that share limited resources, see only part of the world, and must coordinate while acting independently.
What do M14, M15, and M16 mean?
M14 is the latest formally promoted policy. M15 is the latest completed product workflow for constrained recommendation. M16 is the latest engineering milestone for explicit CPU, MPS, and CUDA execution.
Is SweetGold a production control system?
No. It is open-source research and evidence infrastructure. The local server is a research interface, and real robotics or industrial use still requires domain simulation, integration, safety, security, and regulatory evidence.
For learners and evaluators
Try
Do I need an AI background?
No. The simulator, rule policies, benchmark, and web Arena need only Python 3.10+. PyTorch is optional and required only for learning pipelines.
Should I train a model first?
No. Start with the Arena and matched-seed comparison. Promoted checkpoints can be downloaded and verified separately, without retraining.
Does one Arena match prove robustness?
No. A match or small league is useful for demonstration and debugging. Formal robustness requires predeclared gates, isolated final seeds, enough episodes, and multiple declared scenarios.
Why preserve failed experiments?
Failures expose reliability boundaries and prevent cherry-picking. M10–M12 failed their declared gates, stayed in the record, and motivated the structural change in M14.
For researchers and engineers
Build
Why use matched random seeds?
They give competing policies the same maps, resources, and weather—the equivalent of the same exam—so luck is less likely to decide the comparison.
Why can final seeds not be reused for tuning?
Once final results have been inspected, those seeds are no longer unseen. New research must allocate fresh validation and final ranges to preserve independent evidence.
Does a valid SHA-256 prove a model is safe?
No. It proves byte-level identity only. Suitability, performance, robustness, provenance, and licensing require separate evidence.
Which contributions are welcome now?
Focused defect, security, compatibility, installation, reproducibility, documentation, and regression-test improvements. New architectures need a concrete question, budget, fresh seeds, and predeclared gates.
For partners and governance teams
Adopt
Can SweetGold directly control robots or drones?
No. The transferable asset is the evaluation and evidence workflow, not the bee policy. Real systems need dynamics, sensors, communications, integration, and safety validation.
What is the closest credible adoption path?
Education and enablement first, then an adapter-based evaluation and promotion toolkit connected to an existing simulator or policy source.
Why is “no eligible policy” a useful answer?
If every candidate violates a declared constraint, explicit rejection is safer and more auditable than recommending the least-bad ineligible policy.
What would justify further product investment?
Repeated high-cost user problems, self-service use, value outside BeeSim, a partner committing real resources, and measurable reductions in evaluation time, defects, approval time, or audit effort.
NEED THE COMPLETE REFERENCE?
Continue with all 55 answers.
The repository FAQ also covers installation, hardware, authoritative artifacts, releases, licensing, issue routing, and reporting templates.