Read diffs and verdicts
Understand what changed, why it matters, and what the model cannot establish.
Read the infrastructure diff
Request a diff at any point to compare the rebuilt branch with its original baseline.
emfirge_branch_diff({ branch_id: "<branch_id>" })
| Fields | What they describe |
|---|---|
| added_nodes / removed_nodes / modified_nodes | Resource changes |
| added_edges / removed_edges | Relationship changes |
| added_findings / removed_findings | Changes in native checks |
| newly_internet_reachable / no_longer_internet_reachable | Modeled reachability changes |
| score_before / score_after / score_delta | Score comparison; higher is safer |
| deletion_impacts / lost_dependencies / lost_connectivity | What a deletion breaks or disconnects |
| coverage_warnings / collection_warnings | What the model could not check; non-empty means the result is degraded |
Two-sided diff: resources_added, resources_removed and resources_modified with before and after values, plus cost_before and cost_after, including resource types that have no graph node.
Interpret the verdict
The combined verdict compares native checks with scanner results and includes provisioned-cost notes. In the hosted service Checkov runs on each branch verdict and Trivy is off; scanner_status reports the outcome per scanner. Scanner findings are advisory. It is advisory; the backend does not stop an external AWS apply.
| Result | When it happens | Example reason codes |
|---|---|---|
| block | The change introduces something critical, or Emfirge cannot see enough to judge it. | introduced_critical_finding · introduced_critical_exposure · privilege_escalation · recently_used · usage_unknown · data_store_deleted_no_recovery_point · unseen_change · unmodeled_delete · unmodeled_risky_change |
| warn | The change needs human review. | introduced_finding · new_exposure · newly_internet_reachable · lost_dependency · lost_connectivity · deletion_impact · recovery_point_removed · capacity · unknown_plan_values |
| pass | No lens raised a warning or block. | None |
Read the reasons
Every verdict lists reasons. Each one has a level (block or warn), a stable code, and a human-readable message, so your agent can explain exactly why and decide what to change next. Only newly introduced problems count: an issue that already existed in the base does not block a branch.
Each reason also lists the resources it affects, and hand-back responses include a next_step your agent can follow.
{
"verdict": "block",
"reasons": [
{ "level": "block", "code": "recently_used",
"message": "CloudWatch metrics show a deleted resource was used in the last 90 days",
"resources": ["orders-db"] }
]
}
Read coverage alongside the result
Check scanner_available and scanner_status: a scanner that is disabled or unavailable did not find nothing, it did not run. Read scanner_loss, which lists what the scanner input left out (for example IAM, KMS, CloudTrail, Lambda, and VPC resources are not sent to scanners). Read cost_unknown_notes even when a numeric cost delta is present.
The current combined-verdict response does not include a universal confidence field. Confidence tiers on graph findings and roadmap commitments should not be treated as fields guaranteed on every tool response.
A pass is a statement about the checks that ran. Missing scanner coverage, unknown prices, and unmodeled application dependencies still need review.