FRONTEND + POSTGRESQL · ACCEPTEDDEMO DATA · SIMULATED · NO LIVE OUTBOUND

OpsPilot AI

Human-in-the-loop AI operations automation system.

A traceable workspace that turns lead evidence into deterministic qualification, a recommended action, a human approval decision, and a safely simulated execution record. The demo does not send a message.

Portfolio maturity

IMPLEMENTED · NOT LIVE

Frontend built and accepted on fixture data; approval and execution are simulated, with no live outbound.

Other labels on this page describe individual surfaces and evidence, not the whole project.

Operations overview — accepted fixture-backed demo. DEMO DATA and NO LIVE OUTBOUND remain visible in the product frame.

Decision quality needs an evidence trail

01 · Problem

Lead-response operations often split qualification, supporting evidence, approval context, and action history across multiple tools. Operators lose time reconstructing why a lead was prioritised and whether an action was authorised.

OpsPilot keeps the decision chain in one place while making each domain concept explicit: qualification is not evidence strength, evidence is not a recommended action, and approval is not execution.

Domain rules stay outside presentation

02 · System

The React interface displays adapter-provided decisions. Canonical qualification and workflow rules remain in the Python domain layer, with FastAPI boundaries, SQLAlchemy persistence, and Alembic migrations behind them.

Qualification: HOT / WARM / LOW
Evidence: HIGH / MEDIUM / LOW / UNKNOWN
Recommended action: A separate, explicit operator recommendation
Control: Human approval before simulated execution

One traceable decision chain

03 · Workflow

Inbound lead
Analysis
QualificationHOT / WARM / LOW
EvidenceHIGH / MEDIUM / LOW / UNKNOWN
Recommended action
Human approval — key stage
Simulated executionno live outbound
Audit evidence

Lead queue — qualification, workflow status, recommended action, and timing remain separate and scannable.

The reasoning stays inspectable

04 · Evidence-led dossier

A representative lead dossier brings the qualification result, supporting evidence, recommended action, response draft, approval state, execution state, and audit events into one operator view.

Acme Robotics dossier — deterministic fixture data, a demo approval decision, and no live outbound action.

A success state is not a delivery claim

05 · Safe simulated execution

SIMULATED · NO LIVE OUTBOUNDApproval and execution controls update an in-memory fixture projection. No API, provider, customer system, or outbound messaging service is contacted by the demo.

Executed-lead proof — SUCCEEDED is shown in the same frame as SIMULATED and NO LIVE OUTBOUND.

Step 1 — awaiting approval. The decision is the operator's; nothing has been armed.
Step 2 — approved. Execution is armed as PENDING and SIMULATED, and still has not run.
Step 3 — simulated success. The audit timeline records the demo decision and a send that delivered no message.

Critical context without horizontal discovery

06 · Operational at mobile width

At 390 pixels, each operational card retains lead identity, status, qualification, recommended action, and timing. Queue rows are real links, keyboard focus stays visible, and meaning never depends on colour alone.

Loading, loaded, not-found, and recoverable error states are explicit at the adapter boundary, with status or alert semantics where appropriate.

OpsPilot mobile lead queue at 390 pixels wide, showing identity, status, qualification, recommended action, and demo-data disclosure without page overflow. — Mobile queue — exact 390 × 844 accepted capture.

Accepted locally, not presented as production deployment

07 · Engineering proof

497: repository tests passed
59: targeted simulated-E2E tests passed
PostgreSQL 16.15: real-database technical acceptance
Alembic: canonical migrations reached head
Ruff: lint and format gates passed
strict mypy: backend type gate passed

Technical acceptance used a disposable real PostgreSQL 16.15 instance. It proves repository behaviour against PostgreSQL; it does not claim a production database, deployment, customer traffic, provider activation, or real outbound execution.

08 · Role and current state

My role

Domain-to-interface translation, responsive React implementation, product-truth boundaries, accessibility, rendered QA, and acceptance evidence.

Stack

React 18, TypeScript 5.5, Vite 5.4, React Router, Python 3.12+, FastAPI, Pydantic 2, SQLAlchemy 2, Alembic, PostgreSQL, pytest, Ruff, and mypy.

TECHNICALLY ACCEPTED · NOT PRODUCTION-DEPLOYEDThe portfolio demo remains deterministic, fixture-backed, and simulated. No live outbound send or customer-data claim is made.