How to prove every required tender attachment is present

Proof standard

Presence is only one part of attachment completeness

A filename in a folder proves very little. The buyer may require a declaration from a particular legal entity, a workbook for a particular lot or a CV for every named specialist. A file with the expected name can contain the wrong subject, an old template or an unsigned draft. The manifest therefore tests the obligation and the file as separate objects, then records the link between them.

Start with a stable context: procurement identifier, response stage, current package version, selected lots, bidding entity, consortium structure, relied-on entities, known subcontractors, named personnel, proposed variants and submission language. The same instruction can create one attachment for a sole bidder and six for a consortium. A change to that configuration can alter the required set without changing the tender documents.

A row is complete only when the requirement is current, its trigger and cardinality are resolved, the correct owner has supplied an approved instance and the final file passes the checks that apply to it. If any of those facts is unknown, the row stays open. An overall green count cannot override an open material row.

Requirement discovery

Derive the list from every controlling instruction

The buyer may place attachment instructions in the main response guide, a list of documents, a form footer, a question branch, the selection evidence section, an amendment or a portal slot description. No single table should be assumed complete unless the tender expressly makes it controlling. Search for action words such as attach, upload, provide, submit, complete, sign, include and enclose, then read the condition and timing around each occurrence.

Preserve the exact sentence and a precise locator in the buyer's material before writing a short normalized description. Record the document function as well as its name. A form template may define its own mandatory annexes; a clarification may remove one; an amendment may replace the template while leaving the filename unchanged. The manifest needs these relationships so a later version does not sit beside an obsolete requirement as if both were active.

Reconcile repeated instructions rather than deleting them. Two occurrences may confirm the same obligation, narrow it to a lot, add a signature, move the due stage or create a conflict. Link them to one requirement only after their subject, scope, trigger, timing and output agree. If they do not, retain separate rows and resolve the difference through the applicable source hierarchy or buyer clarification.

• Inspect the current notice, invitation and response instructions.
• Read every mandatory form, workbook and schedule for embedded annex requests.
• Follow cross-references into definitions, evidence clauses and question guidance.
• Include amendments and authorized clarification answers in the source chain.
• Record portal-only wording as a separate observed source with its check time.

Object and timing

Not every requested item belongs in the upload set

Classify both the delivery object and the due event. A narrative entered into a portal field is not an attachment. A certificate the buyer retrieves from a public register may need an identifier rather than a duplicate file. A scale model, sample or oral presentation follows another delivery route. Mixing those objects into one attachment count creates false missing rows and distracts the reviewer from files that must accompany the tender.

Timing changes the answer just as much. Some evidence accompanies the request to participate, some the tender, some only a later buyer request, and some only the proposed winner before award. Keep those stages visible. A document that is valid and available but not due now should be `not_due_at_submission`, not missing and not silently uploaded early.

Never treat the possibility of later supplementation as a production plan. Article 56(3) of Directive 2014/24/EU allows a contracting authority, within its stated conditions and national implementation, to request incomplete, erroneous or missing information. Germany, France and US federal procurement each draw their own boundaries. Those provisions confer no general supplier right to repair an omitted attachment after the deadline.

Cardinality

Calculate the required copies from the actual bid configuration

Words such as each, every, per lot, for all members and where applicable control the number of instances. Store the repetition rule before expanding it. Then apply the frozen bidder configuration. A requirement for a declaration from each consortium member becomes one row per legal entity; a technical schedule per offered model becomes one row per model; a method statement per lot becomes one row for every selected lot.

Conditional questions need the same treatment. If selecting subcontracting, reliance on another entity or use of a proposed variant activates a supporting form, keep the condition linked to the answer that resolved it. `No` may close one branch but open another explanation. `Unknown` cannot be counted as zero. The manifest should show the unresolved trigger and the smallest set of files it blocks.

Use a stable instance key that includes the requirement, stage and scoped subject. Human-readable labels such as `CV, engineer 2, Lot B` help reviewers, but the identity should not depend only on a filename. People and products can have similar names, and renamed files should not create a second obligation.

