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

Scheduled report generation

schedule → generate → render → download.

Rendering diagram

Downloads

Concepts

  • Capabilities
  • Reports
  • Report

Keywords

  • report_snapshots row
  • scheduled_jobs kind: report
  • generate snapshot
  • render PDF
  • pdfPath on the snapshot
  • in-app or link
  • coverage · KPIs · entities · gaps
  • concurrency-1 Playwright queue
  • schedule
  • persist
  • store
  • download
Source and generation provenance

Status: current

Generated at: 2026-08-12T23:41:47.390Z

Source hash: ba9dc3693ab1043cf33bcde31e7d4f064d896bd143e56cbb7cb351719fb7abc6

Metadata payload hash: 5c23f1bae262155fab281695f9241aeec3a94f5388206abf4f42a148dc722a62

Canonical appearance

src/app/(docs)/docs/capabilities/reports/page.tsx:30 route /docs/capabilities/reports

All appearances

  • canonical — src/app/(docs)/docs/capabilities/reports/page.tsx:30 route /docs/capabilities/reports

No mirrored appearances.

Generation versions

App: eli-ai 0.1.0

Mermaid: 11.16.0 · Mermaid CLI: 11.16.0

Node: v26.3.1 · Yarn: 4.17.1

Renderer config hash: 68c10966fe84406ee626034d58bfabd555df9f65f691204b7c46db24038da101

Renderer theme hash: c80287a78d80ad63d27bd5ca348b2ef9a7e2f44da289e436be6484ea28a1b033

Adapter versions: diagramGenerator=2, drawioFlowchart=1, drawioGantt=1, drawioSequence=1, drawioState=1

Full sidecar JSON: scheduled-report-generation-ba9dc369.json

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