The compliance matrix

What a compliance matrix is

A compliance matrix is a row-per-requirement inventory of everything a solicitation obliges you to do, keyed to the issuer's own numbering, tracking for each one where in your response it is satisfied, who owns it, what state it is in, and what evidence proves it.

It is sometimes called a requirements traceability matrix, a cross-reference matrix, or — when the issuer demands one as a deliverable — a compliance cross-reference table. The names differ; the job does not. It converts an unbounded reading task ("have we covered everything?") into a bounded counting task ("are all one hundred and forty rows closed?").

It is not a checklist of good practice, and it is not the proposal outline dressed up. Every row traces to a specific sentence in a specific document the issuer published. If you cannot point at the source, it does not belong in the matrix — put it in your internal quality list instead.

Why it exists

A solicitation is not a coherent document written by one person. It is assembled from a scope of work, an instructions section, a general-terms section that has been recycled for a decade, a set of attachments produced by different departments, a sample contract drafted by legal, and a stack of addenda published after the fact. The obligations are scattered across all of them, and several will contradict each other.

Reading that carefully once is not a control. Four things defeat it:

• Requirements hide outside the requirements section. The instructions section carries the format gates. The sample contract carries the insurance limits. The pricing workbook carries a submission rule. A matrix built from the scope of work alone will miss most of what disqualifies people.
• The document changes under you. Addenda add, delete and amend requirements after everyone has already read the original and formed a mental model of it. Mental models do not receive addenda.
• Work is distributed. The moment more than one person is writing, "we covered that" becomes an assumption held by two people about each other.
• Coverage cannot be perceived. A response that answers ninety-eight of a hundred requirements reads exactly as complete as one that answers a hundred. Nothing in the finished document signals the two that are missing. Only an external inventory can.

The matrix also does something quieter and just as valuable: it is the outline. Built before drafting, it tells every writer precisely what they are answering, in the issuer's own words, and where the answer goes. That is why it belongs at the start of the response sequence rather than at the quality-control end of it.

The columns, one by one

1. Requirement ID, as the issuer numbered it

Use the issuer's scheme verbatim: §IV.B.3, Attachment 7, Form 4, Addendum 2, Q14. Never renumber into a tidier scheme of your own. The entire value of this column is that a reviewer holding the solicitation can land on the exact sentence in seconds, and a private numbering system destroys that in exchange for nothing.

Where the issuer did not number something — and unnumbered obligations buried in prose are common — derive an identifier that still points back, like p.14 ¶3. Keep it stable, because you will cite it in review comments for weeks.

2. The requirement text, verbatim

Quote it. Do not paraphrase. Paraphrase is precisely where requirements quietly lose their teeth: "shall provide three references from comparable municipal accounts held within the last five years" becomes "references" in someone's summary, and three weeks later the response contains two references from private clients.

If the sentence is long, truncate with an ellipsis — but keep the operative verb and every qualifier. The words that matter are shall, must, may, three, continuous, within, prior to, and every number.

3. Type — hard gate or scored, and the weight

Classify each row as a pass/fail gate or a scored criterion, and for scored rows record the points available. This one column changes how you spend the remaining time: gates are binary and must be closed absolutely, while scored rows deserve effort in proportion to their weight. A thirty-point criterion and a five-point criterion should not receive equal attention, and without this column they usually do.

4. Where it is satisfied

A specific location in your response: volume, section, and page. "Technical Volume, §3.2, p.11." Not "yes". Not "covered". Not a person's name.

This column has two jobs. During drafting it prevents two writers answering the same requirement in two places while a third goes unanswered. At the end it is what you use to check the rendered file — you open page 11 and confirm the answer is on it. "Covered" cannot be checked, which is another way of saying it cannot be wrong, which is another way of saying it is worthless.

5. Owner

One named human. Not a department, not a job title, not two names. A requirement owned by a team is owned by nobody, and the discovery happens on the last afternoon.

6. Status

Use a small fixed vocabulary and refuse to extend it — for example: Not started, Drafted, In review, Verified, At risk, Not satisfied. Fixed vocabulary matters because free-text status is where things go to die: "in progress", "mostly done", "waiting on Dave" and "should be fine" are all indistinguishable from each other and from nothing.

Verified is a privileged state. It means someone other than the author opened the evidence and confirmed it. Nothing reaches Verified on an author's own say-so.

7. Evidence

What proves the row is closed: the executed form, the certificate number, the attachment filename, the page of the rendered PDF, the licence number, the signed reference sheet. On the final pass you verify against this column rather than against anyone's recollection of having done the work, and the difference between those two things is most of the value of the exercise.

Two columns worth adding

Source document — base solicitation, Attachment C, or Addendum 2. When a later addendum amends a requirement you need to see at a glance which version you are holding. Its own deadline — some gates have dates earlier than the submission date: a mandatory pre-bid meeting, an intent-to-bid notice, a site visit, a certification application. Those rows are due before the response is.

