Skip to documentation
eli.aidocs

Platform

Reports & PDF deliverables

The consulting deliverable: a client-ready report that captures the state of the knowledge base as of a moment in time — coverage, interview priorities, KPIs, top entities, and gaps — persisted as an immutable snapshot, rendered to PDF with print CSS, and reproducible months later because every snapshot is stamped with the layout version that produced it.

The pipeline

schedule → generate → render → download.

As-of snapshots

A report is not a live query. Generating one computes each section against the KB at that instant and persists the result as a report_snapshots row — the numbers in a report you hand a client in March are still the numbers when they reopen it in September, regardless of how the KB has grown since. Each snapshot carries:

  • Coverage — topic-level completeness against the ontology, with the same scoring used by coverage & gap analysis.
  • Interview-next — the ranked list of people/topics to interview next, so the report ends with an actionable plan rather than a diagnosis.
  • KPIs — document counts, entity and relation counts, answer-quality metrics, and their deltas since the previous snapshot.
  • Top entities— the most connected and most cited entities, the "who and what matters here" view.
  • Gaps — the coverage holes and stale areas, ranked by impact.

Reproducibility stamping

Data alone doesn't make a report reproducible — the presentation has to be pinned too. Every snapshot is stamped with the layout version of the report template that rendered it and the generation timestamp. When the template evolves, old snapshots keep rendering with the layout they were generated under, so a re-download is byte-for-byte the same deliverable the client already has.

Why this matters in consulting

An engagement report is often the paid artifact. If a client asks "where does this number come from?" six months later, you can re-open the exact snapshot — same data, same layout, same timestamp — instead of reconstructing an approximation from a moving KB.

The knowledge-graph map

Each report embeds a server-rendered SVG map of the knowledge graph — communities, top entities, and their relationships laid out server-side and serialized as static SVG. Because it is plain SVG rather than an interactive canvas, it prints crisply at any scale, needs no JavaScript in the rendered PDF, and is identical in the browser preview and the printed page.

Print CSS → PDF

The report page is styled with dedicated print CSS — page breaks between sections, running headers with the workspace and snapshot date, and print-safe colors. PDF rendering is exactly that page printed by a headless browser: the worker drives Playwright (Chromium) against the snapshot's print view and stores the result, recording the file location on the snapshot's pdfPath.

One render at a time

PDF rendering runs on the worker's concurrency-1 Playwright queue. Headless Chromium is memory-hungry, so renders are serialized: one browser, one render at a time, every other job waits its turn. A burst of scheduled reports queues up rather than exhausting the box.

Scheduled reports

Reports join drift scans and eval canaries as a first-class schedule kind: scheduled_jobs rows with kind: "report" generate a snapshot and enqueue its PDF render on a cron cadence — a Monday-morning client report that is already rendered when you open your inbox. Scheduled report runs count against the workspace's workspace monthly spend cap like any other scheduled work.

report schedule (cron)text
0 6 * * 1     # Monday 06:00 — weekly engagement report, PDF ready by morning
0 6 1 * *     # 1st of month 06:00 — monthly board snapshot

Related