LS — Trust Layer for AI Software Delivery

Inspiration

AI can generate, review, and modify software faster than ever. But faster delivery creates a new trust problem: an approval may have been created for an older commit, a reviewer identity may be missing or untrusted, or a required validation lane may never have run.

A pipeline should not deploy software simply because an approval exists. It should verify that the approval belongs to the exact code being released.

That idea inspired LS — Trust Layer for AI Software Delivery.

What it does

LS evaluates delivery evidence before it can influence a release decision.

It verifies:

the exact expected commit SHA;
whether review evidence belongs to the current commit;
reviewer provenance;
required review lanes;
deterministic reason codes;
complete PASS, FAIL, and NOT_RUN handling.

LS fails closed when evidence is stale, incomplete, or cannot be trusted.

Example blocked outcomes include:

ONLY_STALE_REVIEW_EVIDENCE
REVIEWER_PROVENANCE_MISSING
REQUIRED_LANE_NOT_RUN

When the commit, reviewers, and all required checks match, LS returns a trusted result.

The core idea is simple:

attack → detect → block

How we built it

The project was built as a focused developer-security workflow using:

Python;
pytest;
Docker;
GitHub Actions;
OpenAI Codex with GPT-5.6.

The verification engine produces deterministic trust decisions from normalized evidence.

We created adversarial fixtures covering stale approvals, missing reviewer provenance, missing validation lanes, exact-head changes, and valid current-head evidence.

The Docker clean-room workflow:

resolves the exact source SHA;
checks out that exact commit;
verifies git rev-parse HEAD;
runs the focused tests;
builds the Docker image;
runs the project inside the container.

Codex with GPT-5.6 was used to independently inspect and harden:

exact-head SHA binding;
reviewer provenance handling;
deterministic reason-code generation;
required-lane PASS, FAIL, and NOT_RUN behavior;
fail-closed security boundaries;
focused tests;
Docker clean-room reproducibility;
judge-facing documentation.

The final independently audited commit was:

f7109d4123c874b6a7e8cdb5b883d30be99c408a

Challenges we ran into

One of the hardest problems was separating the existence of evidence from the validity of evidence.

An approval can exist but still be unsafe because:

it refers to an older commit;
its reviewer provenance is missing;
one of the required lanes did not run;
the expected head changed during evaluation.

We also needed to preserve the difference between FAIL and NOT_RUN. Treating a missing check as successful would create a dangerous trust bypass.

Another challenge was reproducibility. A judge should not need the developer’s local environment to verify the result. We solved this with an exact-source-SHA Docker workflow running in GitHub Actions.

Finally, we used Codex CLI with GPT-5.6 for an independent final audit. The session verified the exact PR commit, executed the focused tests, reviewed the security properties, and confirmed the successful Docker workflow evidence.

Accomplishments that we're proud of

Built a working exact-commit trust gate for AI software delivery.
Implemented deterministic, fail-closed security decisions.
Covered stale evidence, reviewer provenance, and required-lane failures.
Passed 17 focused tests.
Reproduced the project through a clean Docker workflow.
Verified the exact source SHA before testing and building.
Completed an independent Codex and GPT-5.6 audit.
Created a public demo that explains the problem and solution in under one minute.
Kept the project focused without adding autonomous merge or deployment authority.

What we learned

We learned that AI software delivery needs more than automated reviews. It needs verifiable evidence connected to an exact software state.

A review is only meaningful when the system can answer:

Which commit was reviewed?
Who produced the evidence?
Which required checks ran?
Did any relevant state change?
Can another person reproduce the same result?

We also learned that deterministic reason codes are important. They make security decisions easier to test, audit, automate, and explain.

Codex with GPT-5.6 was especially useful for challenging assumptions, identifying trust-boundary risks, strengthening tests, and independently validating the final implementation.