Reports, Findings, and Plans
Three different objects, three different jobs. Knowing the difference makes Escher much faster to use.
TL;DR
| Object | Answers | Mutates? | When you'll see one |
|---|---|---|---|
| Report | What did we observe? | No | Generated automatically by scans, or explicitly when you ask for an audit-style summary |
| Finding | What is worth attention? | No | Created from a Report or directly when Escher detects an actionable issue |
| Plan | What do we intend to do about it? | Not yet — it's intent, not execution | When you decide a Finding needs remediation |
A Report describes reality. A Finding interprets a slice of reality as actionable. A Plan captures what you intend to change about it. Every claim at every stage is backed by Evidence with a one-click link into the AWS Console or Azure Portal.
Report
A Report is a snapshot of observed data — a structured analysis produced from a scan.
- Reports are read-only and immutable once generated
- Some Reports are automatic (every scan produces an inventory Report)
- Some are generated on demand ("give me a security posture Report for prod")
- Reports power Findings and Canvases — they're the substrate, not the conversation
You typically don't navigate to Reports as a top-level surface. They show up as the underlying evidence behind the Findings and Canvases you do see.
Finding
A Finding is an actionable interpretation of one or more Reports.
A Report says: "S3 bucket prod-customer-uploads allows public read." That's an observation.
A Finding says: "S3 bucket prod-customer-uploads allows public read — this is a HIGH severity exposure issue. Last public access was 12 minutes ago. Recommended remediation: enable Block Public Access." That's an actionable interpretation, with severity, recommendation, and a path to a Plan.
Properties of a Finding:
- A scope — which resource(s) or environment it covers
- A severity (info / low / medium / high / critical)
- A confidence rating
- Linked evidence (the underlying Report sections / config values)
- Optional ticket links (Jira / Linear / GitHub Issues)
- A status:
new → acknowledged → delegated → resolved(ordismissed)
Findings are the collaboration unit in Escher. You triage them, assign them, dismiss false-positives, and close them with evidence.
Plan
A Plan represents developed intent — what you've decided to do about a Finding (or several).
- A Plan is bound to one or more Findings
- A Plan captures inputs and assumptions ("we're applying this only in
us-east-1", "we'll use the standard remediation Playbook") - A Plan evolves through revisions as you refine it
- A Plan is not an execution — it's the intent. The execution happens via the Bundle materialized from the Plan
Plans matter because they make the what should happen explicit and reviewable, separate from what actually runs. That separation is the foundation of Escher's safety model: an approved Plan with a stale Bundle gets flagged before it can damage anything.
See Playbooks Overview for the developer reference on Plans → Bundles → Runs → Evidence.
How they connect
Estate scan
│
▼
Report (immutable observation, pinned to an EstateView)
│ │
│ ↓ cites
│ Evidence record(s) — typed, immutable, with cloud-console deep links
▼
Finding (actionable interpretation — severity, recommendation)
│ │
│ ↓ cites
│ same Evidence + extra Evidence captured during triage
▼
Plan (intent — what we'll do)
│
▼
Bundle (concrete steps — what will run)
│
▼
Run (the execution)
│ │
│ ↓ produces
│ Run-time Evidence — before-state, after-state, API calls, approval record
▼
Closed FindingEach transition is explicit. None of them is automatic without your approval, and each leaves a record you can audit.
Evidence is the universal citation
Reports, Findings, Plans, Bundles, and Runs all cite Evidence. Every Evidence record is:
- Typed — a CloudTrail event, a config snapshot, a billing line, an IAM policy, a deployment record, an approval record, etc.
- Immutable — never overwritten. If a fact changes, a new Evidence record is created with a new timestamp; old Evidence stays readable forever.
- Linked to the cloud — every Evidence record carries one or more cloud-console deep links so any claim can be verified in the AWS Console or Azure Portal with one click.
So when a Finding says "S3 bucket prod-customer-uploads allows public read", you can:
- Click the citation chip → see the actual
BlockPublicAccesssettings and bucket policy that produced the claim - Click the View bucket in S3 Console ↗ link → land directly on the bucket's page in AWS Console
- Export the whole chain as PDF (JSON / Markdown on the roadmap) and the console links survive intact
This is what makes Escher's reports auditor-grade: every claim resolves to a typed Evidence record, every Evidence record resolves to the source-of-truth cloud system.
For the full Evidence record schema and the cloud-console URL patterns Escher uses, see Evidence & Reports (developer reference) and Canvas Export.
Common workflows
"Tell me what's wrong" → returns a Canvas backed by Findings (no Plans yet).
"Fix this Finding" → moves the Finding into a Plan-creation flow. You review the proposed Plan, approve, and Escher materializes the Bundle.
"Show me the audit trail for last quarter" → returns Reports + closed Findings + completed Runs with their Evidence, exportable as PDF.
What's next
- Canvas Overview — the format Findings and Plans are presented in
- Playbooks Overview — the developer reference for Plans, Bundles, Runs
- Asking Questions