Partner with Accemic
Add real-target evidence without replacing your toolchain: three integration boundaries, what each side supplies, and the first evaluation step.
Add real-target evidence without replacing your toolchain
Accemic integrates at three boundaries: as an upstream measurement service, as an embedded trace source, and as a workflow-level acceptance component. Before implementation, we define the transferred artifacts, identifier mapping, integrity checks and the boundary of each assurance claim - the contract comes before the code.
Start a partnership conversation
Choose the boundary
Upstream measurement service. Your tool keeps its role as the system of record; Accemic supplies continuous, machine-readable target evidence through documented interfaces. This is the model behind the existing integrations: coverage into TESSY Hyper Coverage and Teamscale, measured timing into AbsInt TimeWeaver for hybrid WCET, timelines into Perfetto (beta). Where a standard format cannot carry observation validity, source-attribution status or MC/DC evidence, the export marks the Accemic-specific fields instead of silently flattening them.
Embedded trace source. For RISC-V® cores and SoCs, CEDARtools.TraceEncoder (CTTE) is synthesizable RTL published under CERN-OHL-S-2.0, with trace back ends, verification assets and measured synthesis profiles published with the release on the CTTE overview; a commercial Accemic license is available for integrators whose product cannot meet its reciprocity obligations, and for projects that need a defined commercial delivery and support scope. Evaluation starts in the open: inspect the repository, check the matrix of implemented standards (what Nexus, N-Trace and E-Trace define, and what CTTE provides), run the demo, then talk to us about the acceptance test for your core.
Workflow-level acceptance component. For platforms and generative tooling, CEDARtools.Forge provides the acceptance decision outside the generator, on evidence measured on the real target - offered as a guided pilot. If you build the generation side - a platform, a model, a tooling stack - the acceptance path is meant to be integrated with. The gate does not care which generator produced the candidate: what it consumes and what it returns is stated on the CEDARtools.Forge page, supported model providers are named per engagement, and that list is not meant to be a closed one.
What each side supplies
| You | Accemic | |
|---|---|---|
| Interface definition | The artifact your tool produces or consumes, identifier scheme, protocol subset | The evidence artifacts, their validity semantics, the documented interface |
| Acceptance test | The acceptance criteria of your integration | The reference behavior and the verification assets to test against |
| Assurance boundary | The claim your product makes on top | A stated boundary of what the transferred evidence does and does not establish |
The first evaluation step
A first conversation needs no confidential material: which tool, core or platform is involved, which artifact crosses the boundary, and where the integration point sits. We map the interfaces, evidence artifacts and responsibility boundary before estimating implementation work.