RFP Tank

1. Business Proposal

Prepared by: IT Pro Partner | Germaine Brown

Date: August 2026

Version: 1.0

"Throw your RFP in the Tank. Out comes a winning response."

1. Executive Summary
2. Elevator Pitch
3. Problem Statement
4. Market Analysis
5. Product Overview
6. Revenue Model
7. Competitive Advantages (Moat)
8. Go-to-Market Strategy
9. Risk Analysis
10. Financial Projections
11. The Ask

1. Executive Summary

The United States federal government spent $793 billion on contracts in FY2025. Every single dollar of that required someone to write a proposal. That proposal funnel is the choke point for an entire industry - and the tools serving it are broken.

The enterprise players hide pricing behind a sales call and target mid-to-large primes. The cheap tools are search wrappers with a chatbot bolted on. The middle - the 200,000+ active small businesses, independent consultants, and emerging contractors who collectively chase $182 billion in set-aside contracts every year - gets nothing purpose-built. They get spreadsheets, prayer, and $500/hour consultants they cannot afford.

RFP Tank fills that gap with a sledgehammer.

RFP Tank is a SaaS platform purpose-built for government contractors who need to find, analyze, and respond to RFPs faster and more accurately than any tool on the market. It is not a search tool with AI added. It is not an enterprise platform with a self-service tier bolted on. It is a complete proposal pipeline - from proactive opportunity matching to guided response flow to compliance checking to past performance mining - built from the ground up for the contractor who needs to WIN, not just submit.

The differentiation is twofold. First, depth on traceability: a compliance matrix that maps every mandatory requirement to the exact paragraph that answers it, with a confidence score and quoted evidence. Second, an evaluation layer no competitor has: an evaluator simulation that scores the proposal the way the government will, using the RFP's own criteria and weights, so the contractor knows whether it will win, not just whether it complies.

Market Reality:

• $793 billion in federal contract spending (FY2025)
• $182 billion legally reserved for small businesses (the statutory 23% goal)
• 85,247 federal contracts expiring in the next 18 months ($142 billion in recompetes)
• SLED market adds another $1.6+ trillion in accessible opportunity
• Zero existing tools serve the full workflow end-to-end for self-service users

Revenue Potential (Year 1 Conservative):

• 619 paying accounts across tiers = $1.28M ARR
• Blended ARPU of ~$172/month
• Gross margin: 78%+ (infrastructure already operational)

The competitive comparison is not close. GovEagle targets mid-to-large primes - no public pricing, no self-service, enterprise sales cycle only. CLEATUS is a SAM.gov wrapper. GovDash competes on price, not quality. Nobody has built the full guided proposal workflow for self-service contractors. Nobody. Until now.

RFP Tank is an IT Pro Partner product. The infrastructure is already running. The SAM.gov API is free. The USASpending.gov data is public. The value is in the processing, the workflow, and the intelligence layer - and that is exactly what we are building.

The Ask: Domain (rfptank.com - confirmed available), 90 days of focused development, and the confidence to price like the best product in the market - because that is what it will be.

2. Elevator Pitch

GovEagle's pricing is unpublished and getting in the door requires an enterprise sales cycle. The other 99% of government contractors - the small businesses, independent consultants, and emerging prime candidates chasing $182 billion in set-aside contracts - are stuck writing proposals in Microsoft Word with a SAM.gov tab open and a spreadsheet for their compliance matrix.

RFP Tank is GovEagle for the other 99%.

Upload any RFP. In 60 seconds, get a complete compliance matrix, requirement breakdown, and Section L/M alignment. Then work through a guided response wizard that checks every answer against every requirement in real time. Build your past performance library once, mine it forever. Track every bid. Learn what wins. Before you submit, run an evaluator simulation that scores the proposal the way the government will, so you know whether it will win, not just whether it complies.

This is not a feature gap between us and the competition. This is market failure at $793 billion scale - and RFP Tank is the correction.

3. Problem Statement

3.1 The Broken Status Quo

Government contracting is a $793 billion market with a proposal problem. Every awarded contract requires a winning response to a solicitation. The average federal RFP runs 50-200 pages. It contains dozens of mandatory requirements, multiple evaluation criteria, a compliance matrix that must be manually built, and formatting rules that disqualify non-conforming submissions. A single RFP response takes 40-200 hours of work. A mid-sized contractor might pursue 20-30 per year.

Here is how contractors currently handle this:

The result: small contractors are fighting $793 billion in opportunity with tools designed for a different era. They lose not because their work is inferior - they lose because their proposals are non-compliant, incomplete, or poorly structured. The requirement was there. They missed it. Or they addressed it halfway. Or they forgot to map it to an evaluation criterion. The government evaluator marks them down. The work goes to someone with a better proposal team.

3.2 The Target User

RFP Tank serves three distinct users, all underserved:

Persona 1: The Solo Contractor

• Independent consultant or 1-person LLC pursuing federal or SLED contracts
• NAICS-certified, possibly 8(a), SDVOSB, or WOSB set-aside eligible
• Typically chases 5-15 opportunities per year
• Writes every proposal themselves or pays consultants per engagement
• Needs: discovery, compliance matrix automation, guided drafting, past performance management
• Current solution: SAM.gov + Word + prayer
• Willingness-to-pay hypothesis: $79/month if it saves 20 hours on one proposal (to validate in discovery interviews)

Persona 2: The Small GovCon Firm

• 2-20 person firm with a dedicated BD function or part-time capture manager
• Pursues 20-50 opportunities per year across federal and SLED
• Has some past performance history but no organized library
• Needs: team collaboration, pipeline tracking, past performance vault, win/loss analytics
• Current solution: A mix of tools, spreadsheets, and shared drives
• Willingness-to-pay hypothesis: $249-$599/month if win rate improves even marginally (to validate in discovery interviews)

Persona 3: The Emerging Prime

• Mid-sized firm (20-100 employees) that has won subcontracts and is now pursuing primes
• Evaluating GovEagle but balking at the enterprise sales cycle
• Needs: full lifecycle support, compliance tracking, reuse library, team features
• Current solution: Considering GovEagle or has an existing GovEagle contract
• Willingness-to-pay hypothesis: $599/month or custom enterprise if the product matches GovEagle's depth (to validate in discovery interviews)

3.3 The Gap That RFP Tank Fills

The market is not missing a search tool. SAM.gov is free. The market is missing a proposal execution engine - a tool that takes you from "I found an opportunity" to "I submitted a winning, compliant response" with AI assistance at every step. No existing tool does this for self-service users at any price point. That is the gap. It is not subtle. It is not a feature gap. It is a complete market absence at the most critical point in the contractor workflow.

4. Market Analysis

4.1 Total Addressable Market (TAM)

The federal government contract market is one of the largest and most consistent spending pools in the world. It does not contract in recessions. It does not go to zero. It carries a statutory 23% small business contracting goal, roughly $182 billion of the $793 billion total.

TAM: Roughly 200,000 active small business government contractors (per the SAM analysis in 4.2). At a $200/month average for a dedicated proposal tool, the addressable market is $480 million ARR.

Capture target: Even capturing 2% of the $480M TAM is $9.6M ARR - a venture-scale business from a small customer base. The near-term target (619 accounts, 0.31% penetration in 4.3) is deliberately conservative against this ceiling.

The key insight: A 1% win-rate improvement on the small business set-aside portion alone ($182 billion) is worth $1.8 billion in additional contract awards to small businesses. If RFP Tank helps a contractor win one additional $500K contract per year, it has delivered 50x the value of a $599/month subscription. That is the unit economics story that makes this product a no-brainer purchase.

4.2 Serviceable Addressable Market (SAM)

The 200,000 is an umbrella spanning independent consultants, 2-20 person firms, and emerging primes of up to 100 employees - all of which qualify as small businesses under SBA size standards, counted once to avoid double-counting. The 500,000+ registered SAM.gov entities is the top-of-funnel universe; roughly 200,000 are active pursuers.

4.3 Serviceable Obtainable Market (SOM)

Year 1 penetration of 0.31% requires finding 619 customers in a market of 200,000. That is not a growth problem. That is a targeting problem - and GovCon is one of the most targetable communities in B2B software (LinkedIn by NAICS code, GovCon forums, APEX Accelerators, 8(a) cohort lists).

4.4 Competitive Landscape

The competitive comparison is not close. It is embarrassing for the incumbents:

Nobody does all of this. Nobody. Until now.

RFP Tank column reflects planned MVP capability at launch. Build status by feature is tracked in Section 5.

4.5 Why Competitors Cannot Simply Copy This

• GovEagle cannot add self-service without cannibalizing their enterprise sales model. Their entire go-to-market is white-glove enterprise. They will not pivot to serve the market they have spent years ignoring.
• GovDash is competing on price ("68x cheaper than GovWin"). They have already conceded the quality position - they cannot reclaim it without invalidating their own marketing.
• CLEATUS is a data platform with AI bolted on. Rebuilding around proposal execution would require rewriting the product from scratch.
• Vultron has $22M in Series A funding and is still figuring out onboarding. They are building for enterprise clients, not solo contractors.
• None of them have the guided response flow because building it requires deep domain expertise in proposal evaluation - Section L/M alignment, FAR compliance, evaluation criteria weighting. That is not engineering. It is a decade of GovCon experience baked into software.

5. Product Overview

5.1 Architecture

+------------------------------------------------------------------+
|                     RFP TANK PLATFORM                            |
+------------------------------------------------------------------+
|                                                                  |
|   DATA INGESTION LAYER                                           |
|   +-----------+  +--------------+  +------------------+         |
|   | SAM.gov   |  | USASpending  |  | State Procurement|         |
|   | API (free)|  | API (free)   |  | Portals (scraped)|         |
|   +-----------+  +--------------+  +------------------+         |
|         |               |                   |                   |
|         +---------------+-------------------+                   |
|                         |                                        |
|   AI PROCESSING PIPELINE                                         |
|   +-----------------------------------------------------+        |
|   | Opportunity Scorer | RFP Shredder | Content Miner  |        |
|   | (profile match)    | (60-second)  | (past perf)    |        |
|   +-----------------------------------------------------+        |
|                         |                                        |
|   USER LAYER                                                     |
|   +------------+  +------------------+  +------------------+    |
|   | Smart      |  | Guided Response  |  | Past Performance |    |
|   | Discovery  |  | Flow + Compliance|  | Vault + Mining   |    |
|   | Dashboard  |  | Copilot          |  |                  |    |
|   +------------+  +------------------+  +------------------+    |
|                         |                                        |
|   OUTPUT LAYER                                                   |
|   +----------+  +----------------+  +------------------------+  |
|   | Word/PDF |  | Compliance     |  | Win/Loss               |  |
|   | Export   |  | Matrix (Excel) |  | Analytics Dashboard    |  |
|   +----------+  +----------------+  +------------------------+  |
+------------------------------------------------------------------+

Technology stack: Node.js/Python backend, React frontend, PostgreSQL for user data, vector database for past performance content retrieval, LLM API for compliance checking and content generation.

5.1.1 Deployment Options - ITPP-INFRA Shared vs Dedicated

This section addresses the single most common enterprise buyer question: "where does this run?" RFP Tank is not an abstract cloud service - it runs on bare-metal infrastructure owned and operated by IT Pro Partner, with two deployment models to match the client's risk and isolation requirements.

Option A: ITPP-INFRA Shared Deployment (Default)

The solution runs on IT Pro Partner's existing production infrastructure (ITPP-INFRA), the same hardware and backup pipeline that powers ITPP's own operations.

Best for: Solo tier, Consultant tier, early Team tier pilots. Cost-efficient - leverages existing capacity with no dedicated hardware overhead. All infrastructure is documented and auditable under ITPP's existing operational controls.

Option B: Dedicated Deployment

The solution runs on US-owned, US-hosted dedicated infrastructure - AWS GovCloud, Azure Government, or a US-owned colo - provisioned specifically for the client, with a dedicated object-storage bucket and isolated backup pipeline. This tier exists specifically for workloads that cannot run on shared infrastructure: CUI, ITAR-controlled data, or covered defense information under DFARS 252.204-7012.

Best for: Enterprise clients handling CUI or ITAR-controlled solicitations, prime contractors with data-residency or US-person requirements, or organizations whose compliance framework requires dedicated, US-owned infrastructure with no shared-tenancy risk. The shared tier (Option A) is explicitly scoped to unclassified / FOUO-and-below data; anything at or above CUI routes to this tier. All infrastructure is managed by IT Pro Partner - the client never touches servers - but the hardware, storage, and backup pipeline are theirs alone.

Shared responsibility line: In both models, ITPP manages everything below the application layer (OS, Docker, database, backups, monitoring, patching, incident response). The client's only responsibility is user account management, profile configuration, and content submitted to the platform. This is the same operational model ITPP uses for all managed infrastructure - the client gets the benefit of bare-metal performance without any of the operational burden.

5.2 The Seven Core Features

Feature 1: Smart Discovery (SETTLED - core design)

Contractor builds a one-time profile: NAICS codes, set-aside eligibility (8(a), SDVOSB, WOSB, HUBZone), geographic preferences, contract size range, agency history. RFP Tank ingests SAM.gov daily and scores every new solicitation against the profile. User receives a morning digest: "3 new opportunities match your profile. 1 is a recompete at an agency where you have past performance. 1 closes in 14 days." Recompete detection flags expiring contracts the user has previously bid or won. When a tracked solicitation is amended, RFP Tank notifies the contractor with exactly what changed - a moved due date, a new clause, an added requirement - not just "an amendment was posted."

Feature 2: RFP Shredder (SETTLED - core design)

Paste a SAM.gov URL, upload a PDF, or drop in a Word document. In 60 seconds: extracts all requirements, maps them to Section L (instructions) and Section M (evaluation criteria), identifies mandatory vs. desirable criteria, flags ambiguous language ("will be evaluated favorably" - what does that mean?), estimates competition level based on set-aside type and historical award data.

Same input path for the contractor's own proposal: upload the response document or paste its URL, and RFP Tank scores it against the RFP. This is the two-input model - RFP in, proposal in, compliance score out. Proposals are often multi-file (technical approach, cost volume, attachments), so ingestion accepts 1..N documents as one submission, not a single file.

Output: a structured compliance matrix. Every requirement, its source section, its evaluation weight, and a response field. This alone saves 5-20 hours per RFP.

