CEDARtools.Forge
AI-assisted development moves the embedded bottleneck to verification. CEDARtools.Forge answers: acceptance outside the generator, on real-target evidence.
Guided pilot · NDA · scope and assurance boundary defined per engagement
In brief
- requirements and acceptance criteria define the target;
- a generator produces candidate software and tests;
- independent build, test, coverage and integration gates evaluate the candidate;
- unresolved, invalid or non-convergent results remain visible;
- human approval remains explicit where the project requires it.
Scope a guided pilot · Read the assurance boundary
You author the requirements and acceptance criteria. A generator can produce candidate code, tests and configuration - and regenerate them as often as needed. The acceptance policy stays outside that generator.
CEDARtools.Forge evaluates the candidate through separately controlled build, test, coverage and integration gates. The generator may iterate on the result. It cannot silently change the oracle, redefine what counts as a pass or turn an unresolved result green.
CEDARtools.Forge is a workflow for generating and iteratively verifying embedded-software artifacts against explicit acceptance criteria, currently offered as a guided pilot. The release scope, supported model providers, deployment modes and assurance limitations are named per engagement. Patent disclosure does not establish product availability or performance.
One closed loop. Requirements go in, generation and build follow, the candidate executes on the real target, and the acceptance decision is made outside the generator, on evidence measured while the code ran. Findings return as the next iteration, until the criteria are met.
The pilot at a glance
| Starting point | Your requirements, or one of your existing embedded modules, through a Forge* run |
| You provide | The requirements and acceptance criteria - you own the what - and, if the pilot starts from existing code, the module itself |
| Agreed per engagement | Deployment mode, model provider, target and toolchain context, release scope and the assurance limitations that apply |
| Deliverable | The evidence bundle on your desk: versioned requirements, gate decisions (pass, fail, unresolved), open items, human approvals and cryptographic artifact identifiers. A sample evidence-bundle index from a complete Forge* run is available under NDA |
| Success criteria | Agreed before the run. The gate decides against the recorded criteria; no actor - human or generator - sets its own result to green |
| Stop conditions | Named acceptance criteria pass, a configured iteration or resource limit, a non-repairable requirement conflict, or required human review |
| Data boundary | Which artifacts leave your environment, which service receives them, retention and training use - fixed in the pilot agreement before any project artifact moves |
The problem is not speed
AI-generated code is growing quickly. Review capacity is not.
Today’s AI coding assistants have a structural weakness that is easy to miss: the model writes the tests that it then passes. It grades its own homework, and the result is a confident “all green” that can be silently wrong.
No one accepts self-graded homework.
In a web application, a silent defect can usually be corrected by deploying again. In an engine controller, a pump controller or an infusion device there is no redeploy that recalls the consequence.
Generation is not verification
The useful reframing is not that requirements suddenly become the source; disciplined embedded projects already implement against them. The change is that source code no longer has to be the primary artifact written by hand. You own the requirements and acceptance criteria; a generator produces a candidate implementation, and a separate acceptance mechanism decides whether it meets them.
That shift only holds if the verification lives outside the generator. Whoever owns the verification owns the trust - and it cannot be the same actor that produced the code.
A loop with a deterministic external gate
Forge* runs a multi-stage pipeline: requirements, design, code, unit tests, integration tests, system tests, and coverage measured on the real target.
The acceptance decision is made by a deterministic gate, not by the model. The generator never sets its own result to green.
The published application is the first public description of this approach. If you want to read the loop at its source, the patents page carries the publication details and what the application describes beyond the claims.
What the gate evaluates
The gate consumes versioned requirements, build artifacts, test definitions, target results, coverage and timing evidence, and policy thresholds. It produces deterministic pass, fail or unresolved outcomes for those inputs. It does not judge unstated requirements or invent missing acceptance criteria.
Independence is enforced, not just encouraged: artifact generation is separated from acceptance-policy ownership, test oracles are versioned and reviewable, the generator cannot modify acceptance criteria, every iteration is recorded, and designated safety, security or architectural decisions require human approval. A run that does not enforce this separation is not described as independent verification.
What the workflow does not guarantee
Correct requirements, correct test oracles, complete acceptance criteria, complete environment models or freedom from assumptions shared by generator and verifier. These remain controlled engineering and review responsibilities - the assurance boundary page states them in full.
Trace becomes a control signal
In a conventional development workflow, trace is often something an engineer opens when there is a problem.
In Forge*, runtime observation becomes part of the loop itself.
A candidate implementation is built and executed on the target. CEDARtools® turns that execution into structured evidence while the system runs. The acceptance layer evaluates the result against explicit criteria and returns the outcome to the development controller.
The next iteration therefore does not have to start from a guess. It can start from what the real system just did.
That changes the economics of AI-assisted embedded development. Generating the next candidate may take seconds. If understanding the target still requires a human to capture, navigate and interpret trace manually, observation becomes the new bottleneck.
Live processing removes much of that latency from the loop.
The AI does not need a trace GUI. It needs trustworthy feedback from the target.
That is what our observation layer provides.
Live trace processing · What we do differently
A convergence layer, not a replacement toolchain
Forge* does not replace the compiler, debugger, HIL bench, static analyzer or qualified verification suite. It connects them, records their outputs and combines them with independent target evidence. Existing tools remain the systems of record for the functions they perform; Forge* determines whether the recorded acceptance criteria have been met.
That is why Forge* is complementary to an established embedded toolchain: it turns the toolchain’s results, together with Accemic’s live target evidence, into an explicit convergence and approval signal.
See how Accemic fits an existing toolchain
Verified where it runs
The coverage and execution evidence come from the processor’s own trace port - measured on the real, optimized binary, on real hardware.
- No application-side coverage counters distorting timing and memory on the shipping build. Probe-effect-minimal, and we do not write “free”; the reasoning is on the technology page.
- The verification layer is deterministic. The assurance relevance of a model depends on how its output is used, which errors can propagate into the product and which downstream activities detect them. Calling the model a “code source” does not by itself remove it from a tool-assurance analysis; the project documents the model’s role, allowed outputs, required reviews and independent error-detection mechanisms. That explicitness is what makes the arrangement discussable with an assessor at all.
Works with the code you already have
Forge* is not only a generator. In a pilot, it is an evidence engine for existing embedded code:
- wrap existing modules and measure their real resource footprint;
- measure actual coverage and behavior on the target;
- gate changes - human-written, AI-written or mixed - through the same fail-closed pipeline.
This is also the honest answer to “we already develop with an AI assistant”. Good - and an uncontrolled chat session produces no usable lifecycle data. Forge* turns interactive AI work into controlled, evidence-carrying lifecycle data.
What a certification culture gets out of it
An evidence chain with DO-178C and ISO 26262 process discipline: traceability from requirement to design to code to test to coverage, review records, justified exceptions - provenance-complete, and regenerable from a frozen baseline.
Two properties we consider non-negotiable:
Honest reporting by design. What cannot be measured is reported as not measured. It is never fabricated as 0 % or 100 %.
No actor grades its own work. That sentence includes the human ones. Dispositions and requirement changes need an owner and a signature; the generator has neither.
We write process discipline and aligned, never compliant or certified - those are words that belong to an assessment, not to a vendor.
What the evidence bundle contains
The bundle is the tangible object a pilot ends with. It contains:
- the requirement and acceptance-criteria versions;
- the generated artifacts, with model/provider and configuration identifiers;
- prompts or reproducible task records, as permitted by policy;
- build logs, tests and oracles, and the target configuration;
- coverage and timing results measured on the real target;
- every gate decision - pass, fail and unresolved - with unresolved items kept visible;
- human approvals, and cryptographic artifact identifiers for the whole set.
What a team without an auditor gets out of it
Nobody audits a coffee machine. The recall still costs money, the field failure still costs a reputation, and the engineer who has to reproduce a fault on a shipped unit still costs a week.
The safety industries did not invent traceability and structural evidence because they enjoyed it. They did it because a regulator made them pay for it - and once paid for, it turned out to be a cheap way to find out whether the software actually works. Everyone else skipped it for one reason: it took the most experienced verification engineers a team had, and most teams had none. That expertise sits in a small number of certified programs and does not scale by hiring.
That is the constraint Forge* is designed to remove. What used to be a campaign at the end of a project becomes a property of every iteration: the candidate runs on the real target, the evidence is measured while it runs, and the gate decides. Faster and cheaper is what automating a manual activity is expected to deliver - a pilot measures that effect for the named workflow. The less obvious consequence is quality, and it comes from frequency - evidence you can afford on every iteration is evidence you actually act on.
Forge* brings that capability in rather than replacing it. Where a team never had a verification engineer, nothing is displaced - the work simply becomes possible. Where a team has one, the week stops going into producing evidence and starts going into deciding what the evidence has to show, which is the part that was always worth their experience.
What does not change: someone still has to state what the software must do. Forge* does not do that for you, and without acceptance criteria there is nothing for a gate to decide.
Data and execution boundary
A pilot agreement states which source code, requirements, test results and binaries leave the customer environment; which model or service receives them; how prompts and outputs are retained; which deployment modes can run locally; how credentials and generated artifacts are protected; and whether customer data are used for model training. Until those fields are agreed for a project, Forge* is not represented as suitable for confidential embedded development.
Where it stands
Forge* is currently offered as a guided pilot. Its public architectural basis is set out in our published Hybrid Runtime Analysis application - the architecture behind Anchor*; the patents page carries the publication details. Product availability, supported configurations and measured behavior are stated per engagement - the pilot agreement names them before any project artifact moves.
The patent ledger distinguishes the closed-loop embodiments described in the publication from the scope of the claims as published.
Accemic has built processor-trace technology for over twenty years - the CEDARtools® line - protected by granted European and US patents across the predecessor families, including EP 3 792 770 B1; the patent ledger lists every grant per family and jurisdiction.
Patent and publication status · CEDARtools.Forge assurance boundary
The next step
A run stops when the named acceptance criteria pass, a configured iteration or resource limit is reached, a non-repairable requirement conflict is detected, or human review is required. “Converged” means that the declared gate passed for the recorded artifacts; it does not mean that the complete intended system is correct.
A guided pilot: your requirements, or one of your existing modules, through a Forge* run, with the evidence bundle on your desk afterwards.
The supported model providers are named per engagement, and that list is not meant to be a closed one. If you build the generation side - a platform, a model, a tooling stack - the acceptance path described on this page is meant to be integrated with, and we would like to hear from you.
Talk to us about what that would look like for your project.