VERA — Verified Environmental Review & Attestation

Environmental due diligence for lenders: searchable records, explainable review signals, and attestations on Solana.

Inspiration

Through my work on Opef, I kept encountering the same problem: environmental information may be available, but turning it into a useful decision is still difficult.

A lender or infrastructure investor needs to understand the environmental review behind a project. The relevant material can be scattered across long reports, supporting documents, agency records, and permitting milestones. Finding the right document is only the beginning. Someone still needs to understand what it says, identify passages that deserve closer attention, and preserve a clear record of what was reviewed.

I built VERA to explore a more practical workflow: search for a project, inspect its environmental review, surface specific passages for follow-up, and create a verifiable fingerprint of the scan summary and document versions.

The central idea is simple: make the evidence easier to find, make the signals easier to inspect, and make the review record easier to check.

What it does

VERA is a lender-facing research prototype for National Environmental Policy Act (NEPA) documents. It brings together document search, deterministic review signals, AI-assisted exploration, portfolio dashboards, and Solana devnet attestations.

A typical workflow is:

Find a project using its name or other search terms.
Open its records and inspect the available documents and milestones.
Run a scan to identify text patterns that may warrant further review.
Inspect each flag alongside its triggering excerpt and location in the document.
Ask questions using retrieved passages as context for an AI answer.
Create an attestation that records a fingerprint of the scan summary and document hashes on Solana devnet.

VERA also provides two broader views: a NEPA Observatory for exploring the loaded document collection, and a Stuckness Radar for examining permitting-project statuses across states, sectors, and agencies.

How I built it

1. A structured environmental-document pipeline

VERA uses the NEPATEC2.0 dataset from PNNL PermitAI as its environmental-document source. The dataset spans Categorical Exclusions, Environmental Assessments, and Environmental Impact Statements. Its published scope is 61,881 projects and approximately 6.97 million pages across more than 60 agencies.

I built an ingestion pipeline that reads project-level JSONL records and separates them into projects, documents, and milestones in SQLite. Each project is processed in a transaction so a failed record can be rolled back without discarding the rest of the import.

One important detail is choosing the right document to scan. An Environmental Impact Statement project can have several files labeled as main documents, including a Record of Decision, a summary, or an errata sheet. VERA prioritizes the actual analysis documents—such as a Final or Draft Environmental Impact Statement—before falling back to the source's main-document labels.

The pipeline also:

Normalizes process types and document metadata.
Creates milestones from recognized document types.
Computes SHA-256 fingerprints of document text.
Maintains SQLite FTS5 indexes for project search.
Preserves project and document references for downstream review.

The complete source dataset and the semantic-search index are separate layers: semantic search operates over the documents selected and indexed in the running application.

2. Eight explainable review signals

I implemented eight deterministic detectors for text patterns associated with potential environmental-review concerns:

Deferred mitigation.
Reliance on future studies.
Explicit statements that environmental justice analysis is absent.
Thin environmental justice coverage.
Missing no-action alternative discussion.
Thin no-action alternative discussion.
Thin cumulative-impact discussion.
References to tribal interests or consultation.

Each finding includes a signal type, severity, triggering excerpt, and character offset. The tribal-interests signal is informational: a mention is a prompt to inspect the discussion, not evidence of a defect.

I used rule-based matching for this layer so the triggers remain inspectable and repeatable. I also added process-type gating: several detectors run only on Environmental Assessments and Environmental Impact Statements, rather than treating every document category as if it followed the same structure.

Explicit phrase exclusions reduce obvious false positives, and duplicate findings are suppressed by signal type and normalized excerpt. The repository includes positive and negative test cases for detector behavior.

These signals are research aids. They identify passages to review rather than determining legal compliance or predicting the outcome of litigation.

3. Semantic search with Actian VectorAI

Keyword search is useful when someone knows the wording they need. Environmental research often starts with a concept instead: a mitigation commitment, a missing study, or a discussion of alternatives.

For that workflow, I integrated Actian VectorAI DB through its Cortex client:

Split selected document text into overlapping chunks.
Generate embeddings using OpenAI's text-embedding-3-small model.
Store vectors with project, agency, state, process-type, and document metadata.
Embed a user's query using the same model.
Retrieve similar passages using nearest-neighbor search and optional metadata filters.

The implementation uses 600-character chunks with an 80-character overlap and 1,536-dimensional embeddings.

I also built a local NumPy fallback that persists vectors and metadata to disk and performs cosine-similarity search when Actian is unavailable. Both backends sit behind the same application interface, so the search workflow can remain consistent across development environments.

4. AI answers grounded in retrieved passages

