PLUMB — How deep does “done” really go?

PLUMB independently verifies AI-built software by mapping requirements to implementation, running tests and measurements, and tracing every verdict to evidence—revealing what “done” actually means.

Comment

Inspiration

AI can now generate working software in minutes, but “working” is not the same as “correct.” A project may compile and its tests may pass while important requirements are incomplete, runtime behavior is wrong, security issues exist, or the evidence simply does not justify the claim that the software is finished.

That led to one question:

How deep does “done” really go?

We built PLUMB, an evidence-first software verification platform designed to inspect AI-built software beyond the completion claim.

What it does

PLUMB takes three main inputs:

  • the original project specification
  • the AI’s completion claim
  • the actual project archive

It then inspects the submitted project and builds an evidence-backed verification record.

PLUMB can:

  • discover project files, structure, modules, routes and tests
  • break specifications into individual requirements
  • trace requirements against the implementation
  • run supported build and test checks
  • perform deterministic static and security analysis
  • execute supported runtime HTTP probes
  • perform mutation testing to evaluate test-suite strength
  • collect performance measurements where supported
  • visualize project architecture and verification evidence
  • distinguish VERIFIED, FAILED, INCONCLUSIVE and UNSUPPORTED conclusions
  • generate a professional verification report with traceable evidence

The key principle is simple:

A passing test suite is evidence, not proof that every requirement is complete.

If PLUMB cannot independently establish enough evidence for a requirement, it does not guess. It reports the requirement as INCONCLUSIVE.

How we built it

PLUMB was developed as a local-first verification system with a Python backend and a browser-based interface.

The verification pipeline follows an evidence-first process:

Inspect → Understand → Plan → Execute → Observe → Verify

The system first examines the submitted project and specification. It then identifies supported verification opportunities and executes deterministic checks such as compilation, tests, static analysis, security inspection, mutation testing and supported runtime probes.

Each conclusion is connected to recorded evidence rather than being inferred solely from the AI completion message.

We also built:

  • an interactive verification dashboard
  • requirement-level evidence exploration
  • architecture visualization
  • test and mutation analysis
  • security and performance views
  • verification history
  • downloadable professional PDF reports

During development, we used ChatGPT, Claude, Google Antigravity, Replit, Lovable and Freebuff as development tools for activities such as ideation, architecture exploration, coding assistance, debugging, UI experimentation, testing and refinement.

These tools assisted the development process; their outputs are not automatically treated as verification evidence by PLUMB.

Challenges we ran into

The biggest challenge was realizing that software verification cannot be reduced to a fixed collection of keyword rules.

Different projects require very different kinds of evidence. During stress testing we explored projects involving:

  • REST APIs
  • filtered numerical calculations
  • state transitions
  • scheduling constraints
  • transactional invariants
  • security problems
  • cross-endpoint consistency
  • business-rule verification

This forced us to move toward adaptive verification planning while keeping the final evidence deterministic and conservative.

Another challenge was avoiding false confidence.

It is easy for a verification tool to say “passed” because an endpoint returned HTTP 200 or because unit tests were green. PLUMB instead separates implementation detection, test execution and actual requirement verification.

The system also has explicit boundaries. Some requirements cannot yet be independently verified in the available execution environment. Instead of pretending otherwise, PLUMB marks those cases INCONCLUSIVE or UNSUPPORTED.

Accomplishments that we're proud of

We are proud that PLUMB does not simply produce another pass/fail test report.

It creates a traceable relationship between:

what was requested → what was claimed → what was found → what was actually verified

We built a working platform that can inspect real project archives, execute supported verification checks, expose weak test suites through mutation testing, identify contradictory runtime evidence, visualize architecture, preserve verification history and produce client-readable reports.

Most importantly, PLUMB follows an evidence-before-confidence philosophy.

A green test suite does not automatically mean a green project.

What we learned

We learned that verifying AI-generated software is fundamentally different from generating it.

Generation asks:

“Can we build this?”

Verification asks:

“What evidence proves that what we built actually satisfies what was requested?”

We also learned that trustworthy verification needs multiple evidence sources. Static analysis alone is insufficient. Tests alone are insufficient. Runtime responses alone are insufficient.

The strongest conclusions come from connecting requirements, implementation, tests, runtime observations, security findings and independently derived evidence.

We also learned the importance of uncertainty. A trustworthy system should be able to say “I do not have enough evidence” rather than manufacture confidence.

What's next for PLUMB — How deep does “done” really go?

The next step is expanding PLUMB's adaptive verification planner.

Future development includes:

  • richer automatic test-input generation
  • broader parameter-domain discovery
  • deeper multi-step behavioral verification
  • generalized invariant and property testing
  • stronger cross-service verification
  • additional language and framework support
  • containerized execution and stronger sandboxing
  • richer architecture and dependency analysis
  • CI/CD integration
  • baseline-versus-candidate regression verification
  • team and enterprise verification workflows

Our long-term goal is not to replace developers, testers or security engineers.

It is to give them a better answer to one increasingly important question:

When AI says the software is done, what can we actually prove?

Built With

Share this project:

Updates

Submission history