Feature 3: Guided Response Flow (OPEN - primary differentiator)

NOT "here is an AI draft, good luck." A step-by-step wizard that walks the contractor through every requirement, section by section. For each requirement: write or paste your response, hit Review, and the AI checks: Does this address the requirement? Does it use government-recognized terminology? Is there quantifiable evidence? Does it map to the evaluation criterion? Green/amber/red per requirement. Progress tracker: "You have addressed 23 of 47 requirements. 3 are partially addressed. 2 are at risk."

This is the product nobody else has built. This is the feature that justifies the price.

Feature 4: Compliance Copilot (OPEN - builds on Feature 3)

Real-time AI assistant that watches as you type. Not post-hoc review - live checking. "This paragraph addresses Requirement 4.2 but does not quantify the outcome. Add a metric (e.g., reduced processing time by 40%)." Tracks every requirement across the full response. Nothing slips through.

Feature 5: Past Performance Vault (OPEN - Team+ tier)

A structured library of every past contract, capability statement, and relevant project description. AI mining: when a new RFP comes in, the vault surfaces relevant past performance automatically. "For this IDIQ requirement around IT modernization, you have 3 relevant past performance references. Click to insert and customize." Over time, the vault becomes the contractor's most valuable asset. It gets smarter with every proposal.

Feature 6: Win/Loss Intelligence (OPEN - Team+ tier)

Track every bid submitted through the platform. Mark wins and losses as awards are announced. Over time, the AI identifies patterns: win rate by agency, by NAICS, by contract size, by proposal section quality score. "Your win rate on DoD contracts is 42%. On DHS contracts it is 67%. Your strongest proposals score 85%+ on the Technical Approach section. Your weakest score below 60% on Management Approach." That insight is worth more than the subscription cost.

Feature 7: One-Click Export (SETTLED - standard)

Export the complete proposal in Word format (formatted per RFP instructions), PDF, or SharePoint-compatible package. Compliance matrix exports to Excel. Auto-generated cover letter. Everything formatted, nothing left to clean up.

5.3 The Differentiation Layer: Traceability + Evaluation

The seven core features are the workflow. This layer is the moat. The gold standard is not a longer feature list - it is depth on the one thing every competitor does shallowly (traceability), plus an evaluation layer none of them do at all.

The three-product handoff keeps lanes clean: RFP Tank owns everything UP TO writing (extract, map, gap-check, score). ProposalTank writes the prose. VerdictTank reviews the finished draft. No feature bleed between them.

A. Traceability (the moat)

• Compliance matrix with evidence. Every mandatory requirement (shall/must) extracted, mapped to the exact proposal paragraph that answers it, with a confidence score and quoted evidence. Exportable to XLSX/PDF. This is the deliverable a pursuit manager prints and hands to leadership.
• Gap report ranked by consequence. Not "14 requirements unaddressed," but "these 3 are shalls = disqualifier risk; these 5 are thin = weaknesses; these 6 are fine." Separate the 3 real risks from the 11 fine items.
• Terminology mirroring. Flag where the proposal should echo the RFP's exact wording (evaluators keyword-scan) and where it is vague.

B. Evaluation (the differentiator, leverages the VerdictTank panel)

• Section-level scoring. A 0-100 score per requirement and per section, not just pass/fail.
• Evaluator simulation. Score the proposal AS the government would, using the RFP's own evaluation criteria and weights. Answers "will it win," not just "does it comply." This is the inherited VerdictTank panel engine pointed at the compliance layer.
• Compliance status taxonomy. Compliant / Partially / Non-compliant / Not addressed, each with evidence.

C. Mechanical compliance (boring but disqualifying)

An automated gate for page count, font, margins, per-volume page limits, required forms and signatures, and naming conventions. The top reason proposals are rejected unread.

D. Make-writing-a-breeze (still RFP Tank lane, no prose)

• Response outline generator. Turn Section L into a writer's outline with each requirement pre-mapped to a section and a page budget per section. The writer fills in, never starts blank.
• Real-time side-by-side. Requirement on the left, draft on the right, compliance score updates as the writer types.
• Amendment-aware re-diff. When the RFP changes, show exactly which requirements and answers are now stale.

Prioritized build wedge

1. Compliance matrix + gap report (core deliverable, biggest moat).
2. Mechanical compliance gate (cheap, high perceived value).
3. Evaluator simulation (the "will it win" layer).
4. Real-time side-by-side scoring (the "breeze").
5. Outline generator + terminology mirroring + amendment re-diff.

5.4 Build vs. Buy Status

Infrastructure: Runs on existing ITPP app servers (app1/app3). No new servers required at MVP. LLM API costs are variable and passed through via usage-aware tier limits.

5.5 Deployment Status Grid

5.6 Pricing Tiers

Pricing rationale: GovEagle does not publish pricing and serves mid-to-large primes with a full sales cycle. We charge $79/month and serve the other 99% - walk-up, self-service, no demo required. The Solo tier is priced to convert on impulse. The Consultant tier is priced where a single proposal win pays for 5 years of the subscription. The Team tier is priced transparently at $599/month for up to five users, with no demo or sales call required.

6. Revenue Model

6.1 Revenue Streams

Enterprise contracts (custom, ~$2,000/mo) are excluded from the base model; 2-3 added in Q4 would push Year 1 total above $500K.

6.2 Pricing Rationale - Why These Numbers Are Right

This is not budget pricing. It is premium pricing positioned below enterprise alternatives. Here is the ROI math for each tier:

Solo at $79/month:

A solo contractor pursuing 10 RFPs per year spends 40-100 hours per response. At a blended rate of $100/hour in opportunity cost, that is $40,000-$100,000 in annual labor. Saving 30% of that is $12,000-$30,000 in value. The subscription costs $948/year. ROI is 12:1 to 30:1. This is a no-brainer at double the price. We price it at $79 to make the conversion decision require zero deliberation.

Consultant at $249/month:

A GovCon consultant who wins a single $300K task order earns a fee of $30K-$60K. If RFP Tank helps them win one additional contract per year that they would have otherwise lost, the subscription ($2,988/year) is irrelevant noise against a $30K fee. This tier also unlocks the Past Performance Vault - which becomes the consultant's competitive moat over time. Priced at $249 for transparent self-service access to an enterprise-grade feature set that GovEagle gates behind an unpublished enterprise sales process.

Team at $599/month:

A 5-person BD team at a small GovCon firm costs $300K-$600K in annual salaries. A 10% improvement in proposal quality that lifts win rate from 30% to 33% on a $10M pipeline generates $300K in additional contract awards. The subscription costs $7,188/year. The comparison is not close. We price at $599 because that is where a decision-maker can approve it without a committee.

Enterprise at Custom:

Enterprise accounts start at approximately $2,000/month and are scoped based on user count, API access, white-label requirements, and SLA needs. This is where the GovEagle comparison lands - we offer a comparable enterprise feature set with transparent pricing and self-service onboarding, versus GovEagle's unpublished enterprise pricing and 1-week implementation requirement.

6.3 Cost Structure

Key insight: The infrastructure advantage is real. Other startups in this space are paying $5,000-$15,000/month in AWS/GCP costs before they write a line of product code. ITPP infrastructure is already running. That is a structural cost advantage that compounds as we scale.

6.4 Gross Margin

At full scale (619+ accounts), estimated gross margin is 78-85%. The primary variable cost is LLM API usage, which is manageable through tier-based usage limits (RFPs per month, compliance checks per day). A single compliance check is 1-2 LLM calls of roughly 1,000-2,000 tokens, or about $0.02-$0.05 at current Claude/GPT pricing; a heavy session of 50 checks costs $1.00-$2.50, leaving the $79/month Solo tier at 80%+ gross margin even under daily-use limits. Real-time copilot latency is bounded to roughly 1-2 seconds per check with streaming, acceptable for an inline writing assistant. Unlike a services business, the marginal cost of serving the 501st customer is near zero.

6.5 12-Month Revenue Ramp

Year 1 total revenue: ~$472K (conservative ramp, 0% churn assumption in early months is unrealistic - see Risk section).

End-of-year MRR run rate: $106,581 ($1.28M ARR) across 619 paying accounts.

These numbers assume no enterprise contracts in Year 1. With 2-3 enterprise accounts added in Q4, Year 1 total exceeds $500K and end-of-year ARR exceeds $1.3M.

7. Competitive Advantages (Moat)

7.1 The Seven Knockout Blows

These are not features. They are structural advantages that compound over time. Each one is hard to copy individually. Together, they are a fortress.

To be precise about what is and is not durable: three of the seven are structural advantages that take real build time and GovCon domain knowledge (profile-driven matching, guided response flow, real-time compliance). Two are positioning choices a competitor could copy in a quarter if it decided to (self-service pricing, full-stack coverage). The durable, compounding moat is Knockout 4 plus Section 7.3 - the Past Performance Vault and win/loss data lock-in, which cannot be copied because the value lives in the user's own data, not in our code.

Knockout 1: Profile-Driven Proactive Matching

Every other tool is reactive - you go find the RFP. RFP Tank finds the RFP for you, scores it against your profile, and tells you which ones are worth your time before you ever open the solicitation. Nobody else does this end-to-end. It requires building a profile engine, a scoring algorithm, and a daily ingestion pipeline. CLEATUS does partial matching but without the full profile context or the scoring depth.

Knockout 2: Guided Response Flow

This is the product nobody built. It is the feature that should exist and does not. The reason: building it correctly requires understanding how government proposals are evaluated - Section L/M alignment, FAR clause awareness, evaluation factor weighting. That knowledge is not in engineering departments. It is in proposal professionals. We are building it first, ahead of everything else, because it is the differentiator the rest of the product hangs on. No competitor has it, and none is positioned to build it quickly.

Knockout 3: Real-Time Compliance Copilot

Every other AI in this space does post-hoc review: "Here is a score for your completed proposal." We check in real time, as you write. The distinction is not cosmetic - catching a compliance gap while writing is 10x cheaper than catching it after you have written 40 pages that need to be rewritten. This is a workflow advantage that shows up in win rates, not just user experience.

Knockout 4: Past Performance Vault With AI Mining

Your past performance is your biggest competitive asset in government contracting. It is also scattered across email chains, old Word documents, and the memory of your BD team. The Vault organizes it, and the AI mines it automatically for each new opportunity. Over time, users who have populated their vault have a compounding advantage over users who have not - and over competitors whose tools do not offer this capability at all.

Knockout 5: Win/Loss Analytics

This is CRM for proposal professionals. Track every bid, mark outcomes, and let the AI identify what separates your wins from your losses. No competitor offers this at the SMB level. Enterprise BD teams at large primes do this manually with spreadsheets. We automate it for solo contractors and 5-person BD teams at a fraction of the cost.

Knockout 6: Transparent Self-Service Pricing

The GovCon software market is dominated by "book a demo" gatekeeping. GovEagle, GovDash, Vultron, Rohirrim - none of them will tell you what they charge without a sales call. That is a conversion killer for small contractors who do not have time for a 3-meeting sales cycle. RFP Tank has a pricing page. You can be live in 5 minutes. No demo. No call. No contract negotiation. That is a product-led growth strategy that scales without a sales team.

Knockout 7: Full-Stack Workflow for Any Contractor Size

Every competitor serves a slice of the market. GovEagle serves large primes. CLEATUS serves individuals (with a shallow product). Nobody serves the full spectrum - from solo consultant to 50-person firm - with a single product that scales appropriately. RFP Tank does. One platform, four tiers, zero workflow gaps. A solo contractor who grows to a 10-person firm does not need to switch tools. They upgrade their tier.

7.2 Competitive Positioning Map

                HIGH CAPABILITY
                      |
          RFP Tank    |   GovEagle
          [Solo-Ent]  |   [Enterprise]
                      |
SELF-SERVICE ---------+--------- ENTERPRISE-ONLY
    $79/mo            |              Unpublished
                      |
          CLEATUS     |   GovDash
          [Search]    |   [Price-led]
                      |
                LOW CAPABILITY

RFP Tank occupies the upper-left quadrant - high capability, self-service access. No competitor is positioned there. That is not an accident. Building high capability AND self-service simultaneously is hard. It requires product discipline that most enterprise-focused companies cannot apply because their incentive is to serve enterprise customers with white-glove support, not to make the product simple enough for a solo contractor to onboard in 5 minutes.

7.3 The Moat Gets Deeper Over Time

The Past Performance Vault creates data lock-in. Users who have spent 6 months populating their vault with past contracts, capability statements, and proposal content are not switching tools. The switching cost is not financial - it is the loss of an organized, AI-indexed library that took months to build. This is the same moat Salesforce uses (CRM data lock-in), applied to the GovCon proposal workflow.

Win/Loss data deepens the moat further. After 12 months of tracking bids and outcomes, the platform knows which proposal sections correlate with wins for that specific contractor, at that specific agency, in that specific NAICS. That intelligence is contractor-specific and cannot be transferred to a competitor's tool.

8. Go-to-Market Strategy

8.1 Phase Structure

8.2 First 100 Customers - Where They Come From

1. LinkedIn GovCon community - There is a large, active community of government contractors on LinkedIn. Posts about proposal pain points, compliance matrices, and SAM.gov go viral in this community. A single high-quality post from a credible voice ("I built a tool that shreds an RFP into a compliance matrix in 60 seconds") reaches thousands of relevant people organically.

1. APEX Accelerator offices - APEX Accelerators (formerly Procurement Technical Assistance Centers) exist in every state. They are funded by the DoD to help small businesses win government contracts. They actively look for tools to recommend to their clients. A 30-minute conversation with an APEX Accelerator director can unlock referrals to 50-200 contractors in that region.

1. 8(a) cohort lists - The SBA publishes lists of 8(a)-certified firms. These are small disadvantaged businesses in the program specifically to win government contracts. They are exactly our user. LinkedIn outreach to 8(a) firm principals converts at high rates because their pain is acute and our solution is direct.

