What the specifications of a tender are: PCAP and PPT explained without the jargon

What the specifications of a tender are

The specifications are the documents that govern a public tender. They are drawn up by the contracting body, the organisation putting the contract out to tender, and they set out what is being bought, who may bid, what documentation has to be supplied, what technical requirements apply, how the offers will be assessed and what terms the contract will carry. They are the rules of the game. Everything your company submits will be read against them, so no offer starts anywhere else.

In practice it is not a single document. A tender is usually published with two main specifications, the PCAP and the PPT, plus a set of annexes: declaration templates, forms and the mandatory documents that have to be attached. They appear alongside the tender notice on whichever procurement platform the body uses; in Spain the reference platform is the Public Sector Procurement Platform (PLACSP). The exact structure varies from one tender to the next, and a requirement can sit in any of the pieces.

What the PCAP is

The PCAP is the Pliego de Cláusulas Administrativas Particulares, the administrative specifications. It holds the administrative and financial rules of the procedure: who may take part and what solvency they have to evidence, what documentation to submit and in what format, how the offers are scored, what guarantees are required, what the deadlines are and what terms the contract will carry once awarded. It is the document that says how the competition works. When a company is knocked out of a tender on a formal ground, the reason was almost always written in the PCAP.

• Who may bid: the economic and technical solvency required, and any classifications or accreditations you need to hold.
• What administrative documentation to submit: responsible declarations, the ESPD (DEUC in Spain) or other forms, powers of representation and the mandatory annexes.
• The award criteria and how the points are shared out between them, including the price formulas that will be applied.
• The lots: whether the contract is split into parts, and how many of them a single company may bid for.
• The budget, the term of the contract and any extensions.
• The guarantees, the penalties and the special conditions of performance.

What the PPT is, and how it differs from the PCAP

The PPT is the Pliego de Prescripciones Técnicas, the technical specifications. It describes the technical requirements of the service, supply or works being bought: what has to be done, with what resources, to what standard, over what scope and what is expected to be delivered. If the PCAP says how the competition works, the PPT says what will have to be carried out. It is the document the technical proposal is built on, because what it asks for is what the proposal has to answer, point by point.

The distinction matters for a practical reason: the administrative staff tend to read the PCAP, the technical staff tend to read the PPT, and what slips between them is whatever turns up where nobody was looking. A technical requirement can sit in the PCAP as a solvency condition, and a deadline or a delivery format can appear in the PPT. Both are binding. They have to be read in full, together, with the annexes to hand.

Mandatory requirements, scoring criteria and conditions of performance

The commonest mistake in reading a specification is to treat everything in it as equally important. It is not. Three different things sit side by side in a specification, and confusing them is costly: the minimum requirements, which have to be met or evidenced in the form required before an offer can compete at all; the award criteria, which exclude nobody but decide who wins; and the description of performance, which sets out how the contract will run and which has to be accepted rather than scored.

An award criterion is what the offers are scored and compared on. It can be automatic, such as a formula applied to the price, or it can rest on a technical assessment of the proposal. Knowing how much weight each one carries changes the whole strategy: a technical proposal is not written the same way when most of the points sit in the price as when they sit in the technical assessment. That split is in the PCAP, and it is the first thing anyone who bids regularly looks for.

A sensible order to read them in

1. The object of the contract and the lots. Is this what your company knows how to do, in full or in part?
2. The mandatory requirements and the solvency. Can you bid, and what will you evidence it with?
3. The deadlines. Is there enough time to prepare everything that is being asked for?
4. The award criteria and their formulas. Where are the points, and what kind of offer wins them?
5. The documentation required, the formats and the page limits. What exactly has to be submitted, and how?
6. The conditions of performance, the guarantees and the penalties. Can you deliver what you are about to sign up to?

Reading specifications with AI: where the real work is

Reading a specification is, above all, a job of extracting and ordering: turning hundreds of pages into a structured list of object, lots, budget, deadlines, criteria, formulas, solvency, documentation, formats, length limits and grounds for exclusion. A general-purpose AI model can summarise a document. The real work lies in missing nothing, in every requirement still pointing to the line it came from, and in flagging what the company has to confirm before it decides.

That is what Carabela's tender analysis does: it reads the main documents and the annexes, separates what is mandatory from what scores, and flags what the company still has to confirm. The system does the reading; the decision remains yours. Whether to bid or pass, what price to set and who signs all wait for a person. The whole process, from detection to a proposal ready to submit, is walked through step by step in how the system works.