Release assurance for AI-built software

AI-assisted software can go from prompt to production faster than a team can justify a release decision. The problem is not generating one more AI confidence score, it is preserving an honest answer to what was checked, what evidence exists and what still needs a human decision?

LyraShield AI makes that boundary visible:

Target → Scan → Evidence State → Fix Proposal → Retest → Assurance Report

A finding stays detected until independent evidence exists. A clean deterministic retest becomes retest-confirmed only when applicable coverage is complete. Otherwise the result remains inconclusive. The product never turns an AI suggestion, a high confidence score or an incomplete scan into proof.

Try the working product now

Judges can exercise the submitted public path without an account, rebuilding the repository, or paid services:

Open the live Lite Check. Enter lyrashieldai.com, confirm authorisation and the Terms, and run the check. Inspect the result and its stated limits. Compare the evidence states with the methodology and synthetic sample report. Login for advanced features like full REPO/URL scan .

To explore the full workspace, open app.lyrashieldai.com, create an account, add an authorised target, and start a review.

This is a deliberately bounded, passive browser-surface review: public assets, exposed-secret patterns, security headers, transport signals and supported data-layer markers. It uses no exploit payloads or database-table queries. That honest scope is intentional. The public demo is a useful working product, and the authenticated workspace supports repository review for registered users.

What I built during OpenAI Build Week

LyraShield existed before the event. I disclose the exact pre-event baseline—commit 72ba1e2—and request judges to evaluate the dated Build Week delta after the official July 13, 2026 start.

The meaningful extensions are:

Evidence integrity: immutable result manifests, coverage receipts, finding candidates, independent verification receipts and server-owned retests. A working public product: the live no-login Lite Check, direct-domain input, truthful one-pass progress, privacy-bounded scorecards and full REPO/URL/API scans. A complete experience: responsive dashboard navigation, evidence console, assurance reports and a guided review loop rather than a proof-of-concept screen. GPT-5.6 execution controls: model routing, per-request accounting and pre-request bounds on context, output, agent delegation, concurrency and spend. Failure-aware operations: worker heartbeats, fail-closed scan admission, orphan reconciliation and explicit queue recovery.

The public MIT-licensed repository includes the judge path, setup guidance, linked pull requests and the dated Git audit trail.

Why the implementation is different

A scan is asynchronous and failure-prone: cancellations, retries, budget stops, evidence-upload failures and worker loss must not silently become a clean result. LyraShield treats those cases as first-class product states.

At scan creation, the system retains an immutable manifest. Scanners record coverage receipts and bounded finding candidates. Only a separate verification receipt can mark a finding verified. Retests are server-owned rather than client-authored and clean deterministic retests require complete applicable coverage before they are called retest-confirmed. When a worker is unavailable, admission fails closed, Fix PR execution also remains blocked until a server-generated patch can be bound to an exact approval.

That creates a shareable decision record for founders and engineering teams shipping AI-built software: not “the AI says you are safe,” but the evidence needed to decide whether a release is ready.

How I used Codex and GPT-5.6

GPT-5.6-powered Codex sessions were the engineering collaborator for the Build Week extensions: tracing cross-package data flows, implementing focused changes, adding regression coverage, reviewing rendered UX, diagnosing CI and deployment failures and reconciling the documentation with the live behavior. I retained the core product decisions: evidence state instead of confidence-as-proof, deterministic public checks separated from the private engine and risky actions failing closed.

GPT-5.6 is also part of the controlled full-scan contract. Luna handles Safe, Quick and Standard work; Terra coordinates Deep and Custom reviews with Luna specialists. Before model requests, the execution boundary enforces bounded context, agents, output, concurrency and spend. The public Lite Check is deterministic and does not pretend to be that private runtime.

Current boundary

We are also using LyraShield-Engine, it is a controlled derivative of Strix OSS. The Lite Check is live today. The authenticated workspace at app.lyrashieldai.com is open for registration: anyone can create an account, sign in, add an authorized target, and use the product. Full repository reviews use a separate controlled worker path; its operational release gates remain independently scoped.

That is the point of LyraShield: uncertainty is a visible, useful state, not an error hidden behind a score.

Built With

  • astro
  • azure-container-apps
  • bullmq
  • cloudflare-workers
  • codex
  • docker
  • gpt-5.6
  • next.js
  • prisma
  • supabase
  • typescript
Share this project:

Updates