Short answer

Yes. Civic.ly's AI document analysis can read an inspection report (PDF or similar), extract the recommended work items (e.g. crown reduction, repollarding, deadwood removal), and surface them so a CS rep or council user can turn them into jobs against the relevant assets. This is distinct from AI auto-classify, which works on asset photos. Document analysis works on the textual content of inspection / survey reports.

Detail

The typical use case is a council that has commissioned an external inspection — most commonly an arboricultural (tree) inspection report — and now has a PDF listing dozens of work items spread across many trees. Manually reading the report and creating jobs is tedious and error-prone. Document analysis short-circuits this:

  • Input: the inspection report (PDF).
  • Output: structured list of work items pulled from the report (verb + asset reference + priority where stated).

What it's been demoed on so far:

  • Tree inspection reports — works well; pulled out crown reductions, repollarding, deadwood removal, and similar arboricultural verbs from a real council's report. Live demo on a real council's PDF is a strong moment in the conversation; the cemetery / tree officer typically has a stack of PDFs and can immediately see the value.

What it has not yet been validated on:

  • Play inspection reports — same shape (structured list of items per asset), so it should work; not yet stress-tested.
  • Building condition surveys, electrical / fire safety reports — likely workable but each has its own vocabulary, and accuracy will depend on how the report is structured.

Where this fits in the workflow

The natural moment to use document analysis is when a council is migrating off (or augmenting) a third-party inspection system. Three common shapes:

  1. Closing the Ezytreev / cemetery gap. A council has a tree inspection system that flags work, but the parks team can't easily confirm completion back to it. The fix: pull the outstanding work items out of the latest inspection report into Civic.ly as jobs, get the parks team to complete them in the app, and now the cemetery officer (or whoever owns the original system) has a single place to see what's been done.
  2. Onboarding a new tree-management cycle. Annual or three-yearly tree inspection commissioned, report comes back with hundreds of items — bulk-import via document analysis rather than typing each one.
  3. Backlog import. Council has a stack of historical reports they've never digitised. Document analysis is a fast way to make the backlog actionable rather than an "I'll get to it" pile.

Watch-outs

  • Report quality matters. Reports that are scanned images of typed text (rather than digitally-generated PDFs) work less well. If accuracy is poor, check the source: is the PDF text-selectable? If not, a re-export from the source system in a text-native format usually fixes it.
  • Each item still needs an asset to attach to. The AI extracts the work items but the council's asset register has to actually contain the trees / equipment those items reference. If the asset register is sparse, do a capture pass first. For trees specifically, see Should every tree be its own asset, or can I group them as a clump? for whether to model individuals vs groups.
  • Treat the AI output as a draft. Have the cemetery / tree officer review the extracted items before they're saved as jobs. The AI doesn't know the council's local context (e.g. that "T47" in the report refers to "the big oak by the war memorial").
  • Don't position this as a full replacement for an arboriculturalist. The AI is an extraction tool; it doesn't decide what work is needed. The expert assessment remains with the inspector who wrote the report.
  • Distinct from AI auto-classify. Auto-classify reads an asset photo and writes back name / description / condition — see What does AI auto-classify do, and what are the gotchas?. Document analysis reads a multi-page report and writes back work items. Don't conflate them in conversation with the council.