Data-source audit · v1 · static
What the audit re-verified — and what it didn’t.
Two external data dependencies, audited against the deployed code rather than against vendor decks or product ambition. Each gets an explicit verdict — not a vague summary — backed by file and line. Verdicts only change when the cited files change.
How to read this report
Two verdicts, each pinned to the codebase.
- Confirmed
- The data plane is real. Every claim in the marketing copy is backed by a code path that runs against a real data source — there is no fabrication between the marketing claim and the deployed behavior.
- Needs integration
- The pipeline is wired — the cron, the read path, the route — but the upstream dictionary is fabricated. The verdict flips to Confirmed when a real vendor (in-house research feed, paid M&A-intelligence API, or admin-curated surface) writes into the same table.
- Not feasible (as shipped)
- The dependency cannot be sourced with the as-shipped system. Procurement and integration of a sanctioned data vendor (Dow Jones Risk & Compliance, Refinitiv World-Check, OpenSanctions, ComplyAdvantage, or equivalent) is a separate workstream that requires a contract, a schema migration, and an agent rewrite.
The two verdicts
One per feature. Pinned to file and line.
M&A target screening
The pipeline is wired end-to-end — nightly cron, per-user materialization, gated read path. The upstream dictionary, however, is fabricated in code. Until a real vendor writes into MaSignalsSource, every name on a watchlist is illustrative.
What ships today
Per-user watchlists, fit-score sorted, with a diligence-questions dialog that generates 5 PE-style questions on demand. First-time clients see an empty list until the cron materializes their first batch (see freshness chip).
What blocks 'confirmed'
A real vendor — in-house research feed, paid M&A-intelligence API, or admin-curated surface — writing into MaSignalsSource. The cron and read path are wired; only the upstream dictionary is fabricated.
Evidence
src/lib/business/ma-signal-agents.ts · 206–305DEFAULT_SOURCE_ROWS — in-code literal of fabricated company names (Northwind Forgeworks, Cedarline Cold Chain, Tideway Logistics, Arteria Health Systems, Petrichor Capital, Linden & Co. Audit, Karoshi Robotics, Tigerlily Diagnostics, Cordillera Energy, Beaconleaf Realty).src/lib/business/ma-signal-agents.ts · 311–319ensureDefaultSignalsSources() bootstraps the MaSignalsSource table from those rows; sole writer for new clients.prisma/schema/ma_signals_source.prisma · 18–32No externalSourceUrl, vendorRef, asOf, or confidenceScore columns — no schema hook for a real vendor feed.jobs/ingest-ma-signals.ts · 30–67Nightly cron is the sole writer of MaTarget rows for clients; reads only from the in-code dictionary above.src/app/api/ma-targets/route.ts · 16–28GET path notes the in-app cold-start seeder is no longer wired; cron is the only path that populates a new client.
Regulated diligence overlay
The diligence-questions prompt anchors to the MaTarget row and explicitly tells the model not to invent entities. There is no sanctions / counter-party / regulatory vendor call anywhere in the path — the marketing claim is currently unbacked.
What ships today
5 token-tight pre-deal diligence questions, drafted by the AI proxy, anchored to the carrier fields on the watchlist row (sector, revenue band, geography, stage, rationale). Cached as JSON on the row.
What blocks 'confirmed'
Procurement and integration of a sanctions / counter-party vendor (Dow Jones Risk & Compliance, Refinitiv World-Check, OpenSanctions, ComplyAdvantage) plus a schema migration adding regulatoryFlags / sanctionsHits / counterpartyRiskScore / watchlistHits columns to MaTarget, plus an agent rewrite that calls the vendor API before the model prompt composes.
Evidence
src/lib/business/diligence-agents.ts · 46–72buildPrompt cites no external sanctions / counter-party provider; explicitly instructs the model to phrase questions so the answer itself surfaces the missing fact rather than invent numbers or entities.src/lib/business/diligence-agents.ts · 81–104runDiligenceQuestionsAgent calls only generateObject on the platform AI proxy; no sanctions-API call in the path.prisma/schema/ma_targets.prisma · 16–46No regulatoryFlags, sanctionsHits, counterpartyRiskScore, or watchlistHits column on MaTarget — nowhere to land a vendor result if procured.src/app/api/ma-targets/[id]/diligence-questions/route.ts · 1–32Route is PE-Operating gated, 502 on AI proxy failure, scope-limited to MaTarget row fields.src/ · grep OFAC / OpenSanctions / World-Check / Refinitiv / Dow Jones / ComplyAdvantage / RegTechZero matches across src/. No sanctioned-vendor reference anywhere in the codebase.
Re-verification cadence
Verdicts change when the cited files change.
This page is a static Server Component. It is not generated from the data plane at runtime — it is metadata about the data planes. A re-verification is a code change that touches one or more of the cited files; the operator re-reviews the affected verdict on that PR and updates the page in the same change.
Report last re-verified against the codebase on commit <removal-commit-hash> (2026-08-02). Verdicts only change when the cited files change.
Northwake · AI-native diagnostic practice — continuous, not episodic. The audit re-verifies the dependencies; the briefing lands before the next market open.