Technical Approach
How DICEE keeps the adaptability of an AI agent without its guesswork, by deciding exactly where the model may act and where it may not.
Intelligence and Determinism
DICEE keeps design and development apart. Design is open-ended, so an AI model leads it. Development is exact, so computation owns it. That separation is what makes the result predictable.
Design Intelligence
Language modelReads your description and turns it into an engineering design: the plant, the controller and the parts.
Works only from what you described. Extras that need more hardware are offered as optional questions, and every job is kept small and tightly scoped.
Deterministic Resolution
SolversComputes the MCU configuration from the official documentation of your exact chip: pins, DMA, interrupts, triggers and the clock.
Computation, not recall: the output reflects what the chip specifies, not what a model remembers.
The model proposes. The solvers resolve.
Applications of AI
Every AI call has a narrow scope, each job is broken into atomic tasks, and every result passes checks it cannot bypass.
- AI proposesThe AI’s role
Analyses the plant, designs the controller with its mathematical model, and grades and sources the parts.
What keeps it groundedParts are checked against real catalog data, and features come only from your description. Each design also states an engineering baseline.
ProducesDesign for approval - DeterministicThe AI’s role
Chooses which peripheral classes the firmware needs and how many, picks the real instances, and decides between bare-metal and RTOS.
What checks itIts answers are validated against the MCU documentation and invented names are rejected. The solvers then resolve the rest.
ProducesResolved MCU configuration - AI inside HAL limitsThe AI’s role
Plans which files the design needs to change, then writes against ST’s HAL (Hardware Abstraction Layer), the vendor-maintained driver library between your application and the chip’s peripherals. Each STM32 family ships its own, and DICEE uses the one for your exact family.
What holds it to the HALGeneration is deterministically constrained to those HAL files. The model can only use what the HAL defines, and anything outside it is caught and corrected before it reaches your project.
ProducesHAL-based project source - VerifiedThe AI’s role
Splits development into checkpoints and writes a runnable test for each, with numeric pass criteria.
What confirms itEach checkpoint compiles before the next begins, then runs on your hardware, where the result decides whether it is done.
ProducesCompiled, tested checkpoints
Guarantees by Design
Reproducible resolution
Resolution is computed, not sampled: the same design on the same MCU always yields the same pin, DMA, interrupt and clock configuration.
Conflicts stay visible
Conflicts are reported together, including what the MCU cannot do, such as more interrupt urgency levels than the hardware offers or a trigger path the part lacks. Nothing is quietly worked around.
Measured, never invented
Values only your hardware can reveal, such as sensor look-up tables, PID gains and plant time constants, start from safe values and are settled with real measurements during the test phase.
Traceable by design
Every design decision is written to documentation you can open at any time, so each behavior traces back to the decision behind it.
What the documentation containsWhat Lands in Your Workspace
For a supported part and a described project, DICEE delivers:
A validated hardware design
Plant analysis, controller design with its mathematical model, and a parts list graded against the roles the design needs.
How the design is builtAn engineering baseline
Fault handling, watchdog, safe state at reset, supply supervision and power budget, each applied or marked not applicable with a reason.
A resolved MCU configuration
Pins, DMA, interrupts, triggers and the clock tree, computed for your exact chip.
What gets resolvedA standard STM32 project
HAL-based source in the familiar project layout, ready for you to open, read, edit and extend.
How the code is writtenCheckpoints with tests
Code built in stages, each compiled before the next, with a runnable test and numeric pass criteria for every checkpoint.
What each checkpoint coversDesign documentation
Eight read-only documents, from plant to build plan, opened in your browser and saved as Markdown in your workspace.
What the documents containThe output is a sound starting point that you own and can extend, not a finished product to ship without review.
Planned direction
These describe intent and are subject to change.
Wider hardware support
More vendors and microcontroller families beyond STM32.
Automated flashing and debugging
Flashing and on-device debugging driven by the agent, with appropriate safeguards.
Bring your own documentation
Upload documentation of any type yourself, so DICEE can support every kind of development task. Today the documentation is curated and built in.