Publishing Long-Form Reports Alongside the Web App

Reports are not APIs

Readiness narratives, executive summaries, and integration matrices are often authored as static HTML or Markdown. They age like documentation: useful for humans, not a substitute for live verification (tests, gates, OpenAPI).

Making them reachable

If users should open reports in a browser without cloning the repository, copy (or build) the static files into the web app's public tree. That yields stable URLs such as /reports/.../index.html on the same host as the product site.

Keep a single source of truth in the repository for edits, then sync to public during release or in CI so production does not drift from the canonical folder.

Link from docs

A short docs page that lists the index, major sections, and "how to update" reduces support questions. Link related API and proxy docs so readers know where to go for behavior, not just commentary.

What we avoid putting in public reports

Treat public bundles as non-sensitive summaries. Do not embed credentials, private customer data, or unreleased roadmap details. If a report was generated from internal-only inputs, strip or redact before publishing.