1. GovCon forums and communities - GovLoop, Govcon Giant (Joshua Frank's community), NCMA (National Contract Management Association) members, APMP (Association of Proposal Management Professionals). These communities have high concentrations of our exact target user.

1. APMP partnership - The Association of Proposal Management Professionals is the professional association for proposal writers. An endorsement or partner listing here reaches the most sophisticated buyers in the space and lends immediate credibility.

1. Germaine's existing network - IT Pro Partner has existing relationships with government contractors, MSP clients, and the broader business community. Warm introductions from a trusted advisor convert at 3-5x the rate of cold outreach.

1. Veteran business networks - SDVOSB (Service-Disabled Veteran-Owned Small Business) owners are a concentrated, self-identified group with acute proposal pain. VetBiz, American Legion posts, SCORE chapters with veteran programs.

1. Content marketing - "How to build a compliance matrix in 30 minutes" is a top-searched query among GovCon professionals. A library of practical how-to content on rfptank.com drives organic search traffic from exactly the right audience.

1. GovWin / Deltek community - GovWin (now owned by Deltek) charges $40K/year and has an enormous dissatisfied customer base. Anyone who has ever searched for a GovWin alternative is a perfect target. SEO and LinkedIn ads targeting GovWin users convert efficiently.

1. Twitter/X GovCon accounts - A handful of high-follower GovCon educators and consultants on X have audiences of 10K-50K exactly aligned with our target user. A single mention or repost from one of these accounts can drive hundreds of signups.

8.3 Channel Strategy

All conversion rates above are planning hypotheses based on benchmark SaaS funnels and adjacent GovCon communities; none have been field-tested. The first 90 days are scoped to validate these against real channel data before scaling spend (see 9.6).

8.4 Product-Led Growth Hook

The RFP Shredder is a natural free-trial hook. Let any user - without an account - paste a SAM.gov opportunity link and get a preview compliance matrix (first 10 requirements extracted, rest gated). This creates an immediate "holy sh*t" moment. The prospect sees the value before they give us an email address. When they hit the gate on requirement #11, they sign up. This is how Figma, Loom, and Notion grew their initial user bases - lead with the product, not the pitch.

9. Risk Analysis

9.1 Market Risks

9.2 Product Risks

9.3 Competitive Risks

9.4 Operational Risks

9.5 Pre-Mortem: What Kills This Within 6 Months

The most likely failure modes, in order of probability:

1. The guided response flow ships too slow. If the differentiating feature - the guided wizard with real-time compliance checking - takes 6 months to build, we launch with just the RFP Shredder. The Shredder is useful, but it is not a sufficient moat. GovDash and GovEagle both have compliance matrix generation. Without the guided flow, we are just another RFP tool. Mitigation: the guided flow is feature #1, not feature #7. Build it first, ship everything else after.

2. Trial-to-paid conversion is below 5%. If users love the free RFP Shredder preview but do not convert to paying subscribers, the product-led growth loop breaks. This usually means the paywall hits before users see enough value, or the paid features are not differentiated enough from the preview. Mitigation: track conversion rates weekly from Day 1; iterate the paywall and trial experience aggressively in the first 60 days.

3. LLM API costs eat the margin. At scale, if users are running dozens of compliance checks per session and the per-check LLM cost is not bounded, gross margin compresses to zero. Mitigation: enforce per-tier daily limits from Day 1; cache common document parsing results; monitor API spend daily.

4. GovCon community does not trust a new tool with proposal data. Government contractors are paranoid about data security for good reason - proposals contain pricing strategies, teaming agreements, and proprietary technical approaches. If RFP Tank cannot answer basic security questions (encryption, data retention, who can access my data), the trust barrier kills conversion. Mitigation: publish a clear security page before launch; answer these questions proactively on the pricing page.

5. Product-market fit is in Consultant tier, not Solo. The economics of Solo ($79/month) require high volume to generate meaningful revenue. If product-market fit turns out to live in the Consultant ($249) and Team ($599) tiers - which is plausible, since those users have more acute pain and more financial stake in win rates - the marketing strategy needs to tilt toward that segment immediately. Mitigation: track ARPU and NPS by tier; respond to where the enthusiasts actually are.

9.6 90-Day Success Metrics

10. Financial Projections

10.1 12-Month P&L

Notes on assumptions:

• Labor costs reflect contractor/developer time at modest rates; Germaine's ITPP time is not fully burdened
• Infrastructure costs are $0 (existing ITPP servers); this is a real advantage vs. startups paying $5K+/month in cloud costs
• Marketing spend ramps with revenue; never exceeds 8% of MRR at scale
• LLM API costs assume $0.002 per 1K tokens blended, with tier-based usage limits controlling total
• No enterprise contracts modeled (conservative); first enterprise contract in Q4 would add $6,000-$24,000 to Q4 revenue

10.2 Unit Economics

LTV/CAC ratios above 3:1 are considered healthy for SaaS. Ratios above 10:1 indicate potential underinvestment in growth. All four tiers show ratios in the 27:1 to 78:1 range. Note these ratios rest on CAC figures that are planning estimates, not field-tested channel data; they indicate room to increase acquisition spend once real CAC is measured, not permission to spend ahead of validation. On churn: the 3% monthly Solo assumption compounds to ~8.7% over 90 days, just under the 'Under 9%' success threshold in section 9.6 - a deliberately tight margin that makes early churn the model's most sensitive assumption and the primary Month-4 go/no-go gate.

10.3 Break-Even Analysis

At the early-stage cost structure from 6.3 (~$3,000-$5,000/month in OpEx excluding labor), the business turns cash-flow positive in Month 2 and net-income positive (including a $5,000/month labor allocation for Germaine's opportunity cost) in Month 4, at 77 paying subscribers and ~$11,200 MRR.

The $10,000-$12,000/month OpEx figure is the Month 11-12 scale structure (see 10.1), reached only after the business is running ~$90,000/month in net income. Break-even is an early-months event, not a scale-stage milestone - a realistic and achievable timeline for a product with genuine product-market fit.

10.4 Three-Scenario Model (Year 1)

The conservative scenario requires 619 paying accounts by Month 12. The realistic scenario adds enterprise contracts and assumes one major APEX Accelerator or APMP channel activation. The aggressive scenario assumes a product that becomes the default recommendation in GovCon communities by Month 6 - plausible if the guided response flow delivers on its promise.

10.5 3-Year Outlook

Year 3 ARR of $16M at 80% gross margin is a $130M+ valuation at standard SaaS multiples (8-10x ARR). This is not a lifestyle business. It is a venture-scale outcome from a $0 infrastructure investment and a domain that costs $15/year.

11. The Ask

11.1 Resources Needed to Launch

Total hard dollar cost to launch: ~$2,500-$5,000 (contract-developer contingency plus marketing), removing the single point of failure without waiting for traction. The rest is ITPP infrastructure (already paid for) and Germaine's time. This is the single best risk/reward ratio in the current ITPP product portfolio.

11.2 Immediate Decisions Required

These decisions need answers before Week 2. Each one unblocks a subsequent action.

Decision 1: Domain - Register rfptank.com NOW

Recommendation: Register rfptank.com today. Domains at this price point that are available do not stay available if the concept leaks. This is a $15 decision with potentially significant downstream value. There is no reason to delay.

Decision 2: Product vs. Consulting Play

RFP Tank is an IT Pro Partner SaaS product. It is not a GovCon consulting practice. The product helps others win contracts; ITPP does not bid contracts using it (yet). There is an optional future play where Germaine's veteran colleague and ITPP form a minority-veteran-owned JV that USES RFP Tank to bid on IT contracts - creating live case studies and a demonstration environment. But the product itself launches as ITPP software. Confirm: product play first, consulting JV optionally later.

Decision 3: Build Sequence

The guided response flow is the differentiator. It should be Feature 1, not Feature 7. Proposed sequence:

1. SAM.gov ingestion + profile matching (2 weeks)
2. RFP Shredder + compliance matrix (2 weeks)
3. Guided response wizard MVP (4 weeks)
4. Marketing site + billing + auth (2 weeks)
5. Beta launch (Week 12)

This sequence carries two weeks of built-in slack. The guided response wizard MVP (4 weeks) is the critical path, and the daily SAM.gov ingestion is contracted out (see 11.1) so it does not compete for Germaine's time. If the guided flow slips, beta still ships on the RFP Shredder + profile matching (already differentiated), and the guided flow lands in Week 12.

Confirm this build order before Day 1 of development.

Decision 4: Pricing Confirmation

The tiers proposed ($79/$249/$599/custom) are recommendations. They are priced to be premium without being enterprise. If Germaine wants to price higher (e.g., Solo at $99, Consultant at $299) the unit economics only improve. If the goal is maximum early traction, the current tiers are correct. Confirm pricing before the marketing site goes live.

Decision 5: IT Pro Partner Branding

Does rfptank.com show "Powered by IT Pro Partner" or does it stand alone as a brand? Most SaaS products benefit from standalone branding for credibility in a niche market. ITPP is an MSP brand; RFP Tank is a GovCon software brand. They serve different audiences. Recommendation: standalone brand for rfptank.com, with a discreet "A product of IT Pro Partner" attribution in the footer.

11.3 What Success Looks Like at Month 12

The benchmark for "product-market fit confirmed" is Month 4: 50+ paying subscribers who were NOT given the product for free, with NPS above 40 and monthly churn below 3%. If those three numbers are green at Month 4, this product grows to $1.28M ARR. If they are red, we know what to fix before we have spent real marketing dollars.

11.4 The Bigger Picture

RFP Tank is not just a product. It is a position in a $793 billion market that nobody has credibly claimed at the self-service level. The government contracting industry is underserved at the small business layer because the tools that exist were built for the large primes, not for the contractors who need them most.

Every month that passes without RFP Tank is a month that 50,000+ small business contractors submit proposals in Word, built with spreadsheet compliance matrices, without a single line of AI assistance on whether they actually addressed the requirement they think they addressed. Some of them will lose contracts they deserved to win. Some of them will exit the GovCon market entirely, convinced the system is rigged, when the real problem was a solvable workflow failure.

RFP Tank does not just serve the market. It corrects a market failure at scale. That is the kind of business worth building.

The competition saw what was possible in this market. They served the 1% and ignored the rest. That was their plan. And then RFP Tank is going to hit them in the mouth.

Appendix A: Competitor Pricing Deep Dive

Observation: Only CLEATUS publishes walk-up pricing in the self-service segment. Every other player gates pricing behind a sales call. RFP Tank and its published tier structure will be immediately differentiated from every enterprise competitor the moment the pricing page goes live.

Appendix B: Data Source Summary

Total data infrastructure cost: $0. The public data is free. The value is not in the data - it is in what you do with it.

Proposal prepared by IT Pro Partner | Germaine Brown | August 2026

RFP Tank is an IT Pro Partner product. rfptank.com is confirmed available as of proposal date.

All market data sourced from SAM.gov, USASpending.gov, SBA.gov, and publicly available competitor research.

2. Subscriber Requirements

Captured live during ideation with Germaine. One entry per numbered

requirement as they are stated. This file is the source of truth for the

subscriber-facing behavior; the proposal (rfptank-proposal.md) and architecture

(v3.6-architecture.md) reference it.

Requirement 1 - Subscriber proposal ingestion

A logged-in subscriber can submit their proposal for compliance review by either:

• Uploading the proposal document(s) as files, or
• Providing a URL to the proposal.

Design notes (to resolve before build)

1. Two ingestion paths, one normalized output. File upload and URL fetch are

different code paths that must both converge on extracted, clean text before

compliance scoring runs. File upload = parse PDF/DOCX/etc. URL = fetch +

extract (PDF download, Google Docs/SharePoint export, or plain page).

1. This is the second half of the two-input model. The existing proposal

already specs the RFP side ("Paste a SAM.gov URL, upload a PDF, or drop in a

Word document"). Requirement 1 is the PROPOSAL side. RFP Tank scores the

proposal against the RFP, so a full run needs BOTH ingested.

1. Proposals are often multi-file. Technical approach, cost/price volume,

attachments, past performance. Ingestion must accept 1..N documents and treat

them as one submission, not a single file.

1. URL path has a hard case. Auth-gated links (Google Docs, SharePoint,

portals behind login) and non-extractable pages are the common failure. The

URL flow needs a clear "can't reach this link" error with a fallback to

manual upload, not a silent empty ingest.

1. Login gates everything downstream. "Log into the portal" is the first

step of the journey, so auth (shared Stack Auth/Clerk tenant) has to exist

before any ingestion is usable. This is a dependency on the shared auth layer

already decided for ProposalTank + VerdictTank + RFP Tank.

Requirement 2 - Profile NAICS + RFP change notifications

Two parts, both from Germaine's second requirement message.

2a. NAICS codes on the subscriber profile

How many NAICS codes a subscriber can attach to their profile. Purpose: NAICS

is the primary filter for RFP matching/tracking (which opportunities are

relevant to this subscriber).

• Recommendation: 10 NAICS per profile, flat. Real contractors median 2-4,

~99% under 10. Keeps matching signal clean.

• Optional upsell lever (only if wanted): Free 3 / Pro 10 / Enterprise

unlimited.

• UX: do not require typing 6-digit codes. Ask for primary NAICS or a one-line

business description and auto-suggest related codes from the NAICS hierarchy.

2b. RFP change/amendment notifications for tracked solicitations

When a subscriber is tracking an RFP and that RFP is amended or changed, send

them a notification. Table-stakes feature (all competitors do amendment

alerts; a missed amendment = late or non-compliant proposal).

• Mechanism: subscriber tracks a solicitation (notice ID). System polls the

SAM.gov Opportunities API for that notice on a schedule (every 6-12 hrs),

diffs against last-seen version, notifies on change.

• Change types to detect: amendment posted, due date moved, NAICS changed,

set-aside changed, requirements/description updated.

• Channels: email + in-app minimum. SMS/Telegram for deadline-critical changes

as a premium add.

• Differentiator: report WHAT changed (due date, new clause, added

requirement), not just "an amendment was posted."

Gold-standard feature brainstorm (2026-08-28)

Frame: the gold standard is not a longer feature list, it is depth on ONE

thing competitors do shallowly - traceability - plus an evaluation layer they

do not do at all. RFP Tank owns everything UP TO writing; ProposalTank writes

the prose; VerdictTank reviews the draft. No feature bleed.

A. Traceability (the moat)

• Compliance matrix: every mandatory requirement (shall/must) extracted,

mapped to the exact proposal paragraph that answers it, with confidence and

quoted evidence. Exportable to XLSX/PDF. This is the deliverable a pursuit

manager prints and hands to leadership.

• Gap report ranked by consequence: unaddressed shalls = disqualifier risk;

thin coverage = weakness; separate the 3 real risks from the 11 fine items.

• Terminology mirroring: flag where the proposal should echo the RFP's exact

wording (evaluators keyword-scan) and where it is vague.

B. Evaluation (the differentiator, leverages VerdictTank panel)

• Section-level 0-100 score per requirement and per section (user's example).
• Evaluator simulation: score the proposal AS the government would, using the

RFP's own evaluation criteria and weights. Answers "will it win", not just

"does it comply". Uses the inherited VerdictTank panel engine.

• Compliance status taxonomy: Compliant / Partially / Non-compliant / Not

addressed, each with evidence.

C. Mechanical compliance (boring but disqualifying)

• Page count, font, margins, page limits per volume, required forms and

signatures present, naming conventions. Automated gate. Top reason

proposals are rejected unread.

D. Make-writing-a-breeze (still RFP Tank lane, no prose)

• Response outline generator: turn Section L into a writer's outline with

each requirement pre-mapped to a section and a page budget per section.

Writer fills in, never starts blank.

• Real-time side-by-side: requirement left, draft right, compliance score

updates as they type.

• Amendment-aware re-diff: when the RFP changes, show exactly which

requirements and answers are now stale (extends Req 2b).

Prioritized wedge (build order)

1. Compliance matrix + gap report (the core deliverable, biggest moat).
2. Mechanical compliance gate (cheap, high perceived value).
3. Evaluator simulation (the "will it win" layer).
4. Real-time side-by-side scoring (the "breeze").
5. Outline generator + terminology mirroring + amendment re-diff.

3. Baseline Scoring (R3)

4. Architecture

Status: Build specification, companion to the v3.6 business proposal.

Scope: Extends the v3 architecture (5-stage pipeline, 4 API endpoints, 10 data model tables) with the 9 new v3.6 capabilities: Chat-to-Refine, URL-to-Review, Dual Scoring, Explain-the-Low-Score, Fix-It Remediation, Second-Opinion Audit Agent, Configurable Rules Engine, White-Label for Consultants, and Roast/Boost Community Peer Review.

Audience: Engineering. This is the build spec, not the pitch.

1. System Overview

v3.6 scope note (Priority Fix #6 / Judge 3 Week 1 Cut List): The critical review of v3.6 found the 15-service, 21-table build scoped "like a multi-engineer build" for a solo-founder timeline. This document now describes two tiers: the 8-Week MVP (5 services, shipped) and Deferred (Post-Launch) components (5 services, designed but not built until a funnel/demand signal justifies them). Deferred components' schemas and designs are preserved below for continuity - cutting scope does not mean deleting the design work, it means sequencing it after MVP validation. See Section 9 for the revised build sequence.

1.1 Architecture Diagram - 8-Week MVP Scope

                                   ┌─────────────────────────────────────────────┐
                                   │                CLIENTS                       │
                                   │  Web App · Mobile · API Consumers            │
                                   └───────────────────┬───────────────────────────┘
                                                        │ HTTPS
                                   ┌────────────────────▼────────────────────────┐
                                   │           EDGE / API GATEWAY (Caddy)          │
                                   │  TLS term · rate limit · auth (JWT/API key)   │
                                   │  request logging                              │
                                   └───────┬───────────────────────────────────────┘
                                           │
                     ┌─────────────────────▼───────────────────────┐
                     │     APPLICATION SERVICES (MVP: 2 of 5 kept) │
                     │  review-api · chat-api                      │
                     └───────────┬───────────────────────────────────┘
                                 │ enqueue
                     ┌───────────▼───────────────────────────────────────────────┐
                     │                    JOB QUEUE (Redis + RQ/Celery)           │
                     │  review.pipeline · chat.turn · url.extract                 │
                     │  remediation.generate · sanitize.scan                     │
                     └───────────┬─────────────────────────────────────────────────┘
                                 │
     ┌───────────────────────────▼──────────────────────────────────────────────────┐
     │                         REVIEW PIPELINE WORKERS (pipeline-worker)              │
     │                                                                                │
     │  Phase 1        Phase 2         Phase 3          Phase 4       Phase 5         │
     │  Research  ──▶  Primary    ──▶  Validation  ──▶  Cross-Check ──▶ Verdict        │
     │  Agent          Reviewer        Reviewer          A + B (‖)     Aggreg.        │
     │  (web verify    (10-dim,        (challenges       (independent  (majority       │
     │   + citations)   1-10 + tags    primary score)     re-score)     + dual         │
     │                  idea/proposal)                                  scores)        │
     │                                                                                │
     │  [Phase 6 - Audit Agent: DEFERRED, see §1.2 and §9 Post-Launch Track]          │
     └───────────┬─────────────────────────────────────────────┬──────────────────────┘
                 │                                             │
     ┌───────────▼───────────────┐                 ┌────────────▼──────────────────┐
     │   SANITIZATION GATE        │                 │   POST-PIPELINE GENERATORS      │
     │   scans: verdict JSON,     │                 │   Explainer (per-dim text)      │
     │   explanations, remediation,│                │   Fix-It Generator (action plan)│
     │   chat transcripts         │                │   (Rules Engine overlay: DEFERRED)│
     │   before egress             │                └──────────────┬───────────────────┘
     └───────────┬───────────────┘                                │
                 │                                                │
     ┌───────────▼────────────────────────────────────────────────▼───────────────┐
     │                              DATA LAYER                                       │
     │  PostgreSQL (primary OLTP, org_id column present but multi-tenant enforcement │
     │  (RLS) deferred until White-Label track - see §1.2)                          │
     │  pgvector (corpus embeddings/similarity)                                      │
     │  Redis (queue, session cache, rate limits, feature flags)                     │
     │  S3-compatible object store (PDFs, chat exports, uploaded docs, extracted HTML)│
     └─────────────────────────────────────────────────────────────────────────────┘

     ┌────────────────────────────────────────────────────────────────────────────┐
     │                     SUPPORTING SERVICES (MVP)                               │
     │  url-extractor (Crawl4AI) · fixit-generator · pdf-generator                 │
     │  cron (prediction T+90/180/365)                                            │
     │  [domain-verifier, moderation-queue: DEFERRED - see §1.2]                   │
     └────────────────────────────────────────────────────────────────────────────┘

1.2 Component List - MVP vs. Deferred

Per Priority Fix #6, the 8-week solo-founder MVP ships 5 services; the remaining 5 services from the original v3.6 scope are deferred to post-launch and gated on real usage/demand signal, not built speculatively. This directly implements the review's Week 1 Cut List (KEEP: Dual Scoring, Explain, Fix-It MVP, URL-to-Review, Corpus Schema / CUT: Audit Agent, Rules Engine, White-Label, Roast/Boost, and Chat-to-Refine deferred-not-deleted per below).

MVP - Ship in 8 Weeks (5 services)

Note on Chat-to-Refine placement: The review's Week 1 Cut List names Chat-to-Refine as a CUT ("funnel feature; build when you have a funnel"). This document keeps a minimal chat-api in MVP scope specifically because the ghostwriting guard in §5.1 is cheap to build (a length/format check, not new infrastructure) and de-risks the single biggest brand-reputation exposure identified by Judge 3 if Chat-to-Refine ships at all, in this MVP or later. If engineering capacity is tighter than modeled, chat-api is the first MVP component to cut - in which case Chat-to-Refine moves to the Deferred table below in its entirety, chat-ws and all real-time streaming remain deferred either way, and the guard design in §5.1 is preserved for whenever the feature ships.

DEFERRED - Post-Launch, Built on Demand Signal (5 services)

The rules-evaluator overlay logic (§5.7) and Rules Engine pipeline injection point are deferred along with rules-api - no schema or prompt-injection surface for org rules ships in MVP. The full designs for all deferred components remain documented in Sections 5.6-5.9 and 7 of this document as the intended post-launch build, not as speculative dead weight - they represent validated architecture pending a demand signal, not throwaway work.

MVP Data Layer implications: Row-level security (RLS) multi-tenant policies (§6.3, §7.4), the org_configs/org_rules/org_api_keys/rule_templates tables, and cross-org isolation logic are not required for MVP since org-api and rules-api are deferred - org_id columns remain present (nullable) on core tables for forward compatibility, but RLS enforcement, domain routing, and multi-tenant billing are built when the White-Label track is actually resumed, gated on Minimum Viable Legal per Section 4.

2. Complete Data Model

2.1 Entity Relationship Summary

users ──1:N── reviews ──1:1── verdicts ──1:N── dimensions ──1:1── dimension_explanations
  │               │                                  │
  │               │                                  └─1:N── remediation_plans (per dimension)
  │               ├──1:N── judge_scores ──N:1── judges
  │               ├──1:N── research_citations
  │               ├──1:N── predictions
  │               ├──1:N── audit_findings          (v3.6)
  │               ├──1:N── peer_reviews            (v3.6)
  │               └──1:1── chat_sessions (optional, pre-review link)  (v3.6)
  │
  ├──1:N── chat_sessions ──1:N── chat_messages      (v3.6)
  │
  └──N:1── org_configs ──1:N── org_rules ──N:1── rule_templates   (v3.6, enterprise/white-label)

corpus_entries (derived from verdicts, searchable, org_id-scoped)
audit_log (cross-cutting, all tables)

All new v3.6 tables carry org_id (nullable for individual/non-enterprise accounts) to support multi-tenant partitioning for White-Label. All v3 tables are extended with org_id as part of the Phase 0 migration described in Section 9.

2.2 v3 Tables (Extended for v3.6)

Dual-Score Schema Validation Gate (Priority Fix #2 / Judge 3 & Judge 1 finding, Architecture §2.2 lines 147-148 in the v3.6 review): The original v3.6 design baked idea_score/proposal_score directly into the reviews and corpus_entries tables as permanent NUMERIC columns from day one - a schema bet made before any beta user confirmed that a two-score split is more useful than the v3 single composite score. The review's Priority Fix #2 is explicit: "Do not bake idea_score/proposal_score into the corpus before validating with beta users that two scores are wanted. Gate the migration behind user testing, or ship dual-scoring as a non-schema overlay first."

>

v3.6 resolution - ship as overlay, migrate only after validation:

1. MVP ships dual scoring as a JSONB overlay, not dedicated columns. The idea_score/proposal_score values computed at Phase 5 (see §5.3) are written into verdicts.verdict_json (already a JSONB column, no migration required) under a dual_score key, and into a new reviews.dual_score_overlay JSONB column (nullable, additive, zero-downtime to add/drop) rather than as first-class typed NUMERIC(5,2) columns on reviews or corpus_entries.

2. The NUMERIC columns shown below (idea_score, proposal_score on reviews; same on corpus_entries, §2.3) are the target schema for GA, not the MVP schema. They are documented here for architectural continuity but are marked DEFERRED - VALIDATION GATE and must not be created by the Phase 0 migration until the exit criterion below is met.

3. Validation exit criterion (must pass before the permanent-column migration runs): a minimum of 25 beta users from the existing $29/mo Inner Circle cohort have used dual-score overlay output across at least 2 reviews each, and post-review survey/interview signal shows a majority preference for two scores over the legacy single composite. This reuses the same beta cohort the review's Priority Fix #1 calls for surveying - one survey instrument serves both purposes.

4. If validation fails (users prefer one score, or show no measurable preference), the dual_score_overlay JSONB column is dropped, verdict_json.dual_score continues to carry the value for backward-compatible display only, and the corpus indexing strategy in §2.3/§2.4 reverts to legacy_composite_score as the primary sortable/filterable column.

5. Corpus search and percentile lookups (§6.4) run against the JSONB overlay during the validation window - idx_corpus_dual_score_overlay is a GIN index on the JSONB path, functionally equivalent to a B-tree NUMERIC index for the query patterns in §3.2/§3.3 but avoids a schema commitment. Query latency is slightly higher (GIN vs. B-tree) but acceptable at MVP corpus volume; this is re-benchmarked before the permanent migration.

-- USERS (v3, extended)
CREATE TABLE users (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    org_id          UUID REFERENCES org_configs(id),      -- v3.6: multi-tenant scoping
    email           TEXT UNIQUE NOT NULL,
    password_hash   TEXT,
    tier            TEXT NOT NULL DEFAULT 'free',          -- free|pro|enterprise|white_label|beta
    role            TEXT NOT NULL DEFAULT 'member',        -- member|org_admin|consultant|superadmin
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_users_org ON users(org_id);

-- REVIEWS (v3, extended: dual score columns, submission source, org scoping)
CREATE TABLE reviews (
    id                  UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    org_id              UUID REFERENCES org_configs(id),
    user_id             UUID NOT NULL REFERENCES users(id),
    source_type         TEXT NOT NULL DEFAULT 'file',       -- v3.6: file|url|api
    source_url          TEXT,                               -- v3.6: populated when source_type='url'
    chat_session_id     UUID REFERENCES chat_sessions(id),  -- v3.6: link to pre-review coaching
    vertical            TEXT,
    status              TEXT NOT NULL DEFAULT 'queued',     -- queued|running|audit|done|failed
    idea_score          NUMERIC(5,2),                       -- DEFERRED - VALIDATION GATE: do not populate until dual-score validation exit criterion (§2.2) is met; MVP writes to dual_score_overlay instead
    proposal_score      NUMERIC(5,2),                       -- DEFERRED - VALIDATION GATE: see idea_score note above
    dual_score_overlay  JSONB,                              -- v3.6 MVP: { "idea_score": 78.5, "proposal_score": 41.0 }, non-schema overlay per §2.2 gate; promoted to typed columns above only post-validation
    legacy_composite_score NUMERIC(5,2),                    -- v3: preserved for backward compat
    rules_applied       JSONB DEFAULT '[]',                 -- DEFERRED - org_rules snapshot, populated only once Rules Engine (§5.7) ships post-launch
    parent_review_id    UUID REFERENCES reviews(id),        -- v3.6 (§5.5): set when this review is a resubmission addressing a prior remediation_plan
    fix_completion_score NUMERIC(3,2),                       -- v3.6 (§5.5): mean fix_quality_tier (0-3) across parent's action_items, computed on resubmission
    created_at          TIMESTAMPTZ NOT NULL DEFAULT now(),
    completed_at        TIMESTAMPTZ
);
CREATE INDEX idx_reviews_org ON reviews(org_id);
CREATE INDEX idx_reviews_user ON reviews(user_id);
CREATE INDEX idx_reviews_status ON reviews(status);
CREATE INDEX idx_reviews_parent ON reviews(parent_review_id);

-- VERDICTS (v3, unchanged shape, verdict_json now carries dual-score payload)
CREATE TABLE verdicts (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    review_id       UUID NOT NULL REFERENCES reviews(id) UNIQUE,
    verdict_json    JSONB NOT NULL,      -- see Section 2.5 for v3.6 schema
    pdf_url         TEXT,
    public_share_id TEXT UNIQUE,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- DIMENSIONS (v3, extended: score_type tag for dual scoring)
CREATE TABLE dimensions (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    review_id       UUID NOT NULL REFERENCES reviews(id),
    name            TEXT NOT NULL,             -- e.g. "Market Analysis"
    score           NUMERIC(4,2) NOT NULL,     -- 1-10, existing v3 scale
    score_type      TEXT NOT NULL DEFAULT 'proposal',  -- v3.6: 'idea' | 'proposal'
    weight          NUMERIC(4,3) DEFAULT 1.0,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_dimensions_review ON dimensions(review_id);

-- JUDGES (v3, unchanged)
CREATE TABLE judges (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    role            TEXT NOT NULL,             -- Research|Primary|Validation|CrossCheckA|CrossCheckB|...
    vendor_internal TEXT NOT NULL,             -- stripped by sanitization gate before egress
    is_audit_agent  BOOLEAN NOT NULL DEFAULT false, -- v3.6: flags the Phase 6 role
    active          BOOLEAN NOT NULL DEFAULT true,
    accuracy_score  NUMERIC(5,4),
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- JUDGE_SCORES (v3, unchanged)
CREATE TABLE judge_scores (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    review_id       UUID NOT NULL REFERENCES reviews(id),
    judge_id        UUID NOT NULL REFERENCES judges(id),
    dimension_id    UUID REFERENCES dimensions(id),
    raw_score       NUMERIC(4,2) NOT NULL,
    rationale       TEXT,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- RESEARCH_CITATIONS (v3, unchanged)
CREATE TABLE research_citations (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    review_id       UUID NOT NULL REFERENCES reviews(id),
    source_url      TEXT NOT NULL,
    excerpt         TEXT,
    retrieved_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- PREDICTIONS (v3, unchanged)
CREATE TABLE predictions (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    review_id       UUID NOT NULL REFERENCES reviews(id),
    predicted_risk  TEXT NOT NULL,
    check_at        TIMESTAMPTZ NOT NULL,   -- T+90/180/365
    outcome         TEXT,                   -- pending|materialized|avoided
    checked_at      TIMESTAMPTZ
);

-- CORPUS_ENTRIES (v3, extended: org scoping for white-label segmentation, dual score overlay)
CREATE TABLE corpus_entries (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    org_id          UUID REFERENCES org_configs(id),   -- v3.6: NULL = shared/general corpus
    review_id       UUID NOT NULL REFERENCES reviews(id),
    vertical        TEXT,
    idea_score      NUMERIC(5,2),                       -- DEFERRED - VALIDATION GATE, see §2.2; not populated at MVP
    proposal_score  NUMERIC(5,2),                       -- DEFERRED - VALIDATION GATE, see §2.2; not populated at MVP
    dual_score_overlay JSONB,                           -- v3.6 MVP: populated instead of the two columns above, see §2.2
    embedding       VECTOR(1536),
    is_public       BOOLEAN NOT NULL DEFAULT false,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_corpus_org ON corpus_entries(org_id);
CREATE INDEX idx_corpus_embedding ON corpus_entries USING hnsw (embedding vector_cosine_ops);
CREATE INDEX idx_corpus_dual_score_overlay ON corpus_entries USING gin (dual_score_overlay);  -- v3.6 MVP: GIN index serves overlay queries until/unless promoted to typed columns, see §2.2

-- AUDIT_LOG (v3, extended: new event types for v3.6 surfaces)
CREATE TABLE audit_log (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    org_id          UUID REFERENCES org_configs(id),
    actor_id        UUID REFERENCES users(id),
    event_type      TEXT NOT NULL,   -- + v3.6: chat.message, review.url_submit, rule.create,
                                      --   audit_agent.finding, peer_review.submit, org.brand_update
    entity_type     TEXT,
    entity_id       UUID,
    metadata        JSONB DEFAULT '{}',
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_audit_log_entity ON audit_log(entity_type, entity_id);

2.3 New v3.6 Tables

-- CHAT_SESSIONS (Feature 1: Chat-to-Refine)
CREATE TABLE chat_sessions (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL REFERENCES users(id),
    org_id          UUID REFERENCES org_configs(id),
    status          TEXT NOT NULL DEFAULT 'active',  -- active|archived|converted_to_review
    review_id       UUID REFERENCES reviews(id),      -- set once user submits for review
    title           TEXT,
    turn_count      INT NOT NULL DEFAULT 0,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_chat_sessions_user ON chat_sessions(user_id);

-- CHAT_MESSAGES
CREATE TABLE chat_messages (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    session_id      UUID NOT NULL REFERENCES chat_sessions(id),
    role            TEXT NOT NULL,        -- user|coach
    content         TEXT NOT NULL,
    sanitized       BOOLEAN NOT NULL DEFAULT false,  -- gate must run before export
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_chat_messages_session ON chat_messages(session_id, created_at);

-- DIMENSION_EXPLANATIONS (Feature 4: Explain the Low Score)
CREATE TABLE dimension_explanations (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    dimension_id    UUID NOT NULL REFERENCES dimensions(id) UNIQUE,
    explanation_text TEXT NOT NULL,
    cited_gaps      JSONB NOT NULL DEFAULT '[]',  -- ["no TAM calculation", "no competitor pricing"]
    sanitized       BOOLEAN NOT NULL DEFAULT false,
    generated_by    UUID REFERENCES judges(id),    -- always the Primary Reviewer judge
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- REMEDIATION_PLANS (Feature 5: Here's How to Fix It - quality-scored per §5.5)
CREATE TABLE remediation_plans (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    review_id       UUID NOT NULL REFERENCES reviews(id),
    dimension_id    UUID NOT NULL REFERENCES dimensions(id),
    action_items    JSONB NOT NULL DEFAULT '[]',
    -- action_items shape: [{ "description": str, "difficulty": 1-3,
    --   "estimated_time_minutes": int, "template_url": str|null,
    --   "fix_quality_tier": int|null,       -- 0=not_attempted,1=superficial,2=minimal,3=substantive; NULL until resubmission evaluated, see §5.5
    --   "fix_quality_rationale": str|null,  -- evaluator's one-sentence justification, sanitized per §7.2
    --   "evaluated_at": timestamptz|null }]
    tier_scope      TEXT NOT NULL DEFAULT 'full',  -- 'summary' (Free) | 'full' (Pro+)
    disclaimer_version TEXT NOT NULL DEFAULT 'DISC-001',  -- v3.6: legal disclaimer version active at generation time, see §2.6
    sanitized       BOOLEAN NOT NULL DEFAULT false,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_remediation_review ON remediation_plans(review_id);

-- Fix quality aggregate lives on REVIEWS (added to the reviews table above, §2.2):
--   reviews.fix_completion_score NUMERIC(3,2)  -- mean fix_quality_tier (0-3) across all action_items on resubmission, see §5.5
--   reviews.parent_review_id UUID REFERENCES reviews(id)  -- links a resubmission to the review whose remediation plan it's addressing

-- AUDIT_FINDINGS (Feature 6: Second-Opinion Audit Agent) [DEFERRED - Post-Launch, see §1.2/§5.6]
-- Table shape preserved here for continuity; not created by the MVP Phase 0 migration.
CREATE TABLE audit_findings (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    review_id       UUID NOT NULL REFERENCES reviews(id),
    finding_type    TEXT NOT NULL,  -- blind_spot|groupthink|underweighted_dim|tagging_inconsistency|no_finding
    description     TEXT NOT NULL,
    severity        TEXT NOT NULL DEFAULT 'low',  -- low|medium|high
    related_dimension_id UUID REFERENCES dimensions(id),
    disclaimer_version TEXT NOT NULL DEFAULT 'DISC-001',  -- v3.6: see §2.6
    sanitized       BOOLEAN NOT NULL DEFAULT false,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_audit_findings_review ON audit_findings(review_id);

-- RULE_TEMPLATES (Feature 7: Configurable Review Rules Engine) [DEFERRED - Post-Launch, see §1.2/§5.7]
-- Table shape preserved here for continuity; not created by the MVP Phase 0 migration.
CREATE TABLE rule_templates (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name            TEXT NOT NULL,
    category        TEXT NOT NULL,     -- compliance|brand_voice|required_field|checklist
    schema_json     JSONB NOT NULL,    -- JSON Schema describing valid rule params
    is_system       BOOLEAN NOT NULL DEFAULT true,  -- system-provided vs org-authored
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- ORG_RULES [DEFERRED - Post-Launch, see §1.2/§5.7]
CREATE TABLE org_rules (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    org_id          UUID NOT NULL REFERENCES org_configs(id),
    template_id     UUID REFERENCES rule_templates(id),
    name            TEXT NOT NULL,
    rule_definition JSONB NOT NULL,
    -- rule_definition shape: { "condition": {...if/then AST...},
    --   "required_fields": [...], "checklist": [...], "severity": "block|warn" }
    is_active       BOOLEAN NOT NULL DEFAULT true,
    validated_at    TIMESTAMPTZ,       -- set once syntax + schema validation passes
    created_by      UUID REFERENCES users(id),
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_org_rules_org ON org_rules(org_id) WHERE is_active = true;

-- ORG_CONFIGS (Feature 8: White-Label for Consultants)
CREATE TABLE org_configs (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    name            TEXT NOT NULL,
    tier            TEXT NOT NULL DEFAULT 'white_label',  -- enterprise|white_label
    domain          TEXT UNIQUE,             -- custom domain, e.g. reviews.acceleratorx.com
    domain_verified BOOLEAN NOT NULL DEFAULT false,
    domain_verified_at TIMESTAMPTZ,
    logo_url        TEXT,
    brand_colors    JSONB DEFAULT '{}',      -- { "primary": "#...", "accent": "#..." }
    email_template  TEXT,                    -- HTML template with token placeholders
    corpus_segment  TEXT NOT NULL DEFAULT 'shared',  -- 'shared' | 'dedicated'
    api_key_prefix  TEXT UNIQUE,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- ORG_API_KEYS (supports Feature 8's per-org API key scoping)
CREATE TABLE org_api_keys (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    org_id          UUID NOT NULL REFERENCES org_configs(id),
    key_hash        TEXT NOT NULL UNIQUE,
    label           TEXT,
    scopes          JSONB DEFAULT '["review:write","review:read"]',
    revoked_at      TIMESTAMPTZ,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
    last_used_at    TIMESTAMPTZ
);

-- PEER_REVIEWS (Feature 9: Roast/Boost Community Peer Review)
CREATE TABLE peer_reviews (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    review_id       UUID NOT NULL REFERENCES reviews(id),
    user_id         UUID NOT NULL REFERENCES users(id),
    type            TEXT NOT NULL,   -- roast|boost
    comment         TEXT,
    visibility      TEXT NOT NULL DEFAULT 'submitter_only',  -- submitter_only|shared
    flagged         BOOLEAN NOT NULL DEFAULT false,
    flagged_reason  TEXT,
    moderation_status TEXT NOT NULL DEFAULT 'clean',  -- clean|pending_review|removed
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_peer_reviews_review ON peer_reviews(review_id);
CREATE UNIQUE INDEX idx_peer_reviews_dedupe ON peer_reviews(review_id, user_id);

-- PEER_REVIEW_RATE_LIMITS (supports 3/day/user cap)
CREATE TABLE peer_review_rate_limits (
    user_id         UUID PRIMARY KEY REFERENCES users(id),
    review_date     DATE NOT NULL,
    count_today     INT NOT NULL DEFAULT 0,
    UNIQUE (user_id, review_date)
);

2.4 Full Table Inventory (v3 + v3.6)

2.5 Verdict JSON Schema (v3.6)

{
  "review_id": "uuid",
  "status": "done",
  "idea_score": 78.5,
  "proposal_score": 41.0,
  "dual_score_overlay": { "idea_score": 78.5, "proposal_score": 41.0 },
  "framing_summary": "Your idea is strong; your pitch needs work.",
  "disclaimer": "This is an automated critique generated by AI models, not professional advice. Scores and commentary are opinions, not facts. Do not rely on this output for investment, procurement, legal, or funding decisions without independent professional review. See full disclaimer at https://verdicttank.com/legal/disclaimer.",
  "dimensions": [
    {
      "name": "Market Analysis",
      "score": 4,
      "score_type": "idea",
      "explanation": {
        "text": "Market Analysis: 4/10 - no TAM calculation, no competitor pricing data, assumes zero competition.",
        "cited_gaps": ["no TAM calculation", "no competitor pricing data", "zero-competition assumption"],
        "disclaimer": "AI-generated critique, not professional advice."
      },
      "remediation": {
        "tier_scope": "full",
        "disclaimer": "This remediation plan is an automated suggestion, not professional or legal advice. Validate independently before acting.",
        "quality_tier": "not_yet_evaluated",
        "action_items": [
          {
            "description": "Calculate TAM using the top-down/bottom-up hybrid formula",
            "difficulty": 2,
            "estimated_time_minutes": 90,
            "template_url": "https://cdn.verdicttank.com/templates/tam-calc.xlsx"
          },
          {
            "description": "Add a competitor pricing comparison table",
            "difficulty": 1,
            "estimated_time_minutes": 45,
            "template_url": "https://cdn.verdicttank.com/templates/competitor-pricing.xlsx"
          }
        ]
      }
    }
  ],
  "audit": {
    "status": "deferred_post_mvp",
    "findings": [],
    "tagging_consistency_check": "not_run",
    "note": "Second-Opinion Audit Agent (Phase 6) is deferred post-MVP per §1.2. Field shape is preserved for forward compatibility; populated once the Audit Agent worker ships. When populated, audit.disclaimer carries the same 'no professional advice' language as other surfaces."
  },
  "rules_applied": [],
  "corpus_percentile": { "idea_score": 80, "proposal_score": 30 },
  "public_share_id": "vt-8x2k",
  "generated_at": "2026-08-11T00:00:00Z"
}

rules_applied ships as an always-empty array in MVP since the Rules Engine (rules-api) is deferred per §1.2 - the field is preserved in the schema for forward compatibility rather than removed, avoiding a breaking payload change when the Rules Engine ships post-launch.

All freeform text fields (explanation.text, action_items[].description, audit.findings[].description) are sanitized before this object leaves the pipeline - see Section 7.2. All disclaimer fields are not sanitizable/removable content - they are fixed legal boilerplate injected by the response serializer after sanitization, never model-generated, and cannot be stripped by any per-review customization (org branding, White-Label templates, tier). See §2.6 for the full disclaimer policy.

2.6 Legal Disclaimers - "No Professional Advice" (All Output Surfaces)

Origin: Judge 4's Legal Killer #2 (AI Liability / Defamation / Tortious Interference - ranked EXTREME) and Priority Fix #9 of the v3.6 review: "Every verdict, explanation, audit finding, and remediation action item must carry conspicuous language... This is the first line of defense against Rank 2 liability." No disclaimer, limitation-of-liability language, or indemnity existed anywhere in v3.6 prior to this revision - Section 15/Risk Assessment covered only technical/product risk, not the liability exposure of an AI system whose scores can be blamed for a lost deal, declined funding round, or reputational harm.

Standard disclaimer text (canonical copy, referenced by ID DISC-001 so all surfaces stay in sync on future legal-copy revisions):

"This is an automated critique generated by AI models, not professional advice. Scores, explanations, audit findings, and remediation suggestions are AI-generated opinions, not verified facts or expert judgments. Do not rely on this output for investment, procurement, legal, regulatory, or funding decisions without independent professional review. VerdictTank and IT Pro Partner disclaim liability for decisions made in reliance on this output. Full terms: https://verdicttank.com/legal/disclaimer."

Coverage - every output surface carries it, no exceptions:

Non-negotiable design constraints:

• Not sanitizable, not removable. The sanitization gate (§7.2) scans for information leakage; it must never scan or strip the disclaimer field itself. This is enforced by keeping disclaimer injection as a distinct post-sanitization serialization step, not part of the model-generated content that passes through the gate.
• Not White-Label-brand-overridable. Per Judge 4's Legal Killer #3/#5 concerns about White-Label trade-secret and IP exposure, org_configs.email_template/brand_colors theming (§5.8) is explicitly scoped to cannot touch disclaimer copy, placement, or prominence - this is enforced at the template-rendering layer (disclaimer blocks are rendered from a separate, non-themeable partial, injected after the brand template resolves). Applies once White-Label ships post-MVP; documented now so it's not an afterthought when org-api is un-deferred.
• Versioned copy. DISC-001 is versioned; if legal counsel revises the disclaimer text (e.g. after the Minimum Viable Legal review the critical review calls for - MSA + Privacy Program + Content Safety Stack), the version bump is a config change, not a code change, and old stored verdicts retain the disclaimer version active at generation time (verdict_json.disclaimer_version) for auditability.
• This is a mitigation, not a legal opinion. This architecture doc specifies the engineering implementation of conspicuous disclaimers per Priority Fix #9. It does not substitute for the Minimum Viable Legal framework (White-Label MSA, Privacy Program, Content & Safety Stack) the review calls out as a precondition for accepting White-Label customers - that legal work is out of scope for this architecture doc and remains a hard gate on the White-Label track (§1.2) regardless of engineering completeness here.

3. API Reference

3.1 Authentication

• User-facing (web app): JWT bearer token, short-lived access token + refresh token, issued by auth-api (unchanged from v3).
• Programmatic (Enterprise/API tier): API key in Authorization: Bearer vt_live_... header. Keys are scoped per-org (org_api_keys) - v3.6 adds org scoping on top of v3's flat per-user API keys.
• White-Label custom domains: requests arriving on a verified custom domain (org_configs.domain) are resolved to org_id at the edge before hitting any endpoint; all endpoints below implicitly filter/write with that org_id.

3.2 v3 Endpoints (Unchanged Contract, Extended Payload)

POST /api/verdicttank/review

Upload-based review submission (file). Response now includes dual score fields once complete.

// Response (200, once status=done)
{
  "review_id": "uuid",
  "idea_score": 78.5,
  "proposal_score": 41.0,
  "status": "done"
}

GET /api/verdicttank/status/{id} - unchanged polling contract; status enum extended with audit (Phase 6 in progress).

GET /api/verdicttank/verdict/{id}/pdf - unchanged; PDF generator now renders dual-score header and per-dimension explanation/remediation sections.

GET /api/verdicttank/corpus/search - unchanged query contract; results now include idea_score and proposal_score columns instead of a single blended score, and are org_id-scoped for white-label callers.

3.3 New v3.6 Endpoints

POST /api/verdicttank/review/url (Feature 2: URL-to-Review)

// Request
{ "url": "https://example.com/pitch-deck", "vertical_hint": "fintech" }
// Response (202 Accepted)
{ "review_id": "uuid", "status": "queued", "source_type": "url" }

Validation: URL scheme allowlist (http/https), DNS resolution check, max content size 10MB, extraction timeout 30s (hard cap 45s), robots.txt respected, content sanitized before entering the pipeline (see Section 7.2).

POST /api/verdicttank/chat/start (Feature 1)

// Request: { "initial_message": "I'm building a marketplace for..." }
// Response: { "session_id": "uuid", "reply": "Tell me more about who pays on this marketplace." }

POST /api/verdicttank/chat/{session_id}/message

// Request: { "message": "Both sides pay a transaction fee." }
// Response: { "reply": "...", "turn_count": 4 }

Also available as WSS /ws/verdicttank/chat/{session_id} for real-time streaming token-by-token (see Section 5.1). REST polling variant is the fallback for clients that can't hold a socket.

GET /api/verdicttank/chat/{session_id}/history

Returns sanitized transcript (chat_messages where sanitized=true). Export triggers gate scan if not already sanitized.

POST /api/verdicttank/rules (Feature 7, Enterprise/White-Label only)

{ "name": "SOC2 disclosure required", "template_id": "uuid",
  "rule_definition": { "condition": {"if": "vertical == 'fintech'"}, "required_fields": ["compliance.soc2_status"], "severity": "block" } }

Response 201 on pass, 422 with schema violation details on rule-syntax failure.

GET /api/verdicttank/rules / PATCH /api/verdicttank/rules/{id} / DELETE /api/verdicttank/rules/{id} - standard CRUD, org-scoped.

POST /api/verdicttank/org/branding (Feature 8, White-Label)

{ "logo_url": "...", "brand_colors": {"primary": "#0B1B33"}, "email_template": "<html>...</html>" }

POST /api/verdicttank/org/domain - initiates CNAME/TXT verification (see Section 5.6).

POST /api/verdicttank/reviews/{id}/peer-review (Feature 9)

{ "type": "roast", "comment": "Your CAC assumption ignores paid acquisition entirely." }

Rate-limited to 3/user/day (enforced via peer_review_rate_limits, Redis-cached counter). Returns 429 past cap.

POST /api/verdicttank/reviews/{id}/peer-review/{peer_review_id}/report - abuse reporting, pushes into moderation-queue.

GET /api/verdicttank/reviews/{id}/remediation - standalone fetch of the Fix-It plan (also embedded in verdict JSON).

GET /api/verdicttank/reviews/{id}/audit - standalone fetch of audit findings (Enterprise tier).

4. Pipeline Flow

4.1 Updated 6-Stage Pipeline

INTAKE                                                                        EGRESS
  │                                                                              │
  ▼                                                                              │
┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────────┐   │
│ File Upload  │   │ URL Extract  │   │ Chat-to-     │   │  API submission   │   │
│ (existing)   │   │ (Crawl4AI)   │   │ Refine draft │   │  (Enterprise)      │   │
└──────┬───────┘   └──────┬───────┘   └──────┬───────┘   └────────┬───────────┘   │
       └──────────────────┴──────────────────┴────────────────────┘               │
                                     │                                            │
                        normalize to standard intake format                       │
                                     │                                            │
                                     ▼                                            │
                    ┌────────────────────────────────┐                            │
                    │  [Rules Engine pre-check:       │  DEFERRED - Post-Launch   │
                    │   DEFERRED, see §1.2]           │  (see §1.2, §5.7)         │
                    └────────────────┬────────────────┘                            │
                                     │                                            │
    ┌────────────────────────────────▼─────────────────────────────────────┐      │
    │ PHASE 1: Research Agent                                              │      │
    │   Live web verification + citation gathering                         │      │
    └────────────────────────────────┬─────────────────────────────────────┘      │
                                     │                                            │
    ┌────────────────────────────────▼─────────────────────────────────────┐      │
    │ PHASE 2: Primary Reviewer                                             │      │
    │   10-dim brutal critique, 1-10 per dim                                │      │
    │   + score_type tag (idea|proposal) per dim, overlay-only [v3.6, §2.2] │      │
    │   + per-dimension explanation generated inline  [v3.6, Feature 4]     │      │
    │   [org rule dimensions: DEFERRED - see §1.2, §5.7]                    │      │
    └────────────────────────────────┬─────────────────────────────────────┘      │
                                     │                                            │
    ┌────────────────────────────────▼─────────────────────────────────────┐      │
    │ PHASE 3: Validation Reviewer - challenges primary score               │      │
    └────────────────────────────────┬─────────────────────────────────────┘      │
                                     │                                            │
             ┌───────────────────────┴───────────────────────┐                    │
             ▼                                               ▼                    │
    ┌──────────────────┐                          ┌──────────────────┐            │
    │ PHASE 4:          │                          │ PHASE 4:          │            │
    │ Cross-Check A      │  (parallel)              │ Cross-Check B      │            │
    └─────────┬──────────┘                          └─────────┬──────────┘            │
              └───────────────────────┬─────────────────────────┘                    │
                                      ▼                                            │
                    ┌──────────────────────────────────┐                           │
                    │ PHASE 5: Majority Verdict          │                           │
                    │  aggregates scores, builds          │                           │
                    │  idea_score + proposal_score        │                           │
                    │  as dual_score_overlay [v3.6, §2.2]  │                           │
                    └──────────────────┬───────────────────┘                          │
                                      │                                             │
                    ┌──────────────────▼───────────────────┐                          │
                    │ [PHASE 6: Audit Agent - DEFERRED,       │                          │
                    │  Post-Launch, see §1.2 / §5.6]           │                          │
                    └──────────────────┬───────────────────┘                          │
                                      │                                             │
                    ┌──────────────────▼───────────────────┐                          │
                    │ POST-PIPELINE: Fix-It Generator          │                          │
                    │  (Pro+; lightweight summary on Free)     │                          │
                    │  quality-scored, 3-tier rubric [v3.6, §5.5]│                          │
                    └──────────────────┬───────────────────┘                          │
                                      │                                             │
                    ┌──────────────────▼───────────────────┐                          │
                    │ SANITIZATION GATE (extended)              │                          │
                    │  scans verdict JSON, explanations,         │                          │
                    │  remediation text                          │                          │
                    │  (audit findings: N/A, Phase 6 deferred)   │                          │
                    └──────────────────┬───────────────────┘                          │
                                      │                                             │
                    ┌──────────────────▼───────────────────┐                          │
                    │ DISCLAIMER INJECTION (post-sanitization) │──────────────────────┐
                    │  "no professional advice" on every        │                      │
                    │  scored/explained/remediated surface [§2.6]│                      │
                    └──────────────────┬───────────────────┘                      │
                                      │                                          │
                    ┌──────────────────▼───────────────────┐                     │
                    │ PDF Generation + Corpus Write               │──────────────────────┘
                    │  (dual-score overlay, org-segmented)         │
                    └───────────────────────────────────────┘

4.2 Data Flow Notes

• Chat-to-Refine is out-of-band from the pipeline. It produces a refined draft that becomes the input to intake, not a pipeline stage. chat_sessions.review_id links the two for provenance, but the coach model never writes to dimensions, judge_scores, or verdicts.
• URL extraction happens before intake normalization. Extracted HTML/text is sanitized for injection payloads (Section 7.2) and stored in S3 as a snapshot (source_url + snapshot key) for auditability - if the source page changes or disappears, the review remains reproducible.
• Dual scoring is computed at Phase 5, not by a new judge. Each dimension already carries a score_type tag set at Phase 2 generation time; Phase 5 aggregation buckets dimension scores by tag and computes two weighted composites (0-100 scale) instead of one.
• The Audit Agent (Phase 6) sees the full review output - all dimension scores, all judge rationales, the dual-score tagging - as its input context. It does not re-score dimensions; it only files audit_findings rows and validates score_type tagging consistency across judges.
• The Fix-It Generator runs after Phase 6, using both the verdict and any audit findings as ballast (an audit finding that a dimension was underweighted can inform which remediation items are surfaced as higher priority).
• The Rules Engine is not a pipeline phase. Org rules are evaluated in two places: (1) pre-check before Phase 1 to catch hard-block conditions early (e.g. missing a required compliance field halts the review with a 422-style rejection before spending pipeline cost), and (2) injected as additional evaluation dimensions inside the Phase 2 Primary Reviewer prompt so soft/scored rules show up as extra dimensions rows tagged source=org_rule.

5. Component Architecture

5.1 Chat-to-Refine - "Un-Copilot" Coaching (Ghostwriting Guard)

Priority Fix #4 (Judge 3): The v3.6 review found the original prompt-level ghostwriting mitigation ("system prompt says don't ghostwrite, flag suspicious output for manual review") reactive and non-deterministic - a coaching model instructed not to ghostwrite can still ghostwrite a full paragraph, and "flag for manual spot-check" catches it after the user already received it. Judge 3's recommendation: build a deterministic, real-time output-length guard that rejects multi-paragraph output before it reaches the user, and lean into an explicit "un-copilot" brand position - VerdictTank coaches by asking better questions, it does not write your pitch for you, and it says so out loud.

• Service: chat-api (REST, MVP) - see §1.2 for the MVP note that chat-ws streaming is deferred; the guard below is described for the REST turn-response path and applies identically if/when streaming ships.
• Model: a distinct, cheaper coaching model - explicitly not one of the 7 panel judges. No scoring capability is exposed to it; its system prompt is scoped to clarifying questions, gap identification, and structural suggestions only.

Real-time output-length guard (deterministic, not prompt-level):

1. Every coach turn response is validated before it is returned to the user - not sampled, not spot-checked, every single turn. The guard runs synchronously in the chat-api request path immediately after the coaching-model call returns and before the response is persisted to chat_messages or sent to the client.
2. Rejection criteria (any one trips the guard):
3. Response contains more than one paragraph (defined as: more than one block separated by a blank line, or more than ~4 sentences in a single block - sentence-count is the fallback heuristic for models that omit paragraph breaks).
4. Response exceeds 280 characters (SMS-length cap - deliberately short; a real Socratic question does not need three sentences of setup).
5. Response does not contain a ? (i.e., it isn't phrased as a question at all - a purely declarative multi-sentence "here's what your pitch should say" response fails this check even if it's under the length cap).
6. Response contains listable/structured markers characteristic of a drafted document rather than a conversational reply: markdown headers (#), numbered lists with more than 2 items, or bullet lists with more than 2 items.
7. On rejection, the system does not simply retry the same prompt. It re-prompts the coaching model with an explicit corrective instruction appended to the turn: "Your previous response was too long / not a question. Respond with exactly one Socratic question (under 280 characters) that helps the user find the gap themselves. Do not draft content for them." This re-prompt is capped at 2 retries; if the model still fails to produce a compliant response on the 3rd attempt, the system falls back to a pre-written generic Socratic prompt from a static bank (e.g. "What's the one number in here you're least sure of?") rather than ever showing the user a rejected response.
8. Every guard trip is logged (chat_messages.guard_rejected BOOLEAN, chat_messages.guard_rejection_reason TEXT, chat_messages.retry_count INT) for the quarterly manual audit in item 6 below, and to catch coaching-model/prompt regressions early (a spike in guard-trip rate on a model update is itself an alert-worthy signal, not just an audit finding).
9. The guard is enforced server-side only - never trust a client-side check for this; the rejection logic lives in chat-api, not the web frontend, so it can't be bypassed by a different client hitting the same endpoint.

"Un-copilot" brand positioning (Judge 3's recommendation, product + UX + copy, not just engineering):

• Explicit framing everywhere Chat-to-Refine surfaces: the chat UI, the session-start system message, and marketing copy referencing this feature all state the position directly - "VerdictTank is not a copilot. It won't write your pitch. It asks the questions a sharp investor would ask, so you find your own gaps before they do." This is deliberate positioning against the general trend of AI writing tools that draft content for users - the differentiator here is Socratic friction, not fluency.
• UI reinforcement: the chat input area displays a persistent one-line reminder (not a dismissible tooltip) - e.g. "Ask, don't ask-me-to-write" - and the "submit for review" conversion CTA (§5.1 conversion path below) is framed as "ready for the panel to score it" rather than "ready to submit the draft the coach helped you write," to avoid implying co-authorship.
• This positioning is the actual risk mitigation, not just marketing. The review's concern (Legal Killer risk + brand risk) was users perceiving/using VerdictTank as a ghostwriting tool, then either (a) submitting AI-drafted content as their own to investors/reviewers (fraud/misrepresentation exposure) or (b) experiencing a bait-and-switch when the panel then scores their (AI-drafted) pitch harshly, since the panel model is intentionally blind to the fact the applicant used the coach. The guard (deterministic, engineering-enforced) plus the branding (explicit, can't-miss-it positioning) work together - the guard prevents the mechanism, the branding prevents the misunderstanding even in edge cases the guard doesn't catch (e.g. a user pasting coach responses together across many short turns to reconstruct a draft).
• State: chat_sessions + chat_messages. Sessions are resumable - a user can leave and come back; turn_count and updated_at support a "recent sessions" list in the UI.
• Free tier: unlimited use, rate-limited only by abuse heuristics (Redis token bucket, not billed).
• Conversion path: at any point the user can click "submit this for review," which snapshots the latest chat state into the standard intake format and creates a reviews row with chat_session_id set.
• Governance: transcripts are logged in full and subject to periodic (quarterly, minimum) manual audit for ghostwriting drift, now cross-referenced against the guard_rejected/guard_rejection_reason log (item 4 above) rather than relying on manual spot-check alone as the only detection layer. Sanitization gate runs on any transcript before it can be exported via GET /chat/{id}/history. A "no professional advice" disclaimer is shown at session start and persists in the chat UI footer - see §2.6.

5.2 URL Extractor

• Service: url-extractor worker, backed by Crawl4AI (headless-browser-based extraction with readability/structure heuristics).
• Flow: validate URL → fetch with timeout (30s soft / 45s hard) → extract main content + structured sections → strip scripts/styles/nav chrome → run content through the injection-sanitization pass (Section 7.2) → normalize into the same intake schema file uploads use → snapshot raw HTML to S3 for reproducibility.
• Failure modes: paywalled/login-gated pages, JS-rendered SPAs Crawl4AI can't execute fully, robots.txt disallow, DNS failures, oversized pages (>10MB) - all return a structured 422 with a specific reason code rather than a generic failure, since users need to know whether to try again or upload a file instead.
• Rate limiting: per-user extraction quota mirrors review quota (it consumes a review slot only once the extracted content actually enters the pipeline, not on extraction attempt).

5.3 Dual Scorer

• Not a separate model call. Implemented as a tagging + aggregation layer:
• Phase 2 Primary Reviewer prompt requires each dimension output to include score_type: "idea"|"proposal".
• Phases 3-4 (Validation, Cross-Check A/B) inherit and can challenge the tag, not just the score.
• Phase 5 aggregation buckets by tag, computes two independent weighted composites on a 0-100 scale (existing dimensions are 1-10; composite = weighted mean × 10, adjusted by corpus-relative calibration carried over from v3's percentile logic).
• Phase 6 Audit Agent explicitly checks tagging consistency across judges - if Judge A tags "Market Analysis" as idea and Judge B tags it proposal, that's a flagged tagging_inconsistency finding, not a silent average.
• Rubric mapping (from the v3.6 proposal): market size, competitive moat, unit economics → idea; clarity of argument, evidence quality, internal consistency → proposal. The mapping is a configurable lookup table (dimension_score_type_defaults), not hardcoded per-judge, so it can be tuned without a redeploy.

5.4 Explainer

• Not a separate model call. The Primary Reviewer (Phase 2) is required to emit explanation.text and explanation.cited_gaps[] as mandatory fields alongside every dimension score - the API schema rejects a dimension object missing them (fail-closed, not fail-open, per the v3.6 proposal's transparency mandate).
• Storage: dimension_explanations, 1:1 with dimensions.
• Highest-risk sanitization surface (per the proposal's risk table) - freeform text has more surface area to leak internal architecture/vendor detail than a fixed-template report ever had. Gate coverage and the 200-sample manual spot-check (vs. v3's 50) are covered in Section 7.2.

5.5 Fix-It Generator - Quality-Scored Remediation

Priority Fix #7 (Fix-It Quality Loophole): The v3.6 review found the original remediation-tracking design ("re-review score deltas... detect superficial template-filling vs. genuine improvement") was aspirational but not actually specified - there was no evaluation step that distinguished a user who genuinely added a TAM calculation from a user who pasted a single sentence into the relevant section just to make the presence-check pass. Presence-checking ("did the field get filled in") is trivially gameable and undermines the entire retention-loop premise of Fix-It as a credible improvement signal, not a checkbox exercise.

• Service: post-pipeline worker, runs after Phase 5 completes and before the sanitization gate. (Previously described as running "after Phase 6" - corrected here since Phase 6/Audit Agent is deferred per §1.2; Fix-It does not depend on it.)
• Input: verdict + dimension scores + explanations + (if present, post-launch) audit findings.
• Output: remediation_plans rows, one per low-scoring dimension (threshold configurable, default: dimensions scoring ≤5/10 get a plan; Pro+ can request plans on any dimension).
• Tier behavior: Free tier gets a single-paragraph summary (tier_scope='summary', no action_items array, just a rolled-up text field reusing the same table with an empty array + a summary_text companion column); Pro+ gets the full structured action_items[] with difficulty, time estimate, and optional template links.

3-Tier Fix Quality Rubric (evaluation, not presence-checking):

On resubmission (re-review of a previously scored document, or a follow-up chat/URL submission linked via reviews.parent_review_id), each action_item that was addressed is evaluated against the specific gap it named - not merely against whether the target section now contains text. Evaluation runs as an additional judge-model call scoped narrowly to comparing the before/after content for a given action_item, using the original cited_gaps and description as the rubric anchor.

• Storage: action_items.fix_quality_tier INT (0-3, per the table above), action_items.fix_quality_rationale TEXT (the evaluator's one-sentence justification, sanitized like any other freeform field per §7.2), action_items.evaluated_at TIMESTAMPTZ.
• Aggregate signal, not just per-item: reviews.fix_completion_score is computed on resubmission as the mean tier score across all action_items that had a prior plan, giving a single 0-3 "did they actually improve it" number surfaced back to the user and usable as a retention/engagement metric internally - replacing the vague "score deltas" framing from the prior draft with a defined, auditable computation.
• Re-score interaction: the Phase 5 dual-score re-aggregation on resubmission is independent of fix_completion_score - a user can get a higher idea_score/proposal_score on resubmission (because the panel re-evaluated the actual content) and a low fix_completion_score if the improvement, while score-moving, didn't specifically target the gaps the Fix-It plan called out; the two numbers are reported separately so users see both "did your score go up" and "did you fix what we told you to fix."
• Anti-gaming design: action items describe what's missing (data, evidence, structure) and deliberately avoid describing how the panel weighs it - this is a direct mitigation for the "remediation reveals evaluation logic" risk. The quality rubric above is the second line of defense: even a user who reverse-engineers what an action item wants can't satisfy it with a token edit, because the evaluator specifically checks for the depth/rigor the tier table demands, not just topical relevance.
• Legal disclaimer: every remediation plan and its action_items[] carries the remediation.disclaimer field per §2.6 - Fix-It output is a suggestion, not professional or legal advice, and this is stated on every surface where a plan is rendered (API, PDF, web).

5.6 Audit Agent [DEFERRED - Post-Launch, see §1.2]

This component is designed but not built for the 8-week MVP. Per the review's Week 1 Cut List, the Audit Agent addresses "an enterprise trust problem, not a launch problem" - it is retained here in full so the design isn't lost, and is revisited once Enterprise-tier pilot demand justifies the build (see §1.2 Deferred Trigger table).

• Service: dedicated worker role, Phase 6, distinct prompt from all 7 panel judges - it is explicitly told it is auditing a completed review, not producing one.
• Input context: full verdict JSON pre-sanitization, all judge_scores, all dimension score_type tags.
• Output: audit_findings rows (blind_spot, groupthink, underweighted_dim, tagging_inconsistency, or no_finding if nothing surfaces - explicitly logged rather than omitted, because a "never finds anything" audit agent is itself a signal per the proposal).
• Rollout mode: ships in shadow mode first (runs, logs findings, does not gate or delay verdict delivery) for 90 days per the proposal's Phase 3 exit criteria, then goes live for Enterprise-tier billing purposes once a blind-spot catch rate is documented.
• Subject to the same reviewer-accuracy tracking as the primary panel (judges.is_audit_agent=true, judges.accuracy_score computed the same way).

5.7 Rules Engine [DEFERRED - Post-Launch, see §1.2]

This component is designed but not built for the 8-week MVP. Per the review's Week 1 Cut List, the Rules Engine is a White-Label/Enterprise dependency with no MVP demand signal. Retained here as the intended post-launch build.

• Service: rules-api for CRUD, rules-evaluator worker embedded in the pipeline pre-check and Phase 2 prompt injection.
• Rule structure: JSON-encoded if/then conditions, required-field checks, and checklists validated against rule_templates.schema_json (JSON Schema) at save time - malformed rules are rejected with a 422 before they ever reach a live review.
• Two enforcement points:
• Hard block (pre-check): rules marked severity: "block" run before Phase 1 - e.g. a required compliance field missing halts the review immediately, avoiding wasted pipeline spend.
• Soft/scored (Phase 2 injection): rules marked severity: "warn" are appended to the Primary Reviewer prompt as additional evaluation dimensions (dimensions.name prefixed, source='org_rule'), scored 1-10 alongside the standard rubric.
• Safety boundary: rules are strictly additive checks, never prompt replacements - the evaluator sandboxes rule text into a fixed template slot rather than concatenating raw user-authored text into the system prompt, closing the obvious prompt-injection vector an open-ended "no-code rules builder" would otherwise create (see Section 7.3).

5.8 White-Label Engine [DEFERRED - Post-Launch, see §1.2]

This component is designed but not built for the 8-week MVP, and additionally gated on Minimum Viable Legal (MSA + Privacy Program) per the review's Legal Killers before any Enterprise/White-Label customer is onboarded - see §2.6 and §1.2.

• Services: org-api (branding/config CRUD), domain-verifier (background job polling DNS for CNAME/TXT confirmation).
• Multi-tenant isolation: every new v3.6 table and every extended v3 table carries org_id. Row-level security policies in PostgreSQL enforce org_id scoping at the database layer as a second line of defense behind application-layer filtering (belt-and-suspenders against a missed WHERE org_id = ... in a future query).
• Custom domain flow: org admin adds domain_configs.domain → system issues a CNAME target + TXT verification token → domain-verifier polls DNS every 5 minutes for up to 48 hours → on match, domain_verified=true, edge gateway (Caddy) is updated (via API-driven config reload, not manual) to route that domain's TLS + org_id resolution.
• Branding injection: logo_url, brand_colors (CSS custom properties injected at render time), and email_template (Jinja/Handlebars token substitution) are applied at the PDF generator and email-notification layer - no separate white-label codebase, one codebase with per-org theming.
• Corpus segmentation: org_configs.corpus_segment controls whether an org's reviews land in the shared corpus (default) or a dedicated segment invisible to corpus-search queries from other orgs - required for the "no more than 3 accounts until segmentation is independently verified" launch condition.

5.9 Community Layer (Roast/Boost) [DEFERRED - Post-Launch, see §1.2]

This component is designed but not built for the 8-week MVP. Per Judge 4's Legal Killer #4 (defamation/moderation exposure), the moderation overhead and liability surface outweigh launch-stage value - retained here as the intended post-launch build once moderation tooling and Minimum Viable Legal are in place.

• Service: peer-review-api + moderation-queue worker.
• Default state: off. Submitter opts in per-review (reviews gets an implicit visibility flag via a companion review_settings.peer_review_enabled column, or reuse reviews.rules_applied-style JSONB settings blob - recommend a dedicated peer_review_enabled BOOLEAN DEFAULT false column on reviews).
• Visibility: default submitter_only - peer feedback lands in the submitter's own dashboard; nothing is public unless the submitter explicitly re-shares it.
• Rate limiting: Redis counter + peer_review_rate_limits table double-enforce the 3/user/day cap (Redis for fast-path rejection, Postgres for durable audit trail).
• Abuse handling: flagged/flagged_reason/moderation_status columns feed a moderation queue; repeated flags against a user trigger a cooldown (application-layer, not schema-level). Feature-flagged (feature_flags.roast_boost_enabled) per the proposal's Condition 7 - off by default for every tier including migrated beta accounts until one full quarter of opt-in data is reviewed.

6. Infrastructure

6.1 Server Layout

┌────────────────────────────────────────────────────────────────────┐
│  Edge tier (2x app3-class instances, HA pair)                      │
│  Caddy - TLS termination, org-domain routing, rate limiting         │
└────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────────┐
│  App tier (autoscaling pool, 3-6 instances)                         │
│  review-api · chat-api · rules-api · org-api · peer-review-api      │
│  chat-ws (sticky sessions via Redis pub/sub for horizontal scale)   │
└────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────────┐
│  Worker tier (autoscaling pool, scales with queue depth)            │
│  pipeline-workers (Phases 1-6) · url-extractor · fixit-generator     │
│  sanitize-scanner · pdf-generator · domain-verifier · cron           │
└────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────────┐
│  Data tier                                                          │
│  PostgreSQL 16 (primary + read replica) w/ pgvector extension       │
│  Redis 7 (queue + cache + rate limits + feature flags)              │
│  S3-compatible object store (Wasabi/S3) for PDFs, transcripts,        │
│  URL snapshots, uploaded source docs                                 │
└────────────────────────────────────────────────────────────────────┘

6.2 Docker Services

services:
  edge-caddy:            {image: caddy:2, ports: ["443:443"]}
  review-api:            {build: ./services/review-api}
  chat-api:               {build: ./services/chat-api}
  chat-ws:                {build: ./services/chat-ws}
  rules-api:              {build: ./services/rules-api}
  org-api:                {build: ./services/org-api}
  peer-review-api:        {build: ./services/peer-review-api}
  pipeline-worker:        {build: ./workers/pipeline, deploy: {replicas: 4}}
  url-extractor:          {build: ./workers/url-extractor}   # wraps Crawl4AI
  fixit-generator:        {build: ./workers/fixit-generator}
  audit-agent-worker:     {build: ./workers/audit-agent}
  sanitize-scanner:       {build: ./workers/sanitize-scanner}
  pdf-generator:          {build: ./workers/pdf-generator}
  domain-verifier:        {build: ./workers/domain-verifier}
  moderation-worker:      {build: ./workers/moderation}
  cron:                   {build: ./workers/cron}            # T+90/180/365 predictions
  postgres:               {image: pgvector/pgvector:pg16, volumes: ["pgdata:/var/lib/postgresql/data"]}
  redis:                  {image: redis:7-alpine}

6.3 Database Choices

• PostgreSQL 16 + pgvector: single source of truth, chosen over splitting corpus search into a separate vector DB to keep transactional writes (a review completing) and searchable corpus writes atomic. HNSW index on corpus_entries.embedding for approximate nearest-neighbor similarity search.
• Row-level security (RLS): enabled on all org_id-bearing tables as of the v3.6 migration - application connects with a role that has org_id set via SET app.current_org_id per-request, and RLS policies filter automatically. This is the second enforcement layer for white-label tenant isolation described in Section 5.8.
• Redis: queue backend (RQ or Celery, reused from v3), session cache for chat, sliding-window rate limiters (peer-review 3/day, URL extraction quotas), and feature flags (roast_boost_enabled, audit_agent_billing_live, etc.) so risky features can be killed instantly without a deploy.
• S3-compatible object store: PDFs (v3), extended in v3.6 to also hold chat transcript exports and URL-extraction HTML snapshots (for reproducibility if a source page changes after review).

6.4 Caching

• Corpus percentile lookups (idea_score/proposal_score distributions) are recomputed on a 15-minute cadence and cached in Redis rather than computed per-request - avoids a full aggregate scan on every verdict render.
• Org branding config (org_configs row) is cached at the edge layer keyed by resolved domain, invalidated on org.brand_update audit events.
• Rate limit counters (chat abuse heuristics, peer-review daily cap, URL extraction quota) live entirely in Redis with Postgres as the durable audit trail, not the hot path.

6.5 Deployment Options - ITPP-INFRA Shared vs Dedicated

This section addresses the single most common enterprise buyer question: "where does this run?" VerdictTank is not an abstract cloud service - it runs on bare-metal infrastructure owned and operated by IT Pro Partner, with two deployment models to match the client's risk and isolation requirements.

Option A: ITPP-INFRA Shared Deployment (Default)

The solution runs on IT Pro Partner's existing production infrastructure (ITPP-INFRA), the same hardware and backup pipeline that powers ITPP's own operations.

Best for: Pro tier, early Enterprise pilots, non-regulated clients. Cost-efficient - leverages existing capacity with no dedicated hardware overhead. All infrastructure is documented and auditable under ITPP's existing SOC 2-type operational controls.

Option B: Dedicated Deployment

The solution runs on dedicated netcup or Hetzner bare-metal instances provisioned specifically for the client, with a dedicated S3 bucket and isolated backup pipeline.

Best for: Enterprise clients with regulatory requirements (HIPAA, ITAR, FedRAMP-adjacent), White-Label resellers who need full data isolation guarantees, or any client whose compliance framework requires dedicated infrastructure with no shared-tenancy risk. All infrastructure is managed by IT Pro Partner - the client never touches servers - but the hardware, storage, and backup pipeline are theirs alone.

Shared responsibility line: In both models, ITPP manages everything below the application layer (OS, Docker, database, backups, monitoring, patching, incident response). The client's only responsibility is user account management and content submitted to the platform. This is the same operational model ITPP uses for all managed infrastructure - the client gets the benefit of bare-metal performance without any of the operational burden.

7. Security Model

7.1 Authentication & Authorization

• JWT for web sessions (short-lived access + refresh, unchanged from v3).
• Per-org scoped API keys (org_api_keys) for Enterprise/White-Label programmatic access - a compromised key can be scoped to review:read only, or revoked without affecting other keys on the same org.
• Role-based checks: org_admin can manage org_rules, org_configs, and view portfolio-wide corpus; consultant role (White-Label) can manage client portfolios but not billing; member can only see their own reviews unless peer_review.visibility='shared'.

7.2 Sanitization Gate (Extended for v3.6)

The v3 gate blocked deploys unless a pre-deploy scan confirmed no internal vendor/model identity or architecture detail could leak into public reports, PDFs, or API responses. v3.6 quadruples the freeform-text surface area the gate must cover:

• Mechanism: regex/keyword denylist (vendor names, model identifiers, internal prompt fragments) + a lightweight classifier pass for paraphrased leaks, run synchronously before any of the above fields are marked sanitized=true and become eligible for egress. Fail-closed: unsanitized content is never served, regardless of tier or urgency.
• No manual-review fallback for launch day - per proposal Condition 1, this is a hard gate, not a soft warning.
• Elevated manual spot-check: first 200 explanation outputs manually reviewed before Phase 2 GA (vs. 50 API responses under v3), because per-dimension explanation text is identified as the single highest-risk new surface (freeform, generated per-review, harder to template-lock than a fixed report layout).

7.3 Prompt Injection Defense (New Surface: Rules Engine + URL Extraction)

Two new v3.6 features introduce attacker-controlled or third-party text into a model context, which is new relative to v3's fully-controlled prompt pipeline:

• Rules Engine: org-authored rule text is never concatenated raw into a judge's system prompt. Rules are parsed into a constrained JSON AST (condition/field/checklist) validated against rule_templates.schema_json, then rendered into a fixed prompt template slot (e.g. "Additionally verify: {field_name} is present") - the rule author cannot inject arbitrary instructions, only populate whitelisted template variables.
• URL Extraction: third-party page content is inherently untrusted. Before entering the pipeline, extracted text passes through the same sanitization/injection-detection pass used on the egress side (Section 7.2) in reverse - screening for embedded instructions like "ignore previous instructions" or role-play directives that could hijack Phase 1-2 judge prompts. Extracted content is also framed to the model as clearly-delimited untrusted data (matching the same principle applied to this document's own web_extract results), never as system-level instructions.
• Chat-to-Refine: user chat input is similarly untrusted but lower-risk since the coach model has no scoring authority and no access to write pipeline outputs - worst case is a wasted coaching session, not a corrupted verdict.

7.4 Multi-Tenant Isolation (White-Label)

• Application layer: every query touching an org_id-bearing table is required (via a lint rule / query-builder wrapper, not convention alone) to include an org_id filter derived from the authenticated session/API key - never from a client-supplied parameter.
• Database layer: PostgreSQL RLS policies as a second enforcement line (Section 6.3) - even a bug that omits an application-layer filter cannot cross tenant boundaries.
• Corpus segmentation: corpus_entries.org_id + org_configs.corpus_segment='dedicated' keeps White-Label client data out of shared corpus-search results and out of cross-corpus benchmark comparisons unless the org explicitly opts into shared benchmarking.
• Launch gate: no more than 3 White-Label pilot accounts until corpus segmentation and confidentiality controls are independently verified (external audit or pen-test), per proposal Condition 4.

7.5 Abuse & Rate Limiting

• Peer-review: 3/user/day hard cap (Redis + Postgres double-enforced), feature-flagged off by default.
• URL extraction: quota mirrors review allotment; extraction attempts that fail validation don't consume quota, only successful pipeline entries do.
• Chat-to-Refine: unlimited by design (free funnel step) but subject to abuse heuristics (burst detection, not usage caps) to prevent it becoming a free-tier proxy for unrelated LLM usage.

8. Cost Model

8.1 Per-Review Cost Breakdown (v3.6, Pro/Enterprise Tier)

Chat-to-Refine and URL-to-Review add ~$0.02-0.03/session, treated as funnel/acquisition cost (not review COGS) - consistent with the free-tier loss-leader model. Free-tier full reviews remain ~$0.07/review; the lightweight Free-tier fix-it summary adds under $0.01.

8.2 Margin Check by Tier

8.3 Cost Attribution by Component (Engineering View)

9. Implementation Sequence

Mapped to the v3.6 5-phase roadmap from the business proposal.

Phase 0 - Foundation (Weeks 1-3)

• Extend sanitization gate to cover free-text explanation fields, blocking deploys, zero manual fallback.
• Script automated PDF generation end-to-end.
• Design and backfill corpus database schema with idea_score/proposal_score columns built in from day one (no later migration).
• Architecture deliverables: all 21 tables migrated (10 v3 extended + 11 v3.6 new), RLS policies enabled, org_id backfilled as NULL on existing rows.
• Exit criteria: zero manual sanitization steps remain; every historical review queryable in corpus; schema supports dual scoring without further migration.

Phase 1 - Coach & Intake (Weeks 4-6)

• Ship Chat-to-Refine (chat-api, chat-ws, chat_sessions/chat_messages) free-tier-wide.
• Ship URL-to-Review intake (url-extractor worker, POST /review/url) alongside file upload.
• Corpus search live internally.
• Prediction-vs-outcome cron scheduled at T+90/180/365 (v3 carryover, now running against the extended schema).
• Reviewer accuracy scoring begins tracking (read-only, per proposal Condition 2).
• Exit criteria: Chat-to-Refine and URL-to-Review in production with zero sanitization gate failures; first cron cycle completes against real T+90 data.

Phase 2 - Transparency & Depth (Weeks 7-12)

• Dual Scoring ships as the panel's default output contract (dimensions.score_type, Phase 5 aggregation logic).
• "Explain the Low Score" ships alongside it (dimension_explanations, Phase 2 mandatory-field enforcement).
• Vertical auto-classification/templates for top 4 verticals by volume (v3 carryover).
• Adversarial red-team per vertical; market simulation engine (v3 carryover).
• Exit criteria: every review issued after this phase carries two scores + per-dimension explanation; report-framing user test passes (proposal Condition 6) before GA of this phase.

Phase 3 - Fix-It & Trust (Weeks 13-19)

• "Here's How to Fix It" ships on Pro+ (remediation_plans, fixit-generator worker).
• New reviewer panel additions go live (v3 carryover, 4→7 judges).
• Second-Opinion Audit Agent begins shadow-mode auditing of Enterprise-tier reviews (audit_findings, Phase 6 worker, not yet billing-gating).
• Configurable Review Rules Engine opens to Enterprise/White-Label in closed beta (rule_templates, org_rules, pre-check + Phase 2 injection logic).
• Exit criteria: Fix-It plans generated on 100% of Pro+ reviews; Audit Agent completes 90 days shadow-mode with documented blind-spot catch rate before going live for billing.

Phase 4 - Distribution & GA (Weeks 20-25)

• Public-facing shareable review reports ship (v3 carryover).
• Review-as-a-Service API opens in closed beta, then generally to Enterprise (v3 carryover, now org-key-scoped).
• Competitive corpus comparisons on every review (v3 carryover, now dual-score-aware).
• White-Label for Consultants dedicated track launches (org_configs, domain-verifier, portfolio console) - capped at 3 pilot accounts (proposal Condition 4) until segmentation/confidentiality independently verified.
• Roast/Boost ships behind a feature flag, opt-in only (peer_reviews, moderation-queue) - not enabled by default for any tier (proposal Condition 7).
• Reviewer accuracy scoring transitions from read-only to weighting live verdicts (proposal Condition 2 satisfied after one full T+90 cycle).
• Beta pricing sunsets; existing $29/mo accounts enter 6-month grandfathered migration window to Pro.
• Exit criteria: API beta completes 100 reviews with zero sanitization gate failures; first White-Label pilot renews past month one; 100% of beta accounts notified of migration window.

10. Failure Modes

Appendix: Traceability to v3.6 Proposal Sections

End of document.