Procurement glossary: the terms behind a defensible RFP

A sealed bid is a bid submitted in a closed, confidential form — once a sealed envelope, now usually an encrypted or access-locked electronic submission — that no one, the buyer included, may open before the submission deadline. All sealed bids are then opened together at a stated time, so no bidder can adjust its price after seeing a competitor’s.

Sealed bidding is also the name of a formal procurement method, usually run through an invitation for bids (IFB) or invitation to bid (ITB). Bids are opened at the time and place the solicitation states — often in public — and evaluated as submitted, without discussions. The award goes to the responsible bidder whose bid conforms to the solicitation and is best on price; many state and local codes call this the “lowest responsive and responsible bidder”. A bid is responsive when it meets the solicitation’s material requirements, and a bidder is responsible when it is able to perform the contract.

The method suits purchases that can be specified completely and decided on price. When quality, approach or qualifications should count, buyers usually issue an RFP instead — and can still keep the pricing portion sealed until the deadline.

How Pactwise Source handles it

Live today

Each pricing submission is envelope-encrypted with its own data key, wrapped by a key the database never holds. The buyer sees that a bid exists — never its contents — until the reveal.

A scheduled job opens every envelope at once after the deadline plus grace, re-checking the effective deadline at run time so an extension can never trigger an early reveal.

After publish a deadline can only move later, every change is historized with a reason, and every vendor is notified at once. Lateness is frozen at submission time.

Nobody can open a sealed bid early — not the buyer, not an admin, not a database dump — and no vendor can be given a different deadline: there is no per-vendor deadline anywhere in the schema.

See it end to end in the AI RFP Studio.

A blind evaluation is a way of scoring proposals in which evaluators are deliberately kept from information that could bias their judgment. Depending on the process, that means scoring without knowing which vendor wrote a proposal, scoring the technical response before the price is known, or scoring independently without seeing other evaluators’ scores.

Each variant targets a different bias. Masking vendor identities — an administrator redacts names and assigns neutral codes before evaluators see the proposals — guards against favoring a familiar brand or the incumbent, though proposals often carry clues, so complete anonymity is hard to guarantee. Scoring the technical response before opening the price keeps a low number from coloring the quality scores. Independent scoring keeps one evaluator’s first number from anchoring everyone else’s.

Whatever form it takes, a blind evaluation is usually paired with conflict-of-interest declarations and a consensus or calibration step after the individual scores are in.

How Pactwise Source handles it

Live today

In Pactwise Source, “blind” means independent scoring. Evaluators attest no conflict of interest before scoring, see only their own scores until lock, and outliers are flagged at lock time. The database rejects any score from an evaluator who has not attested.

AI never scores, ranks, or recommends an award.

That is a structural rule, not a setting: scores are human acts, made under conflict-of-interest and variance controls.

See it end to end in the AI RFP Studio.

An RFI (request for information) gathers information about the market and possible solutions before a buyer has settled its requirements, and is not normally a basis for award. An RFQ (request for quotation) asks for prices on a clearly specified good or service where cost decides, while an RFP (request for proposal) asks for a full proposal — approach, qualifications and price — that is evaluated against criteria beyond price.

• RFI — request for information. Early and exploratory: learn what the market offers, refine requirements, and find out who might bid. Responses inform the later solicitation.
• RFQ — request for quotation. The specification is fixed and price is the main deciding factor, as for standard goods or well-defined services.
• RFP — request for proposal. The buyer describes the need and asks vendors how they would meet it. Proposals are scored against published, weighted evaluation criteria — typically technical approach, qualifications and price.

Usage varies by organization and sector. Some public bodies use “RFQ” for a request for qualifications, which shortlists firms on experience before any pricing, and many teams say “RFP” loosely for all three. Check the solicitation itself to see which process it runs.

How Pactwise Source handles it

Buyer console · Live today

Pactwise Source is built for the competitive RFP: a requirements matrix, weighted evaluation criteria and a pricing schedule, with pricing sealed until the deadline. Its buyer console provides RFP authoring, invitations, documents and addenda, Q&A, roll-call, evaluation, award, completion and audit screens for the buying team.

Prep Studio, “Draft with AI” in the buyer console, drafts that package with you. It is marked Prep Studio · In progress: AI-assisted intake that drafts the scope, requirements matrix, weighted criteria and pricing schedule, reads its own draft as a hostile bidder would, and hands every artifact to you for approval. Built and verified against recorded model runs; live-model drafting switches on with the model key.

See it end to end in the AI RFP Studio.

A bid protest is a formal challenge, by a bidder or prospective bidder, to the terms of a solicitation or to the award or proposed award of a contract. It asks the buying organization or an outside reviewer to find that the procurement broke the rules it had to follow and to correct it — for example by re-evaluating, re-competing or cancelling the award.

Protests commonly allege that proposals were evaluated against criteria other than the published ones, that bidders received different information, that an evaluator had a conflict of interest, or that the award decision was not documented. A protest that challenges the solicitation itself is usually due before bids or proposals are; a challenge to an award comes after it is announced.

