UnmetRadar: auditable market-research engine

_context

UnmetRadar is the backend engine for a market-research tool that assesses whether a business idea is worth building and, just as importantly, refuses to give a confident answer when the evidence behind it is too thin. Individual scores abstain rather than guess, contradicting evidence is reported alongside supporting evidence, and a human correction is filed as an attributed amendment instead of quietly overwriting the earlier report. Work started in July 2026. It runs today as a command-line tool and a background worker: there is no interface yet, evidence is still registered by hand, and it has never been deployed or used by a customer.

_contribution

I build the system solo: the PostgreSQL schema and its reviewed migrations, the row-level security model that isolates each customer's data, the durable job pipeline, the orchestration layer around model calls, and a test suite that runs against a real database rather than a mock.

_what-I-built

• A PostgreSQL schema of roughly 150 tables with 44 hand-reviewed migrations, database-level constraints, and forced row-level security for tenant isolation.
• A boundary-enforced modular monolith: eleven domain modules behind single public entry points, with import rules checked automatically rather than left to convention.
• A durable job pipeline and an orchestration layer for bounded AI workflow steps, with every model call routed through an owned adapter, a permit check, and a cost ledger.
• A test and evaluation harness: suites running against a real database in containers, plus cross-model evaluation matrices covering traceability, contradiction handling, and prompt-injection resistance.

_what-it-demonstrates

• Multi-tenant isolation proven rather than asserted: row-level security is forced on 142 tables, and a test boots a real PostgreSQL instance under a role that cannot bypass it, so a new table cannot ship without protection.
• Architecture rules that are themselves tested: alongside the clean code, hand-written violating files are checked to confirm each boundary rule actually fails when it should.
• Model output and fetched content treated as untrusted input throughout, with schema-validated responses, a purpose-built fetcher carrying typed failure codes for DNS-rebinding and redirect cases, and cross-model adversarial evaluation runs.