Evidence first, grounded ≠ inferred
SecEng's evidence engine (lib/seceng-evidence-graph) answers one question: given everything SecEng actually observed about a system, what credible sequence of trust-boundary crossings leads from an untrusted source to a sensitive capability, which parts are evidenced vs. inferred, and what single intervention breaks the most paths?
- Every grounded node/edge traces back to a concrete
EvidenceItem. observed/derivedevidence is grounded;inferred/speculativeevidence is not, and stays labeled as such through the whole pipeline.- Deterministic code runs before any LLM step — the evidence spine does not require an LLM to produce a result.
- Human validation stays explicit — no code path can mark something analyst-reviewed on its own behalf.
Attack path result states
The live attack-path-result contract (commercial/partner-adapters/contracts/attack-path-result.schema.json) tracks state at three independent levels:
| Level | States |
|---|---|
| Cluster status | draft, draft_grounded_validated, draft_extended, draft_flagged, draft_rejected, analyst_validated |
| Step tier | grounded, speculative |
| Validation verdict | not_run, sound, flagged, rejected |
| Retest status | not_run, pending, passed, failed |
analyst_validated is a state a human reviewer sets — it is not reachable from the automated pipeline. Rejected and flagged states are preserved rather than silently dropped, so a partner reviewing results can see what SecEng considered and ruled out, not only what it kept.
External tool run lifecycle
For external-tool invocations (scanners, linters, sandboxed checks), completion and non-completion states are tracked separately in seceng-external-tool-result.schema.json:
| Status | Meaning |
|---|---|
| not_requested | The tool was never invoked for this run. |
| not_installed | The tool is unavailable in this environment. |
| skipped | The tool was intentionally not run. |
| success | The tool completed normally. |
| failed | The tool ran and returned an error. |
| timeout | The tool exceeded its time budget — kept distinct from a normal failure. |
This is the current, real timeout representation in the engine. A dedicated cross-engine "canceled" state (as opposed to timeout) was not found as a separate enum value at last review — treat cancellation semantics as partner-confirmation-required until the generated error/status reference says otherwise.
SARIF and structured JSON
SARIF output supports scanner, CI, IDE, and AppSec ingestion. A consuming partner should preserve rule identifiers, finding fingerprints, severity, confidence, locations, and evidence references where supported. Exact current field names for structured JSON findings live in the generated schema reference, sourced from seceng-scan-content/schemas/ in savvy-cli.
What this page does not claim
This page describes the real state model enforced in code today. It does not assert a frozen, final schema — SecEng's contracts are pre-1.0 and evolving. Field-by-field documentation is deferred to the generated schema reference rather than duplicated here as a second, hand-maintained copy that can drift out of sync.