How it works

Did the work match what was declared?

Every run in your systems makes a claim. A deploy claims it shipped. An agent claims it finished. A pipeline claims it passed. Mindplane checks that claim against what was actually observed, then records the difference.

That difference is the product. Everything else is how the difference is produced, stored, and read later.

The declared path, and the observed one

For a governed run, Mindplane can compare two paths. The declared path is what the run was expected to do: the steps, the order, and the tools involved. The observed path is what actually happened: the events that fired, the order they appeared in, and the tool or system each event came from.

Mindplane diffs them. The result is a single view of how much of the declared path was matched, and exactly where reality went a different way.

WORKFLOW deploy-auth-svc v3 declared 5 steps CONFORMANCE 60% 3 of 5 matched, 2 deviations ✓ build matched ✓ test matched ✓ push image matched ✗ verify replicas missing ! notify on-call out of order

The agent said five steps. Three were observed. The receipt shows the two that were not. No reading logs. No reconstructing from five dashboards that disagree. No accepting success as proof.

The correlation spine

Real work crosses tools. A single change can touch a commit, a deploy, an alert, an agent action, and a ticket. Mindplane threads those events onto one correlation ID, so the run becomes one timeline instead of six tabs.

Ask for a correlation ID and you get the run end to end, in the order it happened, with the source of each event named. That is the difference between “something broke around 2am” and “here is the step where reality diverged from the declared path, and here is what changed before it.”

The receipt

Every check Mindplane runs leaves a receipt. A receipt is not a log line. It records:

claimed what the run said would happen observed what actually happened, from ingested events decided what Mindplane concluded, and on what basis evidence where the truth came from, with a hash to check later

Receipts are the exhaust of the work, not a separate reporting step. They accumulate. Over time, they become the record you query when you need to know what was true, not just what was reported.

It reads its own record back

Receipts are not write-only. The point of recording truth is that something later can act on it.

Given a correlation ID, Mindplane re-assembles the run. Given a past decision, it can recompute whether that decision still holds under the policy and evidence in effect now. Given the ledger, it can verify the record has not been altered since it was written. The same record that proves what happened is the record the next action reads before it moves.

This is the difference between a log you grep when something has already gone wrong, and a record the system consults before it does the next thing.

Why this is different

Most observability tools record what happened after the fact. Mindplane checks the claim at the point of action: a policy would have blocked an action, Mindplane records that in observe-only mode first. A run reports success but skips a declared step — the receipt shows the deviation, not a reconstructed guess from logs.

Change the input and it tells you a different truth instead of protecting the story. That is the test the product is held to.

Where you read all of this

Today, through the cog command line and the API. Given a correlation ID, cog corr get returns the assembled run, the declared-versus-observed diff, and the receipt.

Mindplane runs in observe-only first. It can show what it would have caught before it blocks anything, so teams can see the truth layer before asking it to enforce.