Tool-Ran Tri-State Provenance

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A scanner is installed but project authentication is unavailable. Distinguish presence, runnable conditions and observed execution, then record success and task coverage separately. An installation inventory does not prove scanning.

Mechanism

Record present, runnable and ran with evidence, using unknown when unresolved. Bind runs to command, current files/revision, environment and output. An authentication-failing invocation is an attempted run, not a successful scan. Separately record result, actual scope, skipped files and gaps, keeping static findings apart. Count only inspected runs covering the current target.

Bad example

The scanner is installed, so the project is security-scanned. Label manually inferred issues scanner findings.

Good example

Inspect scanner/authentication now. If unattempted and authentication unavailable, record present=yes, runnable=no, ran=no with reason. If invocation fails authentication, record ran=yes, result=failed, coverage=none. Retain output instead of claiming success from installation or simulated execution.

Why the change matters

Presence, execution conditions and execution facts differ. Separating success and scope prevents a green configured label from hiding an absent or partial scan.

Observable expectation

Teaching records distinguish unattempted missing authentication from attempted authentication failure; neither establishes scan coverage. A successful output skipping generated needs that gap reported. Every ran=yes links current evidence, not merely command prose.

Limits

Successful calls establish neither full file coverage nor absence of vulnerabilities. Verify actual configuration, model identity and sandbox contracts. Frozen text asking for simulated random execution is not observed execution.