Customer Demo | Local AI Compliance Review

Premai turns engineering evidence into review-ready findings.

A local-first workflow for aerospace software document review: ingest, index, retrieve, review, and report without sending sensitive documents to a cloud AI service.

1,154NASA GCS pages in the study case

LocalPostgreSQL + Ollama runtime

<40 mindemo path with expected outputs

Finding

Evidence gap detected

Requirement has weak verification wording and missing traceability evidence.

Run of show

40-minute presentation path

0-5Why compliance review is hard

5-12What Premai does and why local matters

12-28NASA study case demo with expected outputs

28-35Technical architecture and data model

35-40Evaluation, roadmap, and next steps

Demo principle: live commands are available, but long-running AI steps use expected output snapshots so the narrative stays fast and reliable.

Customer problem

Compliance review is not just reading documents.

Evidence is fragmented

Requirements, verification plans, tests, QA records, and traceability data live in separate artifacts.

Review is repetitive

Engineers repeatedly ask the same checklist questions and chase the same evidence paths.

Cloud AI is often blocked

Engineering and supplier documents may be proprietary, regulated, or contractually restricted.

Premai focuses on local evidence retrieval and review assistance, not replacing expert judgment.

Positioning

What Premai does

Input
Documents + checklist

Local AI workflow
RAG + structured review

Output
Findings + evidence + report

Customer value

Shorter first-pass review cycles.
Evidence-backed findings, not opaque model answers.
Local runtime for sensitive engineering data.

Scope boundary

Preliminary AI-assisted review only.
Human engineer remains final decision maker.
Not a formal DO-178C compliance determination.

NASA GCS study case

A credible public aerospace software document set

NASA GCS Volume 2 — Development documents

NASA GCS Volume 3 — Verification documents

Public NASA Guidance and Control Software materials give the demo realistic lifecycle data without exposing customer IP.

Demo inputs

We review documents against a checklist

Document excerpt

SWR-002: The software shall quickly detect unusual vibration.

SWR-004: The software shall enter degraded mode as needed
when sensor data is unreliable.

Checklist item

id: REQ_QUALITY_002
title: Verifiable requirement wording
severity: high
retrieval_queries:
  - unverifiable requirement wording
  - verification method requirement

The system links vague requirement language to concrete checklist criteria.

Input -> progress -> output

Premai workflow at a glance

1 Ingest Documents become chunks

2 Index Chunks get embeddings

3 Retrieve Checklist finds evidence

4 Review LLM generates findings

5 Report Human-ready output

Step 1

Prepare the local project

Start PostgreSQL and apply migrations

make up
go run ./cmd/premai migrate up

Create the demo project

go run ./cmd/premai init nasa-gcs-demo \
  --description "NASA GCS compliance review demo"

Expected output

applied 000001_init.sql
applied 000002_resume_review_runs.sql

created project
name: nasa-gcs-demo

Step 2

Ingest and index documents

Ingest demo documents

go run ./cmd/premai ingest \
  --project nasa-gcs-demo \
  --path ./demo/docs

discovered: 4 documents
imported: 4 documents
chunks_created: 7311

Generate embeddings

go run ./cmd/premai index --project nasa-gcs-demo

chunks_pending: 16
chunks_indexed: 7106
embedding_model: nomic-embed-text

Step 3

Search evidence before asking the model to judge

Evidence search

go run ./cmd/premai search \
  --project nasa-gcs-demo \
  --query "requirements without verification method"

Expected output snapshot

1. traceability_matrix_demo.md
   SWR-002 | VIBRATION_MONITOR | [missing test]

2. software_requirements_demo.md
   "quickly detect unusual vibration"

3. software_requirements_demo.md
   "degraded mode as needed"

The key control: retrieval happens first, so findings are anchored in visible evidence.

Step 4

Run checklist-driven AI review

Review command

go run ./cmd/premai review \
  --project nasa-gcs-demo \
  --checklist ./checklists/starter_software_review.yaml

