How a response actually gets produced.

The issuer's own document.
Never a summary of it.

Work begins with the solicitation exactly as published: the full package, every exhibit, and every addendum issued up to the closing date.

Procurement portals summarise. They show a scope blurb, a due date and a category code, and that summary is generated from metadata rather than from the document. The requirements that remove bidders — the format specification, the affidavit that has to be notarised, the sentence in an appendix stating what is excluded from the page count — never appear in it.

Exhibits are frequently published as scanned images: a form someone printed, signed, scanned and re-attached years ago, with no selectable text in it at all. Those are read as images and transcribed rather than skipped, because they are usually the forms with the signature blocks. A requirement that only exists inside a picture is still a requirement.

Addenda are tracked as a live set, not collected once at the start. An addendum can move the due date, change a page limit, add a form, revise the scope, or answer another bidder's question in a way that changes your price — and it almost always carries an acknowledgement obligation of its own.

Every requirement,
and where it is answered.

The matrix is the spine of the engagement. Each requirement in the solicitation gets a row: its identifier, the text as written, the volume and page where it is satisfied, and whether it is a hard gate or a scored criterion.

The classification is the part that changes behaviour. A hard gate is pass or fail with no points attached and nothing elsewhere in the response that can compensate. A scored criterion is where the competition actually happens. Treating those two categories with the same urgency is how strong bidders spend their last day polishing a narrative while an unsigned form sits in the package.

The matrix is written first and it is a deliverable, not an internal artifact. You get it, which means you can audit the reading rather than take our word for the result. If a requirement is not in the matrix, we did not see it — and that is a claim you are able to check.

No claim without a basis.

A proposal is a set of assertions someone will later hold you to. Every one of them has to trace back to something you actually gave us.

Three rules carry this, and they are enforced rather than encouraged.

Unearned past tense is caught automatically. The most dangerous sentence in proposal writing is the one that reads well and quietly converts an intention into a history: "we implemented", "we delivered", "we have operated". A check runs against every draft looking specifically for that shape, and the writing has to earn the tense or lose it. It is not a style preference. In a public submission, an overstated past performance claim is a misrepresentation with a protest attached.

Every figure carries a source. Numbers in the response come from your documents, the issuer's documents, or a stated calculation. A figure nobody can trace is treated as an open item, not as a detail to be tidied up later.

Unsatisfied stays visible. An open requirement remains flagged in the matrix until it is closed. Nothing is quietly downgraded to satisfied because the deadline is near — the failure mode we design against is a requirement that disappears rather than one that gets refused.

One source.
Two renderings.
A cap that fails the build.

The response lives in one source per volume and is rendered from there into the formats the issuer asked for — PDF for submission, DOCX where an editable file is required.

Single-source matters because the alternative is the standard proposal disaster: a Word file, a PDF exported from it three hours earlier, and a printed copy from the day before, all slightly different, with nobody certain which one went in the envelope. When there is one source, the rendered files cannot disagree with each other.

The page cap is enforced by the build rather than by a person. The count is taken on the rendered PDF — not on the draft, not on a word count, not on an estimate — and a breach exits non-zero and stops the build. There is no output to submit until it is resolved.

The distinction between failing and warning is the entire design decision. A warning is a line of text somebody reads at 11pm on the night before a deadline and decides to deal with in the morning. It is the same reasoning that puts a hard stop on a machine instead of a sticker.

The positive-control principle

Here is the part almost nobody does, and it is the reason the eight checks above are worth anything at all.

A check that never fires and a check that was never wired up look identical from the outside. Both produce silence. Both let the build pass. If a page-cap check has a broken path, a typo in a variable name, or reads the draft instead of the rendered file, it will report clean on a 40-page document against a 30-page cap and nothing about that output will look wrong.

So each check is itself tested against an input constructed to trip it. A file that is deliberately over the cap. A document with a placeholder deliberately left in. A paragraph with a deliberately unearned past-tense claim. If the check does not fail on those, the check is broken — and we have learned something about the checker, not about the document.

A clean pass from an unproven check is not evidence of anything. It is the absence of evidence wearing the same clothes.

A PDF that builds
is not a PDF that reads.

Every rendered page is opened and read by a person, at the size an evaluator will see it, in the order an evaluator will meet it.

Automated checks confirm facts about a document. They do not have an opinion about it. Nothing in the eight checks above will tell you that a table technically fits but is unreadable, that a heading landed alone at the bottom of a page, that a chart's axis label is too small at print size, or that the section an evaluator scores twenty-five points on opens on the back of a page nobody turns to.

The visual pass also catches the ordering problem. A response can satisfy every requirement and still make the evaluator hunt for the answers. Where the solicitation names its sections, the response follows that order — so the person scoring it with a worksheet in front of them finds each item where their worksheet says it should be.

Nothing is delivered
on an automated pass alone.

A human reviews the complete package before it reaches you. That is a fixed rule, not a capacity-dependent one, and it does not get skipped when the deadline is tight.

You receive the rendered submission files, the forms package assembled in the order the solicitation specifies, and the compliance matrix showing where every requirement is satisfied and what — if anything — is still open. If something is still open, it is named in the handover rather than left for you to discover.

You file the submission. That is deliberate: the bidder is the legal entity making representations to the issuer, signing the certifications, and bearing the consequences of them. The last read of a document that binds your company belongs to your company.