What would you try to verify first?

[mikeholownych]

Context

This repository intentionally avoids features, agents, and UI.
Instead, it makes a narrow claim:

A small kernel can record automation workflows in a way that allows independent verification of what happened, after the fact, without trusting the tool.

That claim is supported by two worked examples (“wedges”):

Shipping a production change

Writing an incident postmortem

Both use the exact same kernel calls, event model, and evidence structure.

The question

If you were approaching this repo as a skeptic:

What would you try to verify first?

Examples (not exhaustive):

Whether the hash chain actually detects tampering

Whether artifacts can be substituted without detection

Whether the evidence bundle is reproducible and inspectable without custom tooling

Whether failure scenarios are handled with the same semantics as success

Whether the examples quietly rely on trust or convention rather than proof

How to engage

You do not need to adopt anything or run it in production.

If you try to verify something:

Say what you attempted

Say where it was clear

Say where it was confusing or fragile

Say where you expected it to fail but it didn’t

Negative feedback and skepticism are explicitly welcome.

Non-goals (to save time)

This project is not trying to:

Be a full automation platform

Compete with agent frameworks

Provide a SaaS or hosted service

Optimize for developer convenience over verifiability

If something feels “too boring” or “too strict,” that may be intentional—but call it out anyway.

Pointers

Start here: docs/wedges.md

Each wedge README includes step-by-step verification instructions

Evidence bundles can be inspected with standard tools (sqlite, unzip, sha256sum)

If you only have time to test one assumption, pick the one you least trust and start there.