Capability matrix
Start with the target configuration and the required evidence. The matrix shows which observation mode, components and prerequisites each result needs.
Read the matrix in three steps
- Select the exact target and available trace path.
- Select the required evidence: object execution, source statement, branch, condition/MC/DC, timing or control-flow monitoring.
- Review the resulting product combination, status, verified versions and limitations.
A blank or not yet verified cell is not a promise of support and not a finding of incompatibility. It identifies a configuration for which Accemic has not published an end-to-end verification record.
The matrix
The matrix below relates each kind of evidence to what it requires from the trace source, the program image, the compiler mapping and the observation mode. It is general on purpose: which cell applies to your project is a property of the exact configuration, and that question is answered per configuration - with a documented reference configuration, or a bounded feasibility review. The feasibility checklist says what to send us.
Related: supported targets · measurement validity
| Metric | Trace semantics | Program image | Compiler mapping | Timing / context option | Passive result | Anchor supplementation | Possible unresolved causes |
|---|---|---|---|---|---|---|---|
| Object execution | ● required | ● required | – not applicable | – not applicable | established within the valid trace scope | – not applicable | trace gaps · image mismatch |
| Source statement | ● required | ● required | ● required | – not applicable | established where the line mapping is unambiguous | ◇ conditional - closes mapping gaps | ambiguous or missing line mapping |
| Source decision / branch | ● required | ● required | ● required | – not applicable | established where the branch structure survives | ◇ conditional - where branches are merged or removed | merged or removed branches |
| Condition | ● required | ● required | ● required | – not applicable | ✕ not sufficient alone where conditions are fused; otherwise conditional | ◑ usually required at optimized builds | fused conditions · branchless code |
| MC/DC | ● required | ● required | ● required | – not applicable | ✕ not sufficient where the decision structure is lost at a merge point | ◑ usually required at optimized builds | masking at merge points · coupled conditions |
| Path timing | ● required | ● required | ◇ conditional | ● required (timestamps) | observed intervals at the implemented timestamp resolution | – not applicable | timestamp granularity · synchronization loss |
| Task / core attribution | ● required | ◇ conditional | – not applicable | ● required (context IDs) | ◇ conditional - needs core / context signaling | – not applicable | missing context packets |
| CFI deviation | ● required | ● required | ◇ conditional | ◇ conditional | deviations from the expected flow within the observed scope | – not applicable | model completeness · response latency |