Product
An investigation you can read back
Production Master turns approved production signals into a cited report: a conclusion, the exhibits under it, and a proposed action that waits for a human.
Product walkthrough
Ninety seconds, one real run
One incident, alert to approval gate. It arrives from Jira and is triaged into a run on its own; specialist agents gather the metrics, logs, deploys and code behind it; the findings become numbered citations; and the one irreversible action waits for a second person to co-sign before anything touches production.
16:9 · 1:30 · no audio — the on-screen captions are part of the recording
Synthetic data · a sample investigation, not a customer's
A payments webhook starts returning 5xx in the EU region after a deploy. Production Master reads the deploy diff, the metric series and the logs, and finds a signature-verification flag that shipped true with the same rollout — every claim in its report linking back to the exhibit it came from. It proposes a Helm rollback, classifies it as irreversible, and holds it until a second approver co-signs.
Would rather read than watch? Step through the same incident in text.
Interactive walkthrough
Follow one incident from signal to gate
The evidence workspace below uses synthetic data to show the reading order: what happened, what was tested, and where a human takes over.
checkout-api · 14:23–14:31 UTC
Checkout p99 rises at a83f9c
The synthetic checkout-api p99 series increases from 410 ms to 2.9 s immediately after the deployment window.
The deploy diff and pool log are filed
DB_POOL_MAX changes from 80 to 20, followed by pool.acquire timeout events recorded at active=20 and idle=0.
Pool exhaustion becomes the lead
The investigation proposes that the lower pool limit holds requests until the two-second acquisition timeout.
Cache degradation is tested and rejected
Synthetic cache hit rate stays within baseline and upstream latency does not change during the incident window.
The config change is the leading cause
Pool timeouts begin after the deployment and then saturate at the new configured maximum of 20 connections.
The rollback waits for engineer review
Restore the previously reviewed DB_POOL_MAX value, observe p99 and pool errors for ten minutes, then record the result.
Three commitments
The same three on every investigation, each one visible in the artifact the product produces.
“How would it know?”
Gathers, then cites
Every log line, metric window, deploy diff and config change it reads becomes a cited exhibit. Nothing enters the report uncited.
claim → E-01…E-03 → raw source
“What if it’s confidently wrong?”
Shows what it rests on
The explanation it settles on is recorded with the exhibits that support it, so you can check the reasoning instead of trusting the verdict. PM-SAMPLE-001 keeps its rejected alternatives the same way.
considered · rejected · why
“Is it going to touch my production?”
Stops at the gate
It proposes the change and waits. Remediation is a decision a human makes, holding a report they can check line by line.
A-01 proposed → awaiting approval
Every claim, a raw source
A claim carries a footnote to the exhibit; the exhibit points at the log line, metric window or diff it was cut from. Select an exhibit in this figure to follow the citation.
Connection-pool exhaustion introduced by a deployment configuration change.
cites [E-01, E-02, E-03] · challenged by [E-04] · 87% sample confidence
checkout-api p99 increases from 410 ms to 2.9 s immediately after the deployment window.
Relation to the claim — Establishes the incident onset and timing, but not yet the cause.
DB_POOL_MAX changes from 80 to 20 in the deployment values file for checkout-api.
Relation to the claim — Provides a falsifiable mechanism for request queueing.
pool.acquire reports timeout_ms=2000 with active=20 and idle=0 for the whole window.
Relation to the claim — Directly supports exhaustion at the new configured limit.
Cache hit rate remains within baseline and upstream latency does not change across the window.
Relation to the claim — Challenges and rejects cache degradation as the leading cause.
E-02, Deploy diff · a83f9c. DB_POOL_MAX changes from 80 to 20 in the deployment values file for checkout-api.
From alert to answer
The stages the investigation moves through, where it can stop, and where it is required to, are on the platform page.
See the investigation pipelineA rejection is a result
In PM-SAMPLE-001 every hypothesis stays in the record with its verdict and the exhibit that produced it.
What ships today records the explanation it settled on and the exhibits under it.
The product stops before production
Production Master prepares a remediation and the evidence for it, then holds.
Applying the change is an action a person takes, on a report they can check line by line.
There is no autonomous remediation path and no configuration that creates one.
Restore the previously reviewed DB_POOL_MAX value, observe p99 and pool errors for ten minutes, then record the result.
Connectors are scoped to read. Proposing a change and applying one are different actions, taken by different parties.
- 01Read the finding against the exhibits it cites.
- 02Check what was ruled out, and on which exhibit.
- 03Apply the change yourself, or send it back.
Production Master prepares the action and its evidence; it never executes a production change without approval.
Read one investigation before you believe any of this
The evidence workspace is the whole product story — citations, the exhibits under the conclusion, and the approval gate.
Self-host via Helm — available now to closed-beta teams.