AI assurance · GitHub evidence · TypeScript
One change.
No invented assurance.
- Automated tests
- 21
- Evidence requirements
- 11
- GitHub event classes
- 3
- Persistence
- D1
Assurance is a correlation problem before it is a dashboard.
Software teams already produce evidence: change requests, reviews, workflow runs and commit identifiers. The dangerous step is collapsing those facts into a reassuring status without proving they describe the same repository, revision and required control.
The engine preserves those boundaries. It authenticates the event, normalizes only supported facts, correlates by exact identity and evaluates each requirement independently. The output is useful precisely because it can say missing, failed or unknown.
From an external event to an inspectable decision.
- 01Observe
Receive pull request, review and workflow events with their delivery identity and raw request body.
- 02Verify
Authenticate the payload and reject malformed, unsupported or conflicting deliveries before trust expands.
- 03Correlate
Resolve evidence against the exact repository, pull request and commit SHA required by the change.
- 04Evaluate
Compute an ordered snapshot across eleven requirements and expose the evidence behind every result.
Facts that look similar are not interchangeable.
The implementation is organised around the exact places where an assurance system can accidentally overclaim.
Webhook authenticity
Verify the HMAC signature against the unmodified request body before parsing or persisting an event.
Delivery identity
Use GitHub delivery identifiers for retry-safe ingestion and reject a repeated identifier when its payload conflicts.
Exact correlation
Join pull requests, reviews and workflows only when repository identity and commit SHA match the declared change.
Workflow allowlist
A successful arbitrary workflow is not proof. Only an explicitly required workflow can satisfy its control.
Approval semantics
Merge state, change scope and review approval remain separate facts. One cannot silently stand in for another.
Deterministic output
Equivalent evidence produces the same ordered snapshot and digest, making changes inspectable and replayable.
Small architecture, explicit contracts.
What the implementation proves today.
01Authenticated ingressTests verify valid signatures and rejection paths against the original request bytes.
02Retry safetyRepeated deliveries are idempotent, while reused identifiers with different payloads are treated as conflicts.
03Strict correlationReviews and workflow runs cannot satisfy a requirement for a different repository or commit.
04Stable evidenceSnapshot ordering and digests are deterministic so the same facts produce the same result.
05Bounded claimsThe live system demonstrates the implemented pipeline; it does not claim a real organisation has connected production repositories or completed an independent audit.
Implemented is not the same as operationally proven.
The webhook path, persistence model and evaluation logic are implemented and tested. A real GitHub repository, production webhook secret and organisational workflow policy are not configured in the public portfolio environment.
A production adoption would still need repository onboarding, secret rotation, retention policy, access review, alerting, load tests and an independently reviewed control definition. The engine supplies evidence; it does not certify the organisation that uses it.