Connor O'Dea

Key design decisions

• Events over shared state. ~154 typed domain events across 12 business domains, published and consumed by 73 service files, with consumer groups, dead-letter queues, and idempotency keys.
• Sagas for multi-service work. A saga orchestrator coordinates transactions that span services and compensates on failure, instead of distributed locks.
• Audit by construction. Every event is appended to a PostgreSQL event store, so the system's history is queryable, not reconstructed from logs.
• Cost-aware vision. The grading service cascades Groq, then Claude, then OpenAI by confidence under a daily budget cap.

Architectural tradeoffs

• A hand-written SQL layer trades ORM convenience for explicit control of indexes, upserts, and migration ordering.
• A single-VPS PM2 deployment (59 processes) is operationally simple but is not yet containerized or wired to CI. Both are noted as planned, not claimed as done.
• Frontends are real but partial (four to nine routes each); the backend is the mature half of the system.

What the pipeline guarantees

• A single authoritative stock ledger. Inventory is the source of truth; every other stage reads and writes it only through events, never by reaching into its tables.
• Traceability by construction. Because state changes are appended to an event store, an item's full history is queryable rather than reconstructed from logs.
• Failure isolation. A saga orchestrator spans multi-stage transactions and compensates on failure, so one stage stalling does not corrupt the others.

Why it is built this way

• Each stage is owned by a different team and interface in the real operation, so the system has to keep many specialized workflows consistent without collapsing them into one monolith.
• An event contract between services is safer to grow than shared database access: new stages subscribe to the stream instead of taking new table dependencies.
• The deployment is deliberately modest — one VPS, no container platform — and the document does not claim scale it has not run.

Design decisions worth calling out

• The core cannot import the agents. An AST-enforced, one-way dependency ladder (engine, then solver, then agents and ingest, then api, then web) with import-guard tests keeps LangGraph and LLM calls out of the deterministic core.
• Retrieval degrades, it does not fail. Deterministic feature-hash embeddings work with no external services; real legal embeddings and vector stores layer on when available.
• Egress is fail-closed. Relationship-based access control, a privilege gate, PII scrubbing, and an append-only audit run on every outbound path.

Status, stated honestly

Implemented: the engine, solver, agent subgraphs, FastAPI surface, 3D interface, Z3 verifier, and a large test suite under a strict branch-coverage gate.

Partial: the external memory stores (Neo4j, Qdrant, OpenSearch) are code-complete but not yet provisioned; the app deploy is pending while the public landing site is live.

Research direction: opponent modeling with I-POMDPs, value-net training in the ReBeL style, and a regret-matching solver are documented as design only, with no code riding on them.

Problem and context

Identifying returned products by hand is slow and inconsistent. QuickVisionz runs a real-time vision pipeline on a Raspberry Pi at the point of capture, so an item is detected, read, graded, labeled, and registered before it leaves the station. Heavy segmentation work is offloaded to a serverless GPU that scales to zero when idle, which keeps an edge-first system affordable.

Verified stack

What this demonstrates

End-to-end computer vision under real constraints: detection with tracking and stability gating, multi-strategy barcode reading with an LLM vision fallback, a rule-based routing engine, raw-socket thermal printing, and a split between edge and elastic GPU inference. The edge pipeline carries roughly 3,800 lines of tests.

Stated honestly

• Condition grading via the classifier is a prototype placeholder until a labeled grade model is trained; there are no model-accuracy metrics.
• The segmentation service loads SAM 2.1 today; a SAM 3 backend is scaffolded for a future swap, not running.
• Label printing, intake registration, and the WebRTC path are code-complete but unverified without live hardware.

Three things that stand out

• Multi-source ETL with a pluggable adapter framework. Per-county foreclosure scrapers use CSS selectors stored in the database, so a county can be retuned without a redeploy. A null-safe normalizer and idempotent, conflict-preserving bulk upserts (four-part key, insert-versus-update detection) keep records clean; raw HTML is snapshotted to object storage so any run is replayable.
• A signal-based propensity engine. A 0 to 100 score built from recency-weighted signal stacking, combo bonuses, and a stack multiplier over a PostGIS property graph, explicitly versioned to be swapped for a trained model once enough labeled outcomes accrue.
• A multi-agent research assistant. A router agent uses forced tool-use to dispatch specialist subagents (deal hunter, comp analyst, market watcher, seller motivator) that return cited answers.

Verified stack

Stated honestly

The lead score is a deterministic weighted heuristic by design, not a trained model. Main-app property search proxies external APIs (Zillow, PropData) with a Postgres cache; the proprietary geospatial scoring lives in the off-market service.

Problem and contribution. Editors spend most of a session scrubbing for a moment they already remember. Cutroom transcribes first and makes the transcript the timeline: strike a sentence and the cut happens. It is built as a real non-linear editor, not a wrapper, with a media pool, multi-track timeline, color, and delivery. The engine is a worker of roughly forty FFmpeg operations (reframe, chromakey, transcription, text-to-speech, captions, color), each with its own test, driven by a Claude agent server that plans multi-step edits with forced tool-use and prompt caching, exposed over web, MCP, and CLI.

I design systems, not isolated features. A model is rarely the hard part. The hard part is the pipeline that feeds it, the state it updates, the events that keep everything consistent, and the interface a person actually trusts. I spend my effort on that connective tissue.

I turn unstructured reality into structured representations. Warehouse items, legal documents, county records, and camera frames all start as noise. Giving them a schema, a graph, or an event stream is what makes downstream reasoning possible.

I connect machine learning to operational workflows. Inference is only useful when it moves through to a routed item, a published listing, a reviewed claim. I build the path from a prediction to an action.

I design for auditability and human review. Consequential systems should be able to explain what they believed and why. Append-only histories, fail-closed review gates, and governed state are defaults in my work, not afterthoughts.

I model uncertainty honestly. When a system cannot know something, it should say so. I would rather ship a calibrated simulation that refuses to fake a probability than a confident number with nothing behind it.

I balance experimentation with discipline. Tests, migrations, and deployment are how a prototype becomes software that runs. I move fast, but I leave a clean seam for the next model, the next service, and the next engineer.