Proposal review

Catch the errors inside your proposal before an evaluator does.

Recensa is an independent check that runs after your proposal is written. It reads the finished package and reports what's wrong insideit — numbers that disagree between volumes, cross-references that point nowhere, referenced items that aren't in the package.

Run a free check on a finished document

Your drafting tool shouldn't grade its own homework

Runs after drafting
Reads the finished package
Evidence-bound findings
Word & PDF

Why a separate check

Proposal platforms now draft the narrative, build the compliance matrix, and review the result — all inside one workflow. A review inside the drafting workflow may carry forward the same context, assumptions, and interpretation of the requirements — even when a different model performs the review.

Recensa runs outside that workflow. It doesn't draft, and it doesn't know what you meant. It approaches the submitted package as finished evidence, reading only what is actually on the page.

Shipley's methodology already holds that Red Team reviewers should be independent of the proposal team. Recensa is a tool for the review your process already asks for.

What an independent check finds

It finds the mistakes that survive a read-through because each page looks right on its own: figures that disagree across volumes, references to sections and attachments that don't exist, terms that drift, and totals that don't add up. Each is tied to the evidence behind it.

Numbers that disagree across volumes

The technical volume staffs 14 FTE. The pricing volume prices 12. Each is internally consistent. Together they are a finding.

Cross-references that go nowhere

“As described in Section 4.2” — after the outline was renumbered and 4.2 no longer exists.

Referenced items that aren't in the package

The narrative cites Attachment C. There is no Attachment C.

Defined terms that drift

“The System” in Section 1 becomes “the Platform” in Section 6. An evaluator scoring against Section M has to decide whether those are the same thing.

Arithmetic that doesn't reconcile

Line items that don't sum to the stated total. Recomputed, not estimated.

Rule-based package checks

Filename rules, duplicate files, file types, arithmetic, and configured page limits are validated mechanically — these apply explicit rules rather than asking a model to make a qualitative judgment. Requirements and document references are traced to supporting evidence, and where interpretation is involved, that is clearly identified.

Check	How it works
Duplicate filenames	Rule-based
Filename length and character set	Rule-based, against the rules you specify
File type and unreadable files	Rule-based
Page limits	Rule-based against a configured limit — you tell us what counts
Arithmetic reconciliation	Recomputed
Package manifest	Every attachment the document references, traced against what's in the package. Reference extraction is reviewed, not purely mechanical.
Requirements list	Available through the Recensa pilot — see below

What's in scope

Recensa reviews the package. It does not review eligibility, submission portals, deadlines, win strategy, or whether your argument persuades. Those stay with you — they're outside the document, and outside what a document checker can honestly claim.

What you get

Three things you can keep and share: an Issue Ledger of every finding with its evidence, a Proof Report of which checks ran and when, and an integrity seal that confirms the file hasn't changed since — without claiming the content is correct.

Issue Ledger	Every finding, with the evidence it rests on.
Proof Report	A record of which checks ran, and when.
Integrity seal	Confirms the file has not changed since the check. It does not certify that the content is correct.

Every finding is tied to evidence: the exact passage, calculation, package item, source, or governing rule that produced it. If we cannot show the basis for a finding, we do not report it.

The Requirements Check — available through the Recensa pilot

You give us your requirement list — a compliance matrix, a Section L breakdown, a checklist, however you keep it. We trace each item to a corresponding file, section, or package entry, and tell you what's present and what we can't find.

Presence does not certify that the item substantively satisfies the requirement.

We tell you the item is there, or that we can't find it. Whether it's good enoughis a human call. We run this manually with pilot customers today, because requirement lists arrive in every format imaginable and we'd rather learn what you actually use before building an uploader for something else.

Want it on your next submission? Request a pilot check.

Request a pilot check

Three checks

The three depths differ by what the package is compared against: itself, your own uploaded source material, or outside sources. You can start free with the Internal Check and add depth only when a submission warrants it.

Check	Compares against	Status
Internal Check (Quick)	The document against itself	Free
Source Check (Full)	Plus your own uploaded source material	Available
External Check (Deep)	Plus outside sources, for externally checkable claims	Coming

Run a free check on a finished proposal

Upload the finished package and see what's wrong inside it before an evaluator does. The Internal Check is free.

Run a free check