Reports and write-ups live at their own address

The workflow

1. Collect the source material in the project folder or provide paths the agent can read. Separate primary evidence from interpretation. Remove secrets and decide what may be quoted, summarized or linked before asking for a polished page.
2. Give the agent a complete prompt: Create a weekly incident-pattern report for engineering leads. Build one page with an executive summary, a table of recurring failure modes, evidence links, confidence notes, three recommended actions and an appendix defining the method. Use only the supplied incident summaries. Mark missing evidence. Do not invent counts or causes.
3. Ask for a static page when the report is a dated snapshot. It needs the page and share URL, but no Postgres, login or scheduled job. Use a full app only when readers must query stored data. Add a schedule only when the source refresh and report generation are truly automated.
4. Review every number, attribution and conclusion against the supplied evidence. Make uncertainty visible. Check that external links and internal references go where the page says, and that the executive summary does not overstate the detailed findings.
5. Push the reviewed files, create a checkpoint named for the reporting period and choose public, password-protected or invited-person sharing. A Pro custom domain is optional for an established publication, not required for a useful first report.
6. Send the address to readers and ask them to comment beside unclear evidence or disputed recommendations. Let the agent read those comments and update the same workspace, preserving the report's address while its reasoning improves.

Setup

grain login
mkdir weekly-incident-report
cd weekly-incident-report
grain init
# Add source material and give the agent the report prompt.
grain push
grain checkpoint -m "incident report 2026-09-04"
grain share --password <pw>

Download the Mac app first. For this dated write-up, use a static page and a restricted share. It does not need Postgres, login or a scheduled job because the inputs are supplied for one reporting period. Use invited-person sharing if readers must be individually named. If the report later becomes a live data product, an app artifact can add Postgres and a scheduled refresh job, but that is a different operating commitment. A custom domain is available on Pro through CNAME. The default https://<slug>.share.rungrain.com address is enough to circulate and revisit the first report.

What you get

• A readable page with a real URL, rather than a long chat response that requires the original session for context.
• A deliberate structure for summary, evidence, method, uncertainty, recommendations and definitions, all visible to the same reader.
• A named checkpoint tied to the reporting period, while the artifact's workspace remains available for corrections and follow-up editions.
• An access mode that can be public, password-protected or limited to invited people according to the material's sensitivity.
• Comments on the report itself, which the agent can read and use to correct a table, explain a claim or qualify a recommendation.
• Files that remain exportable through grain pull, so the write-up is not locked inside a proprietary chat transcript.
• A clear upgrade path to Postgres, login, scheduled jobs and a custom domain only if the report becomes an ongoing application.

Proof

Use an evidence audit as proof. Select three claims from the summary and trace each to the cited source material. Open the shared address outside your own session, leave a correction as a reader and confirm the agent can read it. Close the laptop and revisit the URL after the coding session has ended. Grain's product surface supports the durable URL, comments and exportable files. It does not prove that the report's analysis is sound. That requires source checks, visible confidence notes and accountable human review. A good outcome is a reader who can inspect how the conclusion was reached without asking for the missing chat history.

Limits

• Publishing gives the report a home but does not validate its sources, arithmetic or causal claims. Review those before sharing.
• A static report is a snapshot. Date it and state the input period so readers do not mistake old findings for live data.
• Do not include confidential records, credentials or material outside the chosen audience. Select the access mode before distributing the link.
• Reader comments are inputs, not automatic corrections. Decide which feedback is accepted and review the agent's resulting changes.
• A scheduled report needs an owned data source, observable job output and a recovery plan. Do not add a schedule only to make the artifact seem current.
• Grain is not a general document editor or production deployment platform. Keep editorial governance and production operations in the systems that own them.

Frequently asked questions