Evidence_Lane

Verified project state that can travel between AI tasks while source authority and approval stay local.

Comment

Inspiration

Long-running AI development often crosses task and context-window boundaries. A prose summary helps, but it is not project authority: it can omit the exact files, hashes, accepted version, unresolved delta, or approval boundary. Evidence Lane began as an attempt to make those handoffs inspectable instead of asking each new AI task to reconstruct the project from memory.

The core idea is simple: preserve the last verified project truth outside the model, supply a bounded evidence packet to the next task, and keep promotion under explicit human control.

What it does

Evidence Lane is a local-first Windows developer tool for carrying bounded, inspectable project state across AI tasks.

The current source implements:

task-scoped project packages with a frozen pointer, selected source records, file manifests, and SHA-256 values; validation before export; hash-linked handoff records with current and previous pointers, changed files, package hashes, and open state; explicit human decisions: APPROVE, REJECT, or SUPERSEDE; separation of review from promotion, with automatic promotion disabled and a verified approval receipt required before a separate promotion step; immutable version records that retain the previous verified state and bind old and new snapshot hashes; a React, TypeScript, and Tauri desktop shell backed by Python and SQLite; a 3D Telemetry preview for visual exploration of saved project topology.

The local working project remains the authority. An AI conversation is a reader of the governed packet, not the owner of project truth.

How it works

A typical Evidence Lane route is:

Select a public-safe local project. Build a bounded source intake and project-state package. Validate its pointer, manifest, file records, hashes, and receipt. Give the validated packet to a later AI task. Let that task inspect the exact supplied evidence and return a candidate change. Stop at a human decision gate before any accepted-state promotion.

This makes the handoff inspectable. A judge can see which state was supplied, which sources support it, what decision remains open, and which receipt binds the transition.

How we built it

The backend uses Python and SQLite for project ingestion, indexing, validation, manifests, receipts, version records, and handoff logic. The interface uses React and TypeScript. Tauri and Rust provide the native Windows shell and the embedded-worker bridge. PyInstaller packages the backend worker. The visual preview uses Three.js and React Three Fiber.

The reproducible Windows build route installs pinned Python dependencies, runs focused backend tests, creates and verifies the PyInstaller worker, runs npm ci, audits and builds the frontend, compiles the Tauri application, and creates the NSIS installer.

The private judge repository contains the reviewable source, build scripts, tests, documentation, and runtime assets. Generated binaries are distributed separately through the linked Drive folder.

How Codex and GPT-5.6 were used

Evidence Lane existed before OpenAI Build Week. During the official event window, Codex and GPT-5.6 Sol at Ultra reasoning were used to trace and edit the verified-package, provider-readable export, embedded-backend, desktop, handoff, and approval-receipt paths.

The primary feedback session submitted for review is:

"019fxxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx"- Classified here; shared in place of Primary Key

That session was selected because it contains the clearest concentration of demonstrable implementation and debugging work, not because of transcript length, token volume, or patch count. Human review remained the acceptance authority.

Challenges we ran into

The hardest part was separating convenient context from current authority.

Several failures shaped the design:

context windows ended during multi-day work, so a restart summary was not enough; a structurally valid package could still be unreadable to the target model when useful project evidence was trapped in an opaque binary; browser behavior and native desktop behavior could diverge even when builds and unit tests passed; passing tests did not prove real click behavior, restart persistence, package readability, or human approval boundaries; rich 3D topology could become a visually impressive but operationally misleading graph if it did not preserve the actual folder/file navigation law.

These failures reinforced one rule: technical completion is evidence, not automatic acceptance.

Accomplishments

For the current candidate, Evidence Lane has:

a reviewable private source repository; a reproducible Windows build pipeline; a Windows installer and standalone judge build with published SHA-256 values; a bounded package and handoff walkthrough; explicit decision and approval-receipt logic; immutable prior-version retention; source-linked manifests, hashes, and receipts; an installed desktop surface and a developing 3D Telemetry preview.

The claim is deliberately narrow. This is a judge candidate, not a production-ready release.

What we learned

AI should be the reasoning layer, not the memory authority.

A useful handoff is not merely a larger prompt. It is a bounded data packet containing exact state, selected sources, hashes, open decisions, and receipts. The packet should help a new task reason from evidence while leaving acceptance and project authority local.

Current limitations

The current candidate has disclosed limitations:

the bundled public-model Env package contains mixed historical and current material and is not the final intended Env definition; the Windows installer and standalone executable are intentionally unsigned because this packaged release remains a HIL candidate and has not received final human acceptance; verify the published SHA-256 values before launch; the Git/code-intake path can validate and index repository state across project types; when a required parser or semantic lane is unavailable, affected files are retained as hash-only evidence with their path, size, and SHA-256 instead of causing ingestion or build failure; this candidate has a prompt-area layout defect where the provider/action bar can float or overlap the prompt area; this remains a disclosed limitation pending human review; 3D Telemetry is a preview surface and is outside the narrow proof claim for this submission; this submission does not claim measured token savings, measured speedups, universal provider neutrality, production readiness, or complete clean-machine coverage.

The repository and judge guide state these boundaries directly.

What's next

Next work is to replace the mixed Env package with one current governed definition, complete clean-machine and lifecycle validation, strengthen the end-to-end desktop human-gate path, sign the installer, and continue validating 3D Telemetry against durable saved topology rather than presentation-only state.

Built with

Python, SQLite, React, TypeScript, Tauri, Rust, Vite, Three.js, React Three Fiber, PyInstaller, Git, OpenAI ChatGPT, Codex, and GPT-5.6.

Open WebUI and its community are credited for advancing local, inspectable AI tooling. Open WebUI is not bundled in this repository.

Let's work together to make this stronger: first solve the data packet, then advance further.

Built With

Share this project:

Updates