• Expand per-tender items once for the complete response.
• Expand per-lot items only for lots the approved bid includes.
• Expand entity evidence for the exact role named in the instruction.
• Expand person, site and product evidence from controlled final lists.
• Recalculate after any configuration or conditional-answer change.

File identity

Bind each row to an approved file, not to a folder

Assign three responsibilities where the risk justifies it: the fact owner supplies the underlying information, the producer creates the attachment, and an authorized reviewer approves or signs it. One person may hold more than one role, but the manifest should show which decision they made. A file moving into a shared directory is a handoff event, not approval.

Connect each row to a controlled candidate ID and record the source template, content version, subject, scope, required issuer, language, date, signature or declaration state, final filename and intended destination. Detailed format, size, naming and digital-signature tests belong to their dedicated preflight work, but this manifest must carry their result or blocker before it can release the file.

Freeze the candidate bytes after approval and retain a checksum if policy allows. Open the exact frozen file in the software used for final inspection. Check that pages, sheets, signatures, embedded objects and visible identifiers are present. A successful open does not prove legal validity or factual correctness, yet it catches the common case where the manifest points to a shortcut, corrupt export or earlier draft.

Two-way control

Check obligations forward and candidate files backward

The forward check starts with every active required instance and ends at one of three defensible outcomes: an approved frozen file, an evidenced not-applicable decision or a source-backed later-stage classification. Anything else remains open. Percent complete can help planning, but it must never hide the identity and consequence of the missing row.

The backward check starts with every file proposed for the buyer and asks which current instruction authorizes it, what it answers and where it is meant to go. This catches duplicate editions, superseded forms, internal notes, source evidence that should remain private and brochures nobody requested. Remove unsupported files unless an authorized reviewer confirms their permitted purpose.

One file can sometimes satisfy several rows. Preserve the many-to-many links and test whether the tender allows the treatment, whether the file covers every scoped subject, and whether each evaluator can find the required material. Do not merge forms that require separate signatures or repeat one generic document merely to make all rows appear green.

• Forward: requirement instance to disposition to exact final file.
• Backward: candidate file to authority to intended requirement and destination.
• Collision: several files claim to satisfy one instance.
• Coverage: one file claims several instances but omits a scoped subject.
• Orphan: a required row or candidate file has no valid link.

Worked example

A rail maintenance bid needs more than a folder checklist

Consider an illustrative regional rail-maintenance tender with two lots. The instructions require one signed bidder declaration, a method statement and price workbook for each selected lot, a competence schedule for each lot, and a CV plus availability declaration for every named lead engineer. Insurance evidence is requested only from the intended awardee. The bidder selects both lots and names three engineers, one shared across them.

The manifest does not count six document labels and stop. It creates one bidder-declaration instance, two method-statement instances, two price-workbook instances, two competence schedules and the person-specific CV and declaration instances required by the wording. The shared engineer is tested against the scope of both lots. Insurance remains a later-stage row and is not added to the current upload set merely because the file is available.

During review, the Lot B method statement points to version 4, but the candidate folder contains version 3 and version 4 final. The row stays blocked until version 4 is approved and frozen. A corporate brochure has no requirement link and is removed. The completed manifest proves why every retained file belongs and why the available insurance certificate does not.

Release boundary

Freeze the manifest before package assembly and reopen it after change

An independent reviewer should receive the source baseline, manifest and frozen candidate files. They sample nothing: every active attachment instance receives a disposition. They open each file, compare the identity-bearing facts and execution state with the row, then confirm that unsupported candidates have been removed. The result is `complete_for_final_assembly` only when no required row is unresolved.

The manifest does not choose the upload order, operate the portal or prove that the buyer received the bid. It hands a controlled set to file preflight and package assembly, which apply naming, format, size, signature and destination rules before an authorized submission. Those later steps should return the actual transmitted identity and receipt to the release record.

Reopen affected rows when an amendment, clarification, lot choice, consortium member, subcontractor, named person, answer, template, evidence item or approved candidate changes. Keep the superseded record. Rechecking only the edited file misses dependent declarations and cross-references. Recalculate the required instances first, then repeat the two-way reconciliation.