EventProof

Inspiration

A webhook can return HTTP 200 while crediting the same transaction more than once. Repeated deliveries, concurrent requests, and receiver restarts make this easy to overlook. Even a single database row can hide an incorrect credited amount. I built EventProof for developers who need inspectable evidence that their webhook consumer produced the expected business outcome.

What it does

EventProof is a synthetic credit-ledger testbed that replays five fixed scenarios:

• Single delivery
• Sequential duplicate deliveries
• Concurrent deliveries
• Replay after an orderly receiver restart
• Different events representing the same transaction An independent PostgreSQL observer checks delivery receipts, effect rows, and credited units against fixed expectations. The workspace lets developers inspect individual scenarios, compare a protected baseline with a deliberate regression, revisit run history, and export JSON evidence containing inputs, outcomes, source identity, and the receiver fingerprint. One revealing example: 16 deliveries produce one effect row, but 16 credited units instead of the expected one.

How we built it

The interface uses React, Vite, and TypeScript. The backend uses Go, PostgreSQL, pgx, and versioned SQL migrations. Docker Compose provides the local environment. GitLab hosts the MIT-licensed source and CI/CD workflow.

The demonstrated automation follows Path A — Assisted:

1. An intentionally broken candidate fails its PostgreSQL test.
2. A custom GitLab Duo Agent Platform flow inspects the merge request, diff, and original job log.
3. Duo diagnoses the duplicate-credit query and proposes a repair limited to the PostgreSQL adapter.
4. The repair is reviewed and applied in a separate commit.
5. CI verifies the recorded version.
6. A human triggers a review that binds approval to the exact commit, tested receiver, and evidence hash.

Duo performed the investigation and proposal. Applying the repair, running verification, and approving the demo remained separate steps

Challenges we ran into

The hardest issue was distinguishing a correct row count from a correct business effect. Counting rows alone would miss repeated credit, so the observer also checks credited units.

Another challenge was preserving traceability across investigation, repair, verification, and approval. Evidence identifies the tested source and executable so an earlier passing run cannot approve a later version.

Accomplishments that we're proud of

The hardest issue was distinguishing a correct row count from a correct business effect. Counting rows alone would miss repeated credit, so the observer also checks credited units.

Another challenge was preserving traceability across investigation, repair, verification, and approval. Evidence identifies the tested source and executable so an earlier passing run cannot approve a later version.

What we learned

Successful delivery is only part of correctness. The persisted business outcome must be checked independently.

AI investigation becomes more useful when it has concrete failure evidence, bounded permissions, and deterministic verification.

What's next for EventProof

I plan to expand the scenario library and explore crash-recovery testing while preserving fixed expectations and independent observation.

The current demonstration covers synthetic credits within PostgreSQL. External payments and general exactly-once guarantees are outside its scope.

The video includes a local UI preview. Historical CI and approval evidence applies specifically to recorded commit 8e3b34b8 and its tested executable.

Built With

• agent
• ci/cd
• compose
• docker
• duo
• gitlab
• go
• pgx
• platform
• playwright
• postgresql
• react
• typescript
• vite