A clean beginning
Crucible begins as a new DarkMatter Software project identity rather than inheriting the version chain of the earlier development environment. The architecture that proved useful remains, but the application, documentation, distribution naming and future release history now move forward under Crucible.
The core problem
Local AI development becomes difficult to trust when one model is expected to interpret the request, design the solution, implement it, inspect its own work and declare completion. Crucible separates those responsibilities into visible stages and keeps the human operator in authority over the entire sequence.
Architect + Coder separation
Crucible assigns planning and review to an Architect role while implementation and repair belong to a Coder role. Each role can use its own local Ollama model and its own runtime budgets, allowing the operator to choose models according to the work they perform rather than treating every model as interchangeable.
Controller validation
The development loop includes controller-side completion checks, Python compilation validation and PySide6 offscreen runtime smoke testing. These checks exist outside the language-model judgment loop so a confident response cannot substitute for executable evidence. Failed validation can return concrete failures to the Coder for another correction pass.
Verified Final Output
Crucible separates the collaboration transcript from the deliverable. Planning discussion, implementation attempts, test failures and reviewer feedback remain part of the working record, while the dedicated Final Output area is reserved for work that survives the controller and review sequence.
PerformanceLab integration
PerformanceLab remains the measurement chamber inside the suite. Its documented 1.0.3 baseline provides local Ollama benchmarking, system scans, cold and warm phases, repeated measured runs, persistent configuration, history, reports, comparison data and CPU-governor controls.
PerformanceLab state is namespaced within the project so Crucible can consume benchmark configuration and history without duplicating the measurement system. The integrated report visualizer can read benchmark reports, filter by model, graph selected metrics and export visual comparisons.
Crucible 1.2 direction
The Crucible 1.2 baseline combines role-specific CPU thread controls, role-specific output-token budgets, shared context and temperature settings, configuration import/export/reset behavior, direct import from PerformanceLab profiles, controller validation and verified Final Output promotion.
Project philosophy
- Separate responsibilities: planning/review and implementation are distinct jobs.
- Validate outside the model: executable controller evidence matters more than an AI declaring success.
- Measure the actual machine: local model tuning should be based on repeatable benchmark evidence, not assumptions.
- Keep the operator in control: Crucible structures the experiment, but the human decides what is accepted, rejected, repaired or promoted.
Where the laboratory can go next
Future development can expand baseline pinning, benchmark matrices, experiment organization, stronger statistical analysis, confidence measures, pre/post resource deltas, richer controller test profiles and deeper comparisons between Architect and Coder model behavior.