Telling a hard gate from a scored criterion

The classification decides how you spend the rest of your time, so it is worth doing carefully rather than by feel. Three signals, in order of reliability:

• The consequence is stated. Language like "may be deemed non-responsive", "shall be rejected", "will not be evaluated" or "is a condition of award" names the consequence outright. That is a gate, and the sentence containing it belongs in your matrix word for word.
• The verb. Shall, must and will are obligations. Should, may, preferred and desirable are usually scored or optional. The verb is a strong signal but not a conclusive one, because solicitations are not drafted with that discipline consistently.
• Where it sits. Requirements in the instructions and submittal-requirements sections skew heavily toward gates. Requirements in the scope-of-work and evaluation sections skew toward scored. This is the weakest of the three signals and should never be used alone.

When the classification is genuinely ambiguous, treat it as a gate. The cost of over-closing a scored row is a few hours; the cost of under-closing a gate is the whole submission. And if the ambiguity is material, that is exactly the sort of thing to raise during the question window, while an answer can still be published to everyone as an addendum.

A requirement that disappears looks exactly like one that was satisfied

This is the only thing on this page that is genuinely dangerous, and it is a property of the instrument rather than of the people using it.

When a row is deleted — because someone decided it did not apply, or a filter hid it, or a tab got tidied, or a merge dropped it — the matrix does not show a gap. It shows a slightly shorter list where every visible row is green. That state is indistinguishable from the state where the requirement was satisfied. Both look like a clean sheet. The absence of a warning is not evidence that there is nothing to warn about.

Which produces the rules that make a matrix trustworthy rather than merely present:

• Never delete a row. If a requirement is genuinely withdrawn, mark it Waived by Addendum 3 and cite the addendum in the evidence column. Withdrawal is a status, not a deletion. A deleted row cannot be audited, and it cannot be restored when the next addendum reinstates it.
• Make Not satisfied the loudest state on the page. Sort or filter so unsatisfied and at-risk rows float to the top. The natural tendency of any long sheet is for unfinished work to sink below the fold, which is the failure mode dressed as housekeeping.
• Count, then reconcile. The final pass is arithmetic: total rows, verified rows, unsatisfied rows. If verified plus unsatisfied does not equal total, something has gone missing and you find it before submitting. A number that must add up is a control; a feeling that everything looks fine is not.
• Separate the author from the verifier. A writer closing their own rows is checking their memory of having done something. A second person closing them is checking the artefact. Only the second one is verification.
• Close against the rendered file. Not the draft, not the shared document, not the version in the folder — the exact file that will be uploaded. Page numbers, counts and file structure all change during assembly.

The same reasoning drives how we enforce format gates in production: a page cap that only prints a warning is a page cap someone will scroll past at 11pm. Ours exits non-zero and fails the build, which is described in the method.

Keeping it alive through the addenda

The matrix is not built once. Every addendum is a change order against it, and an addendum published four days before the due date is the one most likely to be skimmed.

Process it deliberately, every time:

1. Read the addendum in full, against the matrix rather than against your memory of the base document.
2. Add a row for each new requirement, sourced to that addendum.
3. For each amended requirement, mark the original row superseded, cite the addendum, and open a new row with the new language. Do not edit the original in place — you will lose the ability to tell whether the change was actually absorbed.
4. Add a row for acknowledging the addendum itself, because that is nearly always its own gate on its own form.
5. Re-check any date the addendum touched, including the due date.
6. Re-open any row whose evidence the change invalidates. A page-cap change invalidates a verified page count.

Published answers to other responders' questions carry the same weight. An answer that says "the successful proposer will be required to…" has created a requirement, and it binds you whether or not you were the one who asked.

Version the matrix by date so that a reviewer can tell which addendum it reflects. A matrix whose age you cannot determine is a matrix you cannot rely on, because the one thing you need to know about it is whether it is newer than the last addendum.

Closing the matrix

The matrix is not finished when the proposal is finished. It is finished when every row carries evidence that someone other than its author has checked against the exact files being submitted, and the counts reconcile.

The closing pass, in order:

1. Render the final files. Everything after this point runs against those files only.
2. Walk the gate rows first. Every one must reach Verified — there is no partial credit available, so there is no reason to look at scored rows while a gate is open.
3. Walk the scored rows, confirming the location column actually lands on the answer.
4. Reconcile the counts. Total, verified, unsatisfied.
5. Read the unsatisfied list out loud to the person who signs. If any of it is a gate, you do not submit yet — you fix it, or you make an informed decision to submit knowing what is missing. An informed decision is survivable; an accidental one is not.

That last step is the point of the whole instrument. It does not make compliance certain — no process can do that. It makes sure nobody first learns what was missing by reading a rejection letter.

For what happens when a gate does stay open, see the taxonomy of why bids are rejected — every entry in it corresponds to a matrix row somebody left unclosed. For where the matrix sits in the wider process, see how to respond to an RFP.