VERA's “Ask the Archive” workflow retrieves relevant passages and supplies them to a local Ollama model. The answer is returned alongside source excerpts and project metadata so a user can inspect the underlying material.

The application also supports project-level chat and AI explanations of individual flags. These help connect a short detector label to the passage that triggered it.

The prototype uses local Ollama generation, including the documented qwen2.5:3b configuration. Embeddings are generated through OpenAI, so that part of the workflow sends text to an external service. Retrieval-grounded prompts help constrain answers, but generated interpretations still require review.

5. Solana attestations

I integrated Solana devnet to explore how a review record could be checked separately from VERA's database.

The attestation layer builds a payload containing:

Project identity.
An attestation timestamp.
Flag counts grouped by severity.
Document text hashes.

It serializes the payload, computes a SHA-256 fingerprint, and submits a compact summary and fingerprint through Solana's SPL Memo program, using solders and solana-py. The application retains the transaction signature and provides a Solana Explorer link.

The underlying documents stay off-chain. The on-chain record is a reference for checking the corresponding payload, not a substitute for reading the evidence.

This is an integrity mechanism: it does not establish that a detector's finding is correct. The current payload commits to the severity summary and document hashes, rather than every individual flag and excerpt. Complete scan snapshots and stronger end-to-end verification are natural next steps.

6. Observatory and Stuckness Radar

The NEPA Observatory provides collection-level statistics and breakdowns by state, agency, and process type.

The Stuckness Radar uses a separate permitting-data CSV snapshot. It assigns a transparent score based on project status, with a small sector-relative adjustment for projects marked “In Progress.” The interface presents maps, charts, filters, and project comparisons, with optional OPEF Copilot narration.

This makes the status distribution easier to explore. It is a heuristic view of the snapshot, rather than a trained prediction of project delays; the current score does not incorporate elapsed time in a stage or missed deadlines.

7. APIs and MCP tools

The backend is built with Python and FastAPI, with SQLite handling structured records and full-text search. The browser interface uses Alpine.js, Tailwind CSS, D3, and Chart.js.

I also exposed VERA's data through a FastMCP server with ten tools for project search, document retrieval, flags, database statistics, and project timelines. This lets compatible assistants query the same structured research source instead of relying only on the browser interface.

Challenges I ran into

Selecting the right evidence. A document labeled “main” is not always the document containing the substantive analysis. Process-aware selection mattered before any detector or AI feature could be useful.

Making flags useful rather than noisy. The same phrase can mean different things in different contexts. Process gating, exclusions, excerpts, and negative tests became as important as adding new detectors.

Keeping vector search portable. Actian integration and the local fallback let me develop a common retrieval interface while accounting for differences in runtime availability.

Separating integrity from interpretation. A blockchain record can anchor a fingerprint. It cannot prove that a document was correctly interpreted. That distinction shaped the attestation design and what the interface should communicate.

Connecting the parts. The harder work was creating one path from imported documents to searchable passages, review signals, AI explanations, and an attestation record.

Accomplishments I'm proud of

Built a connected research workflow spanning ingestion, search, scanning, explanation, and attestation.
Made review signals inspectable through excerpts and document locations.
Integrated Actian VectorAI with a local fallback behind the same search interface.
Combined local AI generation with retrieved source material.
Implemented Solana devnet attestations without storing source documents on-chain.
Exposed the research database through REST APIs and MCP tools.
Built technical explainers and an interactive demo deck showing how the components fit together.
Won [MLH] Best Use of Solana at Hacklytics 2026.

What I learned

This project reinforced a lesson from building Opef: collecting information and making it useful are different engineering problems.

A useful research system needs more than search or generated answers. It needs a clear relationship between source material, transformations, findings, and the record a user ultimately relies on.

VERA brought those concerns together in a focused prototype. Deterministic rules make triggers inspectable, vector search makes relevant passages easier to find, AI helps explain retrieved material, and attestations explore how to preserve a checkable record of a particular review snapshot.

What's next for VERA

Expand semantic indexing and make coverage and indexing limits more visible.
Evaluate detector precision and recall against practitioner-reviewed examples.
Add agency-specific configuration and more nuanced context handling.
Persist complete, versioned scan snapshots and strengthen attestation verification.
Incorporate milestone dates and time-in-stage into the Radar, then evaluate whether those signals improve its usefulness.
Add portfolio-level review and batch workflows.
Harden authentication, authorization, privacy controls, and deployment before handling sensitive customer material.

Built with

Python · FastAPI · SQLite · FTS5 · Actian VectorAI DB · OpenAI embeddings · NumPy · Ollama · Qwen · Solana devnet · SPL Memo · solders · solana-py · FastMCP · Alpine.js · Tailwind CSS · D3 · Chart.js