RFP/DDQ OS

RFP/DDQ OS helps complete RFPs and DDQs without losing control of the answer process.

You give it an incoming file. It pulls out the questions, looks for approved answers, shows what needs review, and produces final output only after the required approvals are done.

It is built for human review, not automatic submission.

Evidence mapping

For DDQs and RFPs, evidence mapping is the system that keeps AI from turning a messy source base into confident, unsupported answers.

An RFP response can look complete long before it is defensible. The answer may sound polished, but cite the wrong policy. It may reuse an old answer that predates a process change. It may blend a roadmap item with a live capability. It may answer "yes" because a similar answer existed in the library, not because the current evidence supports it.

Evidence mapping does four things:

1. Builds the source packet: policies, SOC reports, security docs, product docs, contracts, prior answers, exceptions, and SME notes, each with owner, date, status, and permitted use.
2. Separates answer types: approved facts, conditional answers, assumptions, roadmap items, expired claims, and questions requiring SME review.
3. Maps every response to evidence: each answer carries source IDs, source dates, confidence level, reviewer, and answer-library reuse status.
4. Blocks unsafe completion: unsupported claims, stale evidence, contradictory sources, low-confidence answers, and regulated topics route to review before final export.

For DDQs, evidence mapping protects factual accuracy. For RFPs, it protects the commercial narrative.

The goal is not just a completed questionnaire. It is a response you can defend after it leaves the room. Every answer should know where it came from, who approved it, when it was last validated, and whether it is safe to reuse.

Evidence mapping needs a structured record of questions, answers, sources, claims, review status, and reuse rules. Postgres is one good way to store that, but it is not required at every stage.

Postgres matters when the workflow needs many DDQs and RFPs over time, a reusable approved answer library, source and version history, reviewer workflow, audit trails, confidence scoring, search across past answers, and enforcement that final exports only use approved evidence.

For this project, Postgres makes sense because the product is not just generating one response. It is building a governed answer system. The database becomes the control plane: what sources exist, which answers are approved, which evidence supports them, what changed, and what needs review.

How it works

1. Put the RFP or DDQ file in input/.
2. Run /ingest <firm-or-file> or /ingest and answer the prompt.
3. The system creates a readable run folder under deliverables/rfp-ddq/.
4. Open the dashboard to see what is ready, blocked, or waiting for review.
5. Use /rfp-review and /resolve-gaps to make decisions in chat.
6. Use /approve-export before writing the final output.
7. Use /learn if approved answers should be added back to the answer bank.

The normal flow is:

input file -> /ingest -> /rfp-review -> /resolve-gaps -> /approve-export -> /export -> /learn

If you get lost, run /next.

Note: use /rfp-review for RFP/DDQ review. /review is reserved by Codex for code review.

Why it is reliable

• It uses a Postgres answer bank instead of loose files or chat memory.
• Every drafted answer is tied to source IDs, source dates, evidence, confidence, and review status.
• Questions that lack support are marked blocked instead of guessed.
• High-risk answers go to review before export.
• Final exports require an explicit approval step.
• Generated Markdown is only a receipt. The database is the real workflow record.

Where to look

• input/: incoming RFP and DDQ files.
• deliverables/rfp-ddq/: generated run folders.
• .system/: implementation, tests, scripts, and product docs.

Run folders use the firm slug, for example northstar.

Inside each run folder:

• 01_system-audit-trail/: evidence map, source trail, and trust status.
• 02_operator-summary/: run dashboard and next action.
• 03_review-work-queue/: SME review packets.
• 04_export/: final output after approval.

Chat commands

• /status: show active runs and next actions.
• /ingest: start a run from a file in input/.
• /next: show the next safe command.
• /rfp-review: approve, edit, reject, or skip pending review items.
• /resolve-gaps: handle blocked questions without enough evidence.
• /approve-export: run the final safety check.
• /export: write the final approved output.
• /learn: propose answer-bank updates from approved answers.
• /dashboard: show or refresh the run summary.
• /evidence: show or refresh the evidence map.

Commands that operate on one run accept a firm slug, short ID, or run ID, for example /rfp-review northstar. /status lists all active runs when no target is provided.

Local setup

If you need to run the repo locally, use SETUP.md.

Safety rules

• Do not send completed RFPs or DDQs externally from this repo.
• Do not bypass review or export approvals.
• Do not write to production databases.
• Do not import legacy sales-os data unless explicitly requested.

More detail

• Product direction: .system/docs/prd.md
• MCP tools: .system/docs/mcp.md
• Architecture: .system/docs/architecture.md
• Local Postgres: .system/docs/local-postgres.md
• Trust rules: .system/docs/trust-layer.md