Last technically reviewed 2026-08-16Evidence basis: Engineering analysis

---

The future of embedded development runs in one loop.

Requirements and acceptance criteria define the target. A candidate is generated, built and executed. Processor trace and connected tools produce runtime evidence. CEDARtools.Forge returns pass, fail or unresolved for the recorded inputs and sends the result into the next controlled iteration.

The loop below has two zones. Generation iterates as fast as the model can propose; observation and acceptance sit outside it, on the real target.

Generation is not verification

AI increases development throughput beyond the throughput of traditional human inspection. That is an opportunity, not a reason to slow generation down.

The control problem begins when the same system creates the implementation, creates the tests and decides whether both are sufficient. A green result can then demonstrate internal consistency without establishing that the intended requirement was met.

The target becomes the feedback channel

Embedded software becomes fully observable only when the candidate executes in its real processor, compiler, optimization, scheduling and hardware context.

Processor trace provides an independent execution channel. Processed live, it becomes structured feedback for coverage, timing, control flow, validity and the next development decision.

The generator proposes. The target provides the evidence.

Accemic spans the critical layers of the loop

The layers can operate as one architecture or connect to established compiler, IDE, HIL, requirements, verification and timing environments.

What the gate decides

For recorded requirements, artifacts, tool versions, configurations, test oracles and policy thresholds, the gate produces pass, fail or unresolved outcomes.

The generator cannot modify the acceptance policy or set its own result to green. Designated safety, security and architectural decisions retain an explicit human approval path.

Safeguards inside the loop

The architecture includes a sanitized feedback barrier: implementation-level coverage gaps are translated into requirement-level feedback, withholding source coordinates and other white-box detail from the test-generation path - so tests keep deriving from requirements rather than from the implementation they are meant to check.

Plausibility, invariant and metamorphic checks reduce the risk of accepting trivial, overfitted or domain-inconsistent implementations. An unresolved region can be classified as a missing test, a missing requirement, code that should be reconsidered, or a case requiring controlled justification and review. Iteration budgets, human approval paths and reviewable evidence artifacts complete the loop.

These mechanisms are described in our published patent application; the patents page carries the publication details.

What remains outside the gate

A reproducible gate outcome holds for its recorded inputs. It does not establish:

• correct or complete requirements,
• correct test oracles,
• freedom from assumptions the generator and the checks share,
• environment behavior that was not modeled,
• properties outside the observed metrics.

These remain engineering and review responsibilities. The assurance boundary names them in full.

Built to become part of a broader stack

Closed-loop embedded development touches compilers, IDEs, HIL systems, target farms, requirements tools, static and timing analyzers, verification suites and model providers.

CEDARtools.Forge is designed as an orchestration and evidence layer around those systems. Engagements can include a guided pilot, or a broader strategic relationship - the partner page states the three integration boundaries and the first evaluation step.

Explore CEDARtools.Forge · Discuss a pilot or strategic integration