A version check can’t see order
In the demo above, a version-only check passes the rollback that ran its steps out of order. The log points at the current runbook version, but says nothing about the order the steps were followed in.
For platform, SRE, and operations teams
Documentation says one thing. Operational data says another.
Ecdotic compares documented procedures with what actually executes, shows evidence behind any divergence, and drafts corrections for human review.
- Checks Procedure Execution, Not Just Version
- Evidence on Every Result
- You Decide What Changes
Demo
Watch a Runbook Review
A demonstration of an Ecdotic run on synthetic data: a rollback runbook and sample deploy logs. The results, times and file hashes come from the run.
Read the replay as text
The problem
Procedures Drift Quietly
Runbooks get edited, workarounds become habit, and nobody reconciles the two until something goes wrong.
The record already exists
Deploy, rollback and incident logs show what people actually did. Checking them against the runbook by hand is slow, and when it does happen, it’s usually after a critical failure. Why wait?
Automation inherits the drift
As more operational work runs through scripts and AI agents that read your docs, a stale procedure gets repeated instead of questioned, and the effects compound into organization-level failures.
How it works
Three Steps: Users Make the Final Decision
-
01 Input
Share a procedure and its record
A runbook, plus the deploy, rollback or incident log for the times it ran. Exports are fine. Finding divergence only needs read access.
-
02 What Ecdotic finds
Steps are lined up with events
Ecdotic selects the procedure version in effect, matches each step to recorded events, and returns one of three results:
Matches Diverged Insufficient Evidence
-
03 What you get
Evidence you can check, and a draft
Each result cites the runbook lines and log events behind it. For a divergence, Ecdotic drafts a correction and the owner decides whether it becomes the procedure.
Trust
How Ecdotic Earns Trust
Ecdotic observes what actually happened. Your team decides what becomes the procedure. How much Ecdotic does between those two is up to you.
Read-only is enough to start
An evaluation reads the procedure and the logs you share, and read-only remains a supported way to run Ecdotic. Further permissions only enable actions you authorize, such as publishing an approved correction.
Evidence on every result
Every result cites the exact runbook lines and log events it used, with a hash of each input file.
“Unknown” is an answer
If the log is missing events, the result is insufficient evidence. A missing event is never treated as a skipped step.
A finding isn’t an authorization
A divergence shows that the runbook and the record disagree, not which one is right. The owner decides what becomes the procedure. Detecting a discrepancy never authorizes a change on its own.
Your data, on your terms
Demos use synthetic data only. Before you share anything real, you get a one-page statement of what’s stored, where, for how long, and how it’s deleted.
No tracking on this site
This site sets no cookies and loads no third-party scripts, fonts or analytics. The booking calendar is Calendly’s, shown in its own frame.
From Finding to Fix: At the Level You Choose
If a correction is right, you shouldn’t have to copy it into documentation yourself. Ecdotic is built to carry a fix from evidence to a published procedure, with each step authorized by you.
Starting point Read-Only Evaluation
- Ecdotic examines the evidence and presents findings with a proposed correction.
- This is what runs today, on synthetic data.
Direction Approval-Based Updates
- An authorized owner reviews a specific change. Ecdotic publishes it, or submits it through your existing review workflow.
- The evidence and history stay attached to the change.
To validate Update Automation
- You permit defined categories of change within explicit limits. Anything outside them is escalated to the owner.
- A later capability we’ll prove out first, not a blanket promise of autonomy.
Who’s behind it
Aidan Ehrenhalt, Founder
A computer engineer from Georgia Tech with a background in AI, ML, and data engineering. I run every walkthrough myself. You’ll talk directly to the person building Ecdotic.
Evidence
Where the Evidence Stands
Ecdotic is early. Here’s what’s been shown, what hasn’t, and what’s next.
Shown on synthetic data
- Compares versioned procedures with execution logs, identifying a match, a divergence, or insufficient evidence.
- Selects the procedure version in use and maintains source references and file hashes with each result.
- Records a reviewer’s decision and drafts corrections without making procedural changes.
Not yet shown
- Results on live runbooks and telemetry. We keep customer data private and secure. A production demo is available given a set of your own data.
Testing next
- A time-boxed, read-only evaluation on your team’s real procedures and its deployment, rollback, or incident history.
- An independent review of each finding before we claim anything actionable.
FAQ
Questions Teams Ask First
What does Ecdotic need access to?
A procedure, such as a runbook in Markdown, and the execution record for the times it ran: deploy, rollback or incident logs. Exports are fine. Read-only access is enough for an evaluation and remains a supported way to run Ecdotic. Additional permissions only enable actions you authorize, such as publishing an approved correction to your runbook.
Will Ecdotic change my runbooks?
Only with your authorization. Today Ecdotic drafts the correction and your team applies it. We’re building approval-based updates: once an owner approves a specific change, Ecdotic publishes it or submits it through your existing review workflow, with the evidence and history attached. Letting Ecdotic apply defined categories of change within limits you set is something we’ll validate first.
Is a divergence always a mistake?
No. It means the procedure and the record disagree. The runbook may be out of date, the execution may have departed from policy, or there may be an approved exception that isn’t written down. What happened isn’t automatically what should happen, so a person decides which side changes.
What happens when the logs are incomplete?
Ecdotic reports insufficient evidence and names the steps that have no matching events. It does not turn missing events into a finding.
How is this different from a “last reviewed” date?
A date tells you when a page changed, not whether anyone follows it. Ecdotic compares instruction steps with what the logs recorded, including their order.
Is the demo real?
The replay shows a real run of Ecdotic’s evaluator on synthetic data: a sample rollback runbook and three sample deploy logs. The desktop around it is illustrative; today Ecdotic runs as a command-line tool that writes a report.
How do you handle our data?
Demos use synthetic data only. Before you share anything real, we agree in writing what is stored, where, for how long, and how it’s deleted.
Can we use Ecdotic today?
Ecdotic is early. It runs today on synthetic data, and we’re looking for the first teams to evaluate it on one real procedure. Book a walkthrough to see whether yours is a fit.
Book a walkthrough
See it on a runbook like yours
30 minutes with the founder. We’ll run the demo live, answer questions about access and review, and hear about a recent procedure that didn’t match what actually happened.
- A live demo on synthetic data, start to finish.
- Your questions about data access, evidence and review.
- If it fits, a plan for a time-boxed, read-only evaluation on one of your procedures.
Calendar not loading? Book on Calendly.