Shipped: win/loss pair capture at submit time
When a proposal hits submit, PursuitAgent now captures the response, the disposition, and the structured post-mortem inputs into a single record. The first piece of the win/loss intelligence loop is in production.
We shipped win/loss pair capture this week. Quick changelog post — what it does, how to turn it on, and what it sets up for next.
What shipped
When a proposal moves to a terminal status (submitted, then later won, lost, withdrawn, or no-decision), the response now writes a structured record into the win/loss store. The record captures:
- The submitted response, exactly as submitted (PDF or assembled artifact, with hashes).
- The compliance matrix at submission, including which requirements were addressed by which sections.
- The win themes the team committed to in the capture plan.
- The retrieval and drafting logs — which KB blocks the response drew from, which questions hit refusals, where the human overrode the system.
- The disposition (win / loss / withdrawn / no-decision), the announced award details if available, and the debrief notes if the team conducted one.
The record is immutable once written. It is the input artifact for the win/loss intelligence loop — the part of the product that learns from completed bids.
How to turn it on
Capture is on by default for new bids. For existing bids in flight, the proposal manager can enable it from the bid settings (Settings → Capture → Win/loss pair capture). Enabling it on a bid that is already submitted captures whatever signal exists at the time — useful, but with the caveat that the capture-plan and compliance-matrix data was not necessarily structured for capture.
For maximum signal, start the next new bid with capture on from intake.
Why this is the first piece, not the whole thing
The intelligence loop has three parts: capture (this), reflection (the post-mortem analysis that runs against the captured pair), and writeback (the synthesis that updates the KB with what the bid taught us). Capture is the foundation. Without it, reflection and writeback have nothing to work from.
Reflection ships next. The shape: when a disposition flips from “submitted” to “won” or “lost,” a structured set of post-mortem questions runs against the captured pair — what win themes were honored vs. dropped, which sections drove the score (where debrief data exists), which KB blocks proved load-bearing in the response, where retrieval refused on questions that the buyer subsequently flagged.
Writeback is the third piece. The output of reflection — the themes that worked, the blocks that need updating, the gaps that were exposed — gets written back to the KB as candidate updates. Each candidate is reviewable; nothing auto-merges. The human approves what graduates from candidate to canon.
We covered the eight-stage pipeline in early May; the post-mortem stage is the one most teams skip and the one with the highest compounding payoff. Pair capture is the mechanical prerequisite for actually running it.
What this is not
Not yet a competitor benchmark. The captured data is internal to your account; we do not aggregate across customers and we do not produce industry benchmarks from it. (When and if we do, the methodology will be open and customers will be opted in, not opted out.)
Not a replacement for the human debrief. Capture stores what the system saw. The debrief stores what the buyer said. Both go into the record. Neither replaces the other.
Not magic. The pair-capture record is structured data, not insight. The insight is what reflection (next ship) does with it.
Docs
The full capture-record schema and the API for pulling captured pairs lives at /docs/win-loss/capture. A walkthrough of how to read a captured pair is at /docs/win-loss/reading-a-capture.
Reflection ships in August. We will write about it when it does.