AudiX

SHIPPED

Skillwyn Labs

Technical due-diligence platform — the audit a VC associate does by hand

The problem

Before anyone invests in or buys a company, someone has to check whether the product is actually as good as the pitch — and today that's a person clicking through it by hand for days.

What I built

AudiX audits a live company across six dimensions — frontend, backend, cybersecurity, performance, AI usage and product maturity — and returns one investor-ready report. It pulls real-time market and competitive intelligence, and verifies pitch-deck claims against what the deployed product actually does. Each report gets its own RAG chatbot, with retrieval isolated per report so one company's evidence can never surface in another's answers.

Next.jsPythonNode.jsPostgreSQLRedis / BullMQPlaywrightDockerNginx + SSL

Audit surface

Frontend, backend, cybersecurity, performance
AI usage and product maturity
Pitch-deck claims checked against the live product

Evidence & grounding

Provenance tracking on every claim
Hallucination guards — ungrounded claims are rejected, not shipped
Per-report RAG: ingestion, chunking, embeddings, similarity search

Release gates

AI red-teaming as a standing gate: prompt injection, jailbreaks
System-prompt extraction attempts
887 automated tests

Architecture

in / out
Live product + pitch deck
The company as it actually runs, plus what it claims.
tools
Crawl & probe
Playwright workers queued through Redis / BullMQ.
state
Per-report evidence store
PostgreSQL, one isolated namespace per report. This is the boundary — no cross-report reads exist.
tools
Per-report RAG
Ingestion → chunking → embeddings → similarity search, scoped to one report.
reasoning
Evidence-grounded analysis
Frontend, backend, security, performance, AI usage, product maturity — each claim carries its provenance.
gate
Evidence validator
A claim that can't be traced to evidence is rejected, not flagged.
in / out
Investor-ready report
Plus a chatbot scoped to that one report's evidence.

Across every step

AI red-team release gate
Prompt injection, jailbreaks, system-prompt extraction — failures block the release.
887 automated tests
Run against the pipeline, not just the UI.

reasoningtoolsstategatehuman

Evidence is captured first and reasoned over second. The isolation boundary around each report's evidence is the load-bearing part: retrieval physically cannot cross it.

Hard decisions & trade-offs

Retrieval is isolated per report, not pooled across the corpus

Chose: Every report gets its own retrieval namespace. A query against report A can only ever reach evidence captured for report A.
Rejected: One shared vector store across all reports with a metadata filter on report ID — simpler, cheaper, and better at cross-company pattern-matching.
Why: The users are investors looking at competing companies, sometimes in the same sector, often under NDA. A metadata filter is one bad query away from leaking one portfolio company's evidence into another's report, and that failure is silent — it looks like a good answer. The isolation costs some retrieval quality and some infrastructure. Leaking a client's diligence data into a competitor's report is not a recoverable mistake.

The evidence validator rejects ungrounded claims rather than flagging them

Chose: A claim the model can't tie back to captured evidence is dropped from the report entirely.
Rejected: Flagging it as low-confidence and shipping it anyway, letting the reader decide.
Why: A flagged claim is still a claim — it's read, it anchors, and it survives being copied into a memo without the flag. The report's only real product is trustworthiness: an investor has to be able to treat every line as checkable. A shorter report where everything holds up beats a longer one the reader has to audit themselves, which is the exact work they were paying to avoid.

Red-teaming runs as a release gate, not a periodic review

Chose: Prompt injection, jailbreak and system-prompt-extraction suites block the release if they fail.
Rejected: Scheduled security reviews between releases, with findings triaged into the backlog.
Why: The system ingests untrusted content by definition — it reads the target company's own pages and documents. That makes injection an input, not an edge case. A finding in a backlog is a vulnerability in production with extra steps, so the check belongs where it can actually stop a ship.

Verified numbers

automated tests: 887
audit dimensions per report: 6
ungrounded claims shipped — rejected by design: 0

Open AudiX →All work →Get in touch →