Report & Interpretation Note Generator

The analysis is finished; the deliverable is not. Every engineer who has closed the laptop after a good InSAR processing run knows the gap between having results and having a report — the structure, the methodology statement, the limitations section written in language a reviewer will accept, the disclaimer phrasing that protects both the client and the author. This tool closes that gap. It assembles the numbers you produced across the workbench — converted velocities, classification counts, validation statistics — into a structured engineering report skeleton, tailored to one of four delivery scenarios, in Markdown that pastes cleanly into Word, Google Docs or any documentation system.

Two design decisions distinguish it from a mail-merge template. First, the statistics section is injected from the Data Tray, so the figures in the report are the figures your tools actually computed — there is no transcription step where typos creep in. Second, the limitations and verification language is standardized on purpose: the same careful wording, the same insistence on field verification, every time. Consistency in the caveats is what makes a screening deliverable defensible.

When you should use this tool

• At the end of a screening workflow, to produce the first-draft report the engineer then reviews, edits and takes responsibility for.
• As a junior engineer's training frame: the generated structure shows which sections a defensible InSAR screening note contains, and in what order the reviewer expects them.
• To standardize deliverables across a team — the same scenario always produces the same section skeleton, so reviewers know where to look.
• For fast site memos where a two-page structured note is the right deliverable and a full report would be theater.

When NOT to use this tool

• As the final deliverable without human review. The generator writes structure and neutral phrasing; it does not know your site, your client's specification or your professional judgement — and the generated text says so explicitly.
• For formal geotechnical assessment reports governed by a client template. Where a specification prescribes section structure and wording, the specification wins.
• To launder analysis you have not actually performed. The report skeleton includes a methodology section that lists the tools used; generating a report around steps you skipped is exactly the misuse the disclaimer language exists to prevent.

How the four scenarios differ

All scenarios share the same skeleton — introduction and scope, site and data, methodology, findings, interpretation, limitations, recommendations — but each frames the analysis the way its audience expects. The railway baseline screening variant emphasizes corridor-scale gradients and the asset-span logic of the neighbour radius, because track engineers think in wavelengths of defect. The mine subsidence assessment variant frames results against the monitoring campaign's purpose and flags the difference between planar subsidence bowls and localized slope-motion signals. The landslide reconnaissance variant stresses that slope-parallel motion is the expected signal, that single-track LOS is an imperfect observer of it, and that reconnaissance findings feed a site walkover rather than conclude one. The highway asset survey variant organizes findings by asset segment and references differential-settlement screening explicitly. Pick the scenario that matches the client's vocabulary; the wrong frame makes an accurate report feel foreign.

Step-by-step usage

1. Run the analysis chain first: convert velocities, classify hazards, validate against GNSS if available. The Data Tray accumulates the results as you go.
2. Open this tool, choose the scenario, and fill the identification fields — project, location, period, sensor and track, author. These feed the header and the site-and-data section verbatim.
3. Write the key observations in your own words. This is the section the generator deliberately cannot write for you: it carries your site knowledge, and everything around it is scaffolding.
4. Generate and read the preview end to end. Edit in place if your workflow allows, or copy the Markdown into your document system and edit there. The downloaded .md file keeps the same content.
5. Attach the tool exports (classified CSV, KML, validation pairs) as appendices — the methodology section references them by name.

What the generator writes — and what it refuses to

The generator writes: the section skeleton; neutral methodology sentences naming the tools and their documented screening criteria; a statistics paragraph assembled from the Data Tray (point counts, velocity ranges, class distribution, validation metrics — whichever are present); a limitations section with the site's standard verification language; and a recommendation block with placeholders your judgement must fill. It refuses to write conclusions — no "the site is safe", no "no significant subsidence was detected" filler. Absence of detected motion in a screening dataset is a statement about the dataset as much as the ground, and the limitations section says exactly that. If your findings warrant a stronger statement, that statement is yours to write, own and sign.

Common pitfalls & mistakes

• Submitting the draft unedited. The placeholder fields left in a delivered document are the fastest possible way to lose a client's trust. The generator marks them clearly; search for the markers before sending.
• Statistics without context. A class distribution quoted without the criteria package and neighbour radius is not reproducible. The generated methodology section carries them — keep it.
• Report drift from the data. If you rerun the analysis after generating, regenerate the report. The injection is live at generation time only; stale numbers are the classic audit finding.
• Scenario borrowing. Using the mine template for a railway client because it sounds more thorough confuses reviewers. Match the frame to the asset.

Frequently asked questions

Which statistics get injected automatically?

Whatever the Data Tray holds at generation time: dataset names, point counts, and — when the dataset carries vertical velocities — the velocity range and mean. Validation and classification metrics appear if you have run those tools on the same tray data.

Can I edit the generated Markdown before export?

Copy it into your editor — that is the intended flow. The preview is read-only to keep the generation deterministic.

Does the disclaimer satisfy my professional liability requirements?

It is careful, standardized screening language — not legal advice. Your professional framework and jurisdiction govern what else the deliverable must state.

Why Markdown and not Word?

Markdown pastes into every authoring system, survives copy-paste without corruption, and keeps the deliverable diff-able in version control. Convert to Word at the end of your own workflow.

What if my campaign used only part of the workflow?

Generate anyway and edit the methodology section to describe what actually ran. The skeleton is deliberately tolerant: a note that covers conversion and classification without GNSS validation is a legitimate screening deliverable, as long as the missing verification is acknowledged in the limitations section rather than hidden. What the skeleton will not do is retroactively claim steps that did not happen — the methodology text you keep is the one you can defend.

Is the generated report stored anywhere?

No. The text exists in your browser's memory until you close the tab; download or copy it before leaving the page.

Related tools

This is the workflow's last stop: LOS Converter → Hazard Classifier → GNSS Validation → Error Budget → this report. The Workflow page shows the full pipeline with every quality gate.