# PostMortem AI Canonical product: https://www.nanoneuron.ai/ Docs: https://www.nanoneuron.ai/docs Full reference (API surface, architecture, verified behavior): https://www.nanoneuron.ai/llms-full.txt Contact: vish.matale@gmail.com Last factual review: 2026-08-30 ## What this is An incident postmortem tool: record evidence about an incident, generate an AI-drafted postmortem, publish it once a named human approves. Signed-in users only -- account required (email + password). A forgotten password can be reset via a real emailed link (Resend) -- a single-use, 30-minute token, sent only if the address belongs to a real account, though the request endpoint never reveals which case it was. ## The core guarantee: grounded drafting, not free-text generation Every postmortem draft is produced by a two-layer process, not a single unsupervised model call: 1. The drafting model is given the incident's recorded evidence entries, numbered, and instructed to cite the entry number behind every claim it makes, and to leave a section unsupported rather than infer beyond the evidence. 2. Independently of what the model says about its own citations, code verifies every citation against the real evidence list before anything is stored. A claim with no valid citation (missing, out of range, wrong type) is replaced with a fixed "Not established by the recorded evidence." marker for the four required sections (summary, root cause, detection, resolution), or dropped entirely for optional lists (contributing factors, suggested actions). This verification step can only remove or replace text the model produced -- it never adds new text of its own. A published postmortem always records who approved it and when; the database itself refuses to mark a postmortem published without a named approver on record. ## RAG: similar past incidents as reference context When drafting, the system retrieves the account's own previously published postmortems that are semantically similar to the current incident (via embeddings) and shows them to the model as reference context, clearly labeled as non-evidence. The grounding check above only ever validates citations against the current incident's own numbered evidence, so a retrieved past incident can never become the source for a claim. ## MCP The backend exposes an MCP server with tools for founders (platform summary, payment-claim review, a defense-in-depth read-only SQL tool) and clients (incidents, evidence, drafting, publishing, similar-incident search) -- the same business logic and authorization as the REST API. The frontend federates to it under the caller's own session. ## Webhook ingestion Evidence can also arrive automatically: every account has a real, rotatable webhook URL (its own account settings) that any external tool (a monitoring alert, a script, a CI job) can POST JSON to. It creates a new incident, or appends evidence to an existing open one the caller already has the id for -- the same write path and paywall as the authenticated app, just authenticated by a per-account token instead of a session cookie. The accepted shape is deliberately generic: `summary`, `detail`, an optional `incident_id` to group related events, and `source`, which is a fixed evidence-*type* category (`alert`, `log`, `deploy`, `metric`, `human_note`, or `customer_report`) rather than the sending tool's name -- put the tool's name in `summary`/`detail` instead (e.g. `"summary": "Datadog: checkout error rate spiked to 40%"`). Two monitoring vendors have real, documented setup paths beyond "any tool that can POST JSON": PagerDuty has a dedicated adapter endpoint (`/v1/webhooks/pagerduty/{token}`) that parses PagerDuty's own v3 webhook payload directly -- point a PagerDuty v3 webhook subscription at it and `incident.triggered`/`incident.acknowledged`/`incident.resolved` events create, and later resolve, the matching incident automatically, tracked by PagerDuty's own incident id. Datadog's webhook payload is entirely user-templated on Datadog's side (it has no fixed schema to adapt to), so its integration is a documented JSON template for Datadog's own webhook payload field, pointed at the generic endpoint above -- see account settings for both. ## Reliability and anti-abuse A circuit breaker (closed/open/half-open) wraps the drafting model -- after repeated failures, further calls fail fast instead of hammering an unhealthy provider. Gemini is the primary drafting/extraction model; Claude is used as a real fallback provider (not just a described one) when configured, reached only when Gemini's own call fails or its circuit is open -- each provider has its own independent circuit breaker. Login is rate-limited per account and per IP; creating incidents and drafting postmortems are separately rate-limited per account. Registration and login can require a CAPTCHA when configured. ## Payments Every account may create and fully work on one incident for free -- record evidence, run AI evidence extraction, draft a grounded postmortem -- with no payment. Publishing (making it a permanent, citable record) and creating a second incident both require an active subscription. For clients in any country, an international SWIFT wire (USD/GBP/EUR) or UPI (India) works today -- submit the transaction reference and the founder reviews and approves it personally. Self-serve card payment via Stripe Checkout is built (and self-serve subscription management via the Stripe Customer Portal) but not yet switched on for real payments -- it appears automatically once it is, with no other change needed here. An account that used its free incident, got a real draft out of it, and never subscribed receives exactly one automated reminder email, at least 24 hours later -- never a repeat, and never a fabricated urgency claim (no countdown, no "X spots left"). Not happy after subscribing? Email vish.matale@gmail.com within 14 days of your first charge and it's refunded -- the founder processes it personally, the same manual review as approving a payment in the first place. ## What it does not do - Does not auto-publish anything -- publishing is always a deliberate, named human action. - Does not estimate cost, revenue, or customer-impact figures the evidence didn't state, and the system prompt explicitly instructs the drafting model not to. - Has real, documented setup paths for PagerDuty and Datadog (see Webhook ingestion above) but not for other monitoring vendors -- any other tool can still be pointed at the generic webhook endpoint, un-adapted. - Does not support multiple people on one account or organizations -- each account is a single user's own incidents. ## Access & discovery - Public marketing/landing/docs content is intended for indexing; every account-scoped page requires authentication and is not meant to be crawled or indexed as public data. - No API keys, credentials, or account-specific data are ever exposed in public pages or this file. ## Commercial scope This is an active MVP under continued development, not a finished commercial product with support commitments. Capabilities described here reflect what is actually implemented as of the review date above.