Pass1

Partial1

Fail1

High severity2

Expected in demo: concise review summary and persisted findings.

Finding detail

A finding is useful because it is traceable

Fail | High

Requirement wording is not objectively verifiable

SWR-002 uses "quickly" without a measurable threshold, and traceability data has no mapped test case.

Evidencesoftware_requirements_demo.md

Evidencetraceability_matrix_demo.md

Recommended rewrite

Define a measurable vibration threshold, detection time, fault behavior, and a verification method mapped to a test case.

Step 5

Report, browse, or continue in Web UI

Generate report

go run ./cmd/premai report \
  --project nasa-gcs-demo \
  --format html \
  --out ./out/nasa-gcs-demo.html

Browse in TUI

go run ./cmd/premai tui

Use guided Web workflow

make web

Expected output

report written: ./out/nasa-gcs-demo.html
Web UI: http://127.0.0.1:8787

Nasa case study findings output

Architecture

Thin interfaces, reusable local services

CLI
Cobra

Web UI
HTTP + SSE

TUI
Bubble Tea

Config, ingest, indexer, retrieval, review, report, eval

PostgreSQL + pgvector

Local Ollama
embed + chat

The UI surfaces are thin; the core workflow is shared and testable.

Technical detail

Core data model

projects

documents

chunks
content + embedding

review_runs

findings
status + evidence JSON

CREATE TABLE chunks (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  project_id UUID NOT NULL REFERENCES projects(id),
  content TEXT NOT NULL,
  content_tsv tsvector,
  embedding vector(768),
  metadata JSONB NOT NULL DEFAULT '{}'
);

Technical detail

Review orchestration in Go

retriever := retrieval.Service{
    Store:       retrieval.NewSQLStore(database),
    Embedder:    ollama.EmbeddingClient{BaseURL: cfg.Ollama.BaseURL},
    VectorTopK:  cfg.Retrieval.VectorTopK,
    KeywordTopK: cfg.Retrieval.KeywordTopK,
    FinalTopK:   cfg.Retrieval.FinalTopK,
}

service := review.Service{
    Store:     review.NewSQLStore(database),
    Retriever: retriever,
    Reviewer:  runner,
    Model:     model,
}

summary, err := service.Run(ctx, projectName, loadedChecklist)

The model is only one component; retrieval, persistence, and validation remain explicit Go code.

Quality loop

Benchmark retrieval and reasoning quality

Run evaluation

go run ./cmd/premai eval \
  --project nasa-gcs-demo \
  --ground-truth ./demo/benchmark/ground_truth.json

20ground-truth items

HR@Kevidence hit rate

Statuspass/fail accuracy

Expected output shape

--- Quality & Efficiency Report ---
Total Items: 20
Status Accuracy: 75.00%
Average Hit Rate: 82.50%
HTML report saved: out/reports/benchmarks/eval-report-*.html

Live demo safety

What we run live vs. what we show as expected output

Run live

`version`, `config`, and project listing.
Open the Web UI at `127.0.0.1:8787`.
Show saved reports and findings.

Use expected output

Embedding generation.
Checklist review with LLM calls.
Full evaluation run.

This keeps the presentation smooth while preserving executable commands for technical validation.

Customer value

Where this helps first

Supplier document intake

Quickly identify missing verification links and vague requirement wording.

Internal readiness review

Run a repeatable checklist before formal review meetings.

Knowledge retention

Persist findings and evidence so teams can revisit why a gap was flagged.

Roadmap

Practical next steps

1Fix current `internal/ollama` test alignment and add CI.

2Add richer PDF/DOCX parsing when customer data requires it.

3Add human decision update workflow and audit-friendly review states.

4Run a pilot on anonymized customer artifacts and tune checklist coverage.

Premai makes AI review explainable, traceable, and audit-ready.

Core message

Documents stay local. Evidence comes first. Findings are structured for human review.

Open the guided demo

make web