The process depends on the jurisdiction. In US federal procurement, a protest may be filed with the procuring agency, the Government Accountability Office (GAO) or the US Court of Federal Claims; at GAO only an interested party — generally an actual or prospective bidder — may protest, and GAO must decide within 100 days. State agencies, cities, school districts and special districts set their own protest procedures and deadlines, usually in their procurement code and in the solicitation.

Whatever the forum, a protest is answered from the record: what was published, what every bidder was told, how the proposals were scored and who approved the award.

How Pactwise Source handles it

Live today

Pactwise Source supports your process for answering a protest. One export compiles the timeline, addenda and acknowledgments, published Q&A, submission metadata, locked scores, attestations and approvals into a single hashed document.

The rules that keep a record defensible are enforced while the RFP runs. Vendors ask privately; answers publish to everyone, anonymized. Post-publish changes go out only as versioned addenda every vendor must acknowledge, and an addendum inside the notice window forces a deadline extension or a written override.

An award needs a locked evaluation, a written justification, every vendor question answered, every abnormal-bid flag acknowledged, and an approver who is not the author.

See it end to end in the AI RFP Studio.

An evaluation rubric is the scoring guide evaluators use to rate proposals: the evaluation criteria, the weight of each, the scoring scale, and a description of what earns each score. It is fixed before any proposal is opened, so every proposal is judged on the same stated basis.

Weights are commonly expressed as percentages or points that add up to 100, so each criterion’s share of the total is plain. The scoring scale — 0 to 5, say — gets a short description for each level, so that a “4” means the same thing to every evaluator. Each score should come with a written comment that ties it to the proposal.

Public buyers usually state their criteria and their relative importance in the solicitation; in US federal procurement, the Federal Acquisition Regulation requires every factor and significant subfactor that will affect the award, and their relative importance, to be stated clearly in the solicitation. Changing the criteria after proposals arrive is a common ground for protest.

How Pactwise Source handles it

Live today

In Pactwise Source the rubric is checked by code before the RFP can publish: criteria weights must sum to exactly 100, every scored criterion must map to a requirement, and the requirements matrix cannot be empty. After publish the criteria cannot be edited; changes go out only as versioned addenda that every vendor must acknowledge.

Scoring stays human. Evaluators attest no conflict of interest before scoring, see only their own scores until lock, and outliers are flagged at lock time. Prep Studio can propose criteria and weights for you to approve (Prep Studio · In progress). AI never scores, ranks, or recommends an award.

See it end to end in the AI RFP Studio.

A publish gate is a set of pass/fail checks a solicitation must clear before it can be released to vendors; if any check fails, it stays in draft. “Publish gate” is Pactwise’s own term — many teams do the same job with a pre-release review or checklist — and in Pactwise Source the gate is enforced by the database.

A gate exists because some defects cannot be fixed fairly once vendors have the package: criteria that don’t add up, a response window too short to answer well, or a question period that closes too close to the deadline. Caught before release, each is a quick edit; caught after, it means an addendum, a deadline extension, or a protest.

How Pactwise Source handles it

Live today

Publishing is a database check, not a checklist: contact details, Q&A cutoff spacing, minimum response window, criteria weights that sum to 100 and a pricing schedule are all enforced before an RFP can go out, and it warns when fewer than three vendors are lined up to invite.

The gate reports each unmet item, so the buyer knows exactly what to fix, and a short response window can be overridden only with a documented reason that is written to the audit log.

See it end to end in the AI RFP Studio.

A procurement audit trail is the chronological record of every action taken in a purchase — who did what, when, and to which document — from the first draft of the solicitation to the award. It lets an auditor, oversight body or protest reviewer reconstruct how a decision was reached, and it can be trusted only if its entries cannot be quietly edited or deleted afterward.

A complete trail covers the solicitation and every addendum, vendor questions and the published answers, invitations and acknowledgments, each submission with its time of receipt, the bid opening, evaluator attestations and scores, and the approvals behind the award. It also records reads — who opened which document, and when — not just changes.

A trail that an administrator can edit proves little. Stronger designs make the log append-only and chain each entry to the one before it with a cryptographic hash, so a missing or altered entry is detectable.

How Pactwise Source handles it

Live today

One write path into the audit log, no updates, no deletes, each event hash-chained to the one before.

No one — vendor or buyer — reads a file directly. Every read is logged and served through a signed link that expires in 60 seconds.

Uploads are stamped with the server clock and a server-computed checksum, scanned, then frozen. Late uploads are accepted only with a written reason and flagged as late.

When an award is questioned, there is one place to look. One export compiles the timeline, addenda and acknowledgments, published Q&A, submission metadata, locked scores, attestations and approvals into a single hashed document.

See it end to end in the AI RFP Studio.

• See how these pieces fit together in the AI RFP Studio.
• Read how Source fits public-sector procurement and K-12 school districts.
• Compare an RFP run by email and spreadsheet with one run in Pactwise Source.
• Compare the plans on the pricing page.