Purchase this theme on shadcnblocks.com
Meridian®
Contact us
Workflows

Auto-postmortems.

How Meridian drafts the post-mortem before you open the laptop — and how to teach it your team's voice.

What it does

When a budget event closes, Meridian collects the relevant signals, diffs against the last known-good window, and drafts a post-mortem in your team's standard format. The draft sits in Incidents › Drafts for review before anything is published.

It's never sent to a customer without a human pressing the button.

Note

The point of the auto-draft isn't to replace the post-mortem. It's to remove the blank page so the human can start with editing rather than remembering.

The lifecycle

  1. 01
    /05
    Burn

    A budget event fires. The window context, the responsible service, and the on-call engineer are recorded into the incident record.

  2. 02
    /05
    Collect

    Meridian pulls every signal that touched the affected service during the burn window — logs, traces, deploys, feature-flag flips, pipeline edits, runbook openings. Nothing is filtered yet.

  3. 03
    /05
    Diff

    Each signal stream is diffed against the same window from the previous seven days. Anything outside two standard deviations is tagged as a candidate cause.

  4. 04
    /05
    Draft

    A natural-language draft is written into your team's template. Sections that the system can't fill confidently are left as a TODO with the candidate evidence linked.

  5. 05
    /05
    Review

    The on-call engineer opens the draft, edits, signs off. The published copy goes to the channel of your choice (Slack, GitHub Discussions, Notion, email).

Configuring your team's template

The default template covers Summary / Timeline / Contributing causes / What went well / Action items. To use your own, drop a markdown file at templates/postmortem.md in your workspace config repo with {{...}} placeholders for the system to fill.

Prose
# {{title}}

**Severity:** {{severity}} · **Window:** {{start}} → {{end}}
**Service:** {{service}} · **On-call:** {{oncall}}

## What happened

{{summary}}

## Timeline

{{timeline}}

## Contributing causes

{{causes}}

## Action items

{{action_items}}

What it can fill, and what it can't

  • The exact start and end of the burn window - The service and budget that crossed the threshold - The deploys, flag flips, and pipeline edits in the window - The traces with the largest duration deltas vs the baseline - The log levels and counts that diverged from baseline

Tuning the model's voice

Meridian uses a small fine-tuned model that runs inside your tenant. To adjust its voice, drop reviewed post-mortems into templates/voice/ — the model retrains nightly against the latest 50 examples.

Shell
meridian voice add ./latest-incident.md
# → added · 50 examples in voice corpus · retrain queued for 02:00 UTC
Caution

Voice tuning never sees data outside your workspace. The model weights live in your tenant's KMS, the training data never leaves your region, and we don't keep a copy.

Guarantees

  • The draft is never auto-published. A human signs every release.
  • The model is tenant-isolated. It does not learn across workspaces.
  • The data used in drafting is inside your retention window — if you shortened retention to 7 days, the model has 7 days of context.
Workflow ready