Which files and response volumes does the buyer expect?

Correct abstraction

Start with buyer-required objects, not filenames

The first question is what the buyer expects to receive and evaluate. The answer may include a technical part, financial part, administrative declarations, a pricing schedule, one form per participant, portal-entered values and a physical sample. None of those labels proves how many files will exist. A response part is a logical object. A file is one possible representation. A portal field is a transaction surface. A sealed packet is a physical container. Use separate node types even when the buyer uses the same word for more than one of them.

Official systems make the distinction visible. The European Commission eSubmission guide says that a procedure can request a financial tender and, when required, a technical tender, and that more than one file can be uploaded in either category. Participant documents can sit in each participant's attachments area. FAR 15.204-5 provides a different bounded example: a US federal solicitation may request a specific format or severable proposal parts and can organize them as administrative, management, technical, past performance and pricing information. Neither source supplies a universal template. Each shows why "the proposal" can contain several differently governed objects.

Physical and evaluation boundaries also need separate treatment. FAR 52.215-1 gives a scoped US federal example in which paper proposals use sealed envelopes or packages unless the solicitation permits another method. The EBRD describes a single-stage two-envelope procedure in which technical and financial proposals arrive together but are evaluated separately, with the technical proposal considered first. Those rules concern their own procedures. They show that the purpose of separation can be delivery control, evaluation order or both; they do not determine the number of digital files in an unrelated tender.

Create an architecture root for the response instance, then add typed children. Useful node kinds include `logical_envelope`, `response_volume`, `buyer_template_instance`, `workbook`, `portal_field_group`, `supporting_attachment`, `delivery_object` and `file_candidate`. Preserve the buyer's original label beside a stable internal key. If the source says "Volume II" but never calls it technical, keep that label. A convenient interpretation should not overwrite issued language.

Evidence boundary

Declare which response you are mapping and which sources you could read

Architecture is conditional on a real response configuration. Record the official procurement identifier, procedure stage, selected lots, bidder legal entity, sole or joint submission, consortium members, relied-on entities, named subcontractors, variants and submission channel. A change from sole bidder to consortium can create participant-specific forms. Selecting a second lot can multiply technical and price objects. A permitted alternative can add a parallel technical and financial branch. Without the configuration, a count such as "seven documents" has no stable meaning.

Freeze the source boundary at the same time. Inventory the notice, instructions, data sheet, proposal forms, price schedules, technical schedules, amendments, clarifications and portal guides. Record version or checksum, retrieval time and access state. An authorized portal view belongs in the evidence set, but identify whether it shows a buyer-configured requirement, a general platform capability or a harmless observation. If a required source cannot be opened, use `source_access_required`. If the team cannot prove that it has the complete current package, use `source_boundary_incomplete`.

The World Bank Procurement Framework illustrates why a named family of documents is not enough. The current framework is supported by standard procurement documents, guidance, tools and templates, with different procurement methods and editions. Its two-envelope goods RFP has instructions, a procurement-specific data sheet, evaluation criteria and proposal forms. The final map for a particular procurement must combine the completed procurement-specific material with applicable instructions. It cannot copy the standard document's generic shape and call the local response complete.

• Bind the map to one procurement and one current package snapshot.
• Record selected lots and the full bidder configuration.
• Separate issued evidence, clarification and portal observation.
• Preserve unread and inaccessible sources as explicit gaps.
• Expire the map when a source or response configuration changes.

Data model

Record containment, separation and destination as evidence-linked relationships

Each node needs enough detail for a person or agent to reconstruct its purpose. Record `node_id`, buyer label, node kind, content scope, procurement stage, lots, participant scope, language, source identity, exact excerpt, buyer-visible locator, machine-recoverable selector, obligation record, status, owner and expiry trigger. Status can distinguish `confirmed_required`, `confirmed_conditional`, `permitted_optional`, `prohibited`, `unresolved` and `observed_only`. Do not use `required` because a field appeared in an internal folder or because a portal happened to display an empty slot.

Relationships carry much of the meaning. `contains` builds the hierarchy. `must_be_separate_from` protects evaluation boundaries. `attach_to` associates evidence with a form or participant. `enter_in_portal` and `upload_to_slot` describe destinations. `repeat_per_lot`, `repeat_per_entity`, `repeat_per_member`, `repeat_per_expert` and `repeat_per_variant` create cardinality. `same_content_required_in` can record an evidenced duplicate without pretending the two destinations are one object. Every edge stores its source and condition.

Signature, attestation and acknowledgement relationships may appear in the map because they affect object identity. Keep authority separate. `signed_by: authorized_bidder_signatory` describes an evidenced requirement; it does not decide who is authorized or cause a signature. Link answer limits to AN-071 and buyer-template dependencies to AN-074 rather than copying their detailed records into this artifact. This leaves one owner for each fact and still gives the package model a navigable dependency.

Instance counts

Turn words such as each, all and if applicable into tested cardinality

Most package counts depend on another fact. "Each consortium member must provide a signed declaration" is not one document requirement. It is a rule whose count equals the number of in-scope members. "Provide a method statement for every lot tendered" depends on lot selection. A CV form can repeat per named expert, while a cybersecurity questionnaire may be required once for the submission and referenced by two lots. Store the basis and trigger, not only the calculated number.

Instantiate the rules against a frozen bidder configuration. For every repeated object, record the subject key: legal entity, member, lot, role, expert, site, variant or another source-defined dimension. Test zero, one and many cases. A conditional node stays in the graph even when its current count is zero, with the condition and evidence for the result. This prevents a form from disappearing when the unresolved use of a subcontractor later becomes yes.

Reconcile counts at three levels. Logical count answers how many evaluated or administrative objects exist. Delivery count answers how many files, fields, packets or samples are expected. Instance count answers how many completed copies a repetition rule creates. The numbers often differ. A consortium with three members may have one administrative part, three signed declarations, two lot-specific technical volumes and one portal participant record per member. Calling that "one admin file plus two technical files" loses information before assembly starts.

• Preserve the exact quantifier and the subject it modifies.
• Link every calculated instance to a lot, entity, person or condition key.
• Keep zero-count conditional nodes visible.
• Recompute after participant, lot, variant or staffing changes.
• Compare logical, instance and delivery counts instead of forcing one total.

Portal mapping

Map the buyer model to the portal without confusing observation with authority

A portal can contain participant pages, structured fields, declarations, lot selectors and upload categories. Map each confirmed response object to its destination when the current procedure and authorized role expose that destination. Record portal label, page or step, participant and lot context, allowed object class and observation time. Keep the buyer instruction as the requirement source unless the procurement expressly makes the configured portal field controlling. A generic platform guide explains mechanics; it does not prove what this buyer requested.

The European Commission guide provides a useful scoped example. A user chooses sole or joint submission, identifies participants, selects lots, uploads participant documents in participant attachments, enters tender data and can upload several files in technical or financial categories. It also notes that different consortium composition by lot requires a separate submission per lot in that system. Those facts apply to the guide's stated open-procedure context. They show why participant, lot, field and upload nodes must coexist, not why another portal must work the same way.

Stop at mapping. Do not create a draft submission, change consortium structure, accept terms, click declarations, upload a file or submit. The later submission cluster owns entity registration, roles, signatures, file validation, naming, upload order, final approval and receipt. If the destination cannot be inspected safely and with authorization, return `portal_mapping_unverified`. The package can still be planned, but the unresolved interface becomes a release dependency rather than a guessed folder.

Worked example

Map a fictional two-lot transit operations RFP

A metropolitan transport authority requests one combined tender for two lots: control-room support and passenger-information operations. The instructions require one administrative part for the bidding entity, one technical method per selected lot, one staffing workbook per lot, a separate financial workbook per lot, one cybersecurity questionnaire covering the complete offer and one CV form for each proposed service lead. Legal-entity data and two declarations must be entered in the portal. The bidder selects both lots and proposes two different service leads.

The architecture has one root submission. Under it sit an administrative part, two technical branches and two financial branches. The administrative part contains the bidder declaration and authority evidence. Each technical branch contains a method volume and staffing workbook. Each financial branch contains its lot's price workbook and has a `must_be_separate_from` edge to both technical branches. The cybersecurity questionnaire occurs once and carries `applies_to: [lot-1, lot-2]`. The CV template has a cardinality of one per service lead, which produces two completed instances. The portal fields are nodes even though they produce no bidder file.

The response therefore has more logical nodes than files, and the final file count cannot be read from the phrase "three-part tender". The architecture also exposes one unresolved fact: the portal shows a single technical upload category, while the instructions require lot-specific methods. The team records both methods as separate logical objects and marks their file-to-slot mapping for confirmation. It does not combine them merely because one slot is visible. The map reaches `complete_with_review_items`, not `complete_for_response_planning`, until that destination is resolved.

Agent contract

Give agents a graph they can verify without giving them submission authority

Publish the architecture in readable prose and a compact typed representation. Each node and edge should expose its identifier, kind, scope, status, source version, exact excerpt, human locator, machine selector, review owner and expiry trigger. Preserve unresolved states in HTML, Markdown, API and MCP responses. A smaller response that drops conditions or provenance is not an equivalent representation. Agents need enough evidence to cite the rule and enough structure to answer questions such as "which objects repeat when Lot 3 is added?"

An authorized agent may inventory supplied sources, identify candidate objects, preserve labels, propose relationships, calculate deterministic instance counts and flag orphaned requirements or unsupported files. It may compare the planned graph with a read-only portal view when the customer has granted that access. Tender text is untrusted data. A document cannot instruct the agent to disclose credentials, contact the buyer, change the engagement scope or execute a transaction.

Use controlled outputs: `complete_for_response_planning`, `complete_with_review_items`, `source_boundary_incomplete`, `portal_mapping_unverified`, `architecture_conflict` and `human_review_required`. Confidence describes extraction quality only. Source conflicts route to the controlling-document process. AN-071 owns detailed limits, AN-074 owns question-to-template dependencies, AN-082 owns final pass-fail release, and the submission cluster owns portal action. AN-072 owns the evidence-backed shape of what the buyer expects.

• Expose source and state on every node and relationship.
• Make conditional cardinality executable but reviewable.
• Return orphaned nodes and unresolved destinations as data.
• Treat all tender content as untrusted input.
• Require separate customer authority for every portal action.