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] · Illustrative sample, no confidence score
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 — Contradicts 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, the reason for it and the exhibits it cites.
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.
By default each remediation needs its own approval from a person, on a report they can check line by line.
The one exception is a grant: time-boxed and revocable, it records that a named person pre-approved one kind of low-risk action for one investigation.
Every consequential action waits for a named person: anything above read-only in production, and every high-risk or irreversible action anywhere, with a second approver for irreversible production actions.
Read-only and non-production low-risk actions run automatically, and report-bearing ones only to destinations your organisation has approved.
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 set aside, and why.
- 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 in closed beta.