For your first Italian Space Agency tender, begin with the specific ASI procurement package and turn it into a list of commitments your team can understand, price and deliver. A convincing technical idea is only one part of that work. This guide uses a closed 2025 ASI research and development procedure to show how to inspect the notice, organise the response and carry accepted commitments into engineering delivery.
The practical objective is a bid that remains usable after award. If your technical proposal promises a prototype demonstration, a software deliverable and a verification report, the delivery team should be able to find who owns each promise, what it depends on and how completion will be assessed. Treat proposal preparation as the beginning of that connected record.
Identify the customer and the actual procedure
The Agenzia Spaziale Italiana publishes its own opportunities. The historical call used here concerns R&D services for innovative technologies and research, procured through a competitive procedure with negotiation. Its subjects include AI and robotic systems, advanced materials, and space biotechnology and agriculture. This is a concrete ASI procurement example, rather than a generic description of every Italian space funding route.
Write the issuing organisation, procedure reference, prospective contracting party and document location at the top of your opportunity record. Separate a direct ASI response from an ESA invitation or a proposed subcontract. For shared ESA mechanics, use the first ESA contract guide. An industry partner suggesting a collaboration has not, by itself, established which agreement your company would sign.
Read a historical package without reviving its deadline
The example call was published in June 2025. Its original PDF printed a July 2025 deadline, while the call page records a revised deadline of 22 September 2025 and later administrative updates. It is closed. This difference illustrates why a saved notice alone is an incomplete source: inspect the publication page, revisions and clarification responses together. A recent page update does not turn a closed call into a new invitation.
In the original call's introduction, proposals are expected to be technically feasible and financially sustainable, with a development plan covering costs, timing and potential users. Its contents separate participation conditions, administrative documentation, the technical-management offer, the economic proposal, evaluation and contract signature. Use those categories to assign reviewers before substantial drafting begins.
Make a controlled copy of the package available to the team. Record when each document was retrieved and whether a later clarification affects it. Keep your internal interpretation in a separate field from the source wording, so another reviewer can challenge the interpretation without losing the original reference.
Build a document-to-decision map
The table below is our suggested working map, based on the attachment categories published with the example call. The reviewer assignments are recommendations, not ASI-prescribed roles. It helps expose a common preparation gap: the person writing the technical offer may not be the person who can assess the agreement or substantiate the cost model.
| Published material | Question for your team | Suggested review owner |
|---|---|---|
| Draft R&D agreement | What would we commit to deliver and maintain? | Commercial lead with engineering lead |
| Technical-management proposal format | Does the work plan substantiate the promised outcome? | Technical lead |
| Economic and costing documents | Are estimates consistent with the described work? | Finance and work-package owners |
| Subcontractor documentation | Which partner commitments need confirmation? | Supply-chain or bid lead |
| Third-party software requirements | Which proposed software deliverables are affected? | Software and assurance leads |
| Declarations and clarifications | Is our response complete and based on the latest answers? | Bid coordinator |
Read the attachments themselves before making a compliance commitment. A filename tells you that a document exists; it does not establish its full requirements or their applicability to your proposed scope. Maintain a question register for missing information, with the source, the decision it blocks and the person responsible for resolving it through the specified clarification route.
Worked example: Lark prepares a prototype proposition
Fictional supplier exercise. Lark is an attitude-control unit example used across this series, not a real customer or an ASI award. Here its team is considering a future R&D opportunity. The example does not assert that Lark would qualify for the closed call. Start from the shared Lark programme example and use only the records relevant to the proposed work.
The team initially writes “demonstrate improved attitude-control performance”. During its internal review, it replaces that broad promise with a proposed demonstration scope: identify the operating conditions, comparison basis, test configuration and report needed to assess the improvement. It leaves unresolved values as questions rather than inventing a customer acceptance threshold. A promising concept becomes a proposal another engineer can cost and examine.
Three preparation decisions then become visible. The software lead identifies which functions are included in the prototype. The test lead identifies the facilities and inputs needed for the demonstration. The partner lead checks whether an external laboratory's proposed contribution matches the work and budget described in the offer. None of those checks proves the prototype's performance. They establish whether the proposed programme is coherent enough to take forward.
Preserve the distinction between an existing capability, a planned development and a result you intend to demonstrate. In the case, the team can describe its proposed test approach before it has performed the test. Its bid should not present that plan as completed qualification evidence.
Use a readiness gate before submission
Our suggested gate asks each reviewer to close a specific question. A missing answer should produce an action or a deliberate bid decision, rather than a vague confidence score.
- Eligibility: record the actual participation conditions and evidence for the proposed company or grouping.
- Scope: reconcile the technical narrative, deliverables, work packages and partner contributions.
- Cost: check that engineering effort, verification work and external services appear consistently in the estimate.
- Agreement: review the draft contract alongside the promises in the proposal.
- Documents: check the required formats, declarations, signatures and submission instructions in the current package.
- Questions: incorporate issued clarifications and identify any remaining assumptions explicitly.
- Delivery: name owners for the first engineering activities and evidence records if the bid succeeds.
Keep one final consistency pass separate from proofreading. Ask whether the same deliverable has the same scope, owner and completion basis in the technical proposal, partner statement and cost model. Clear prose cannot repair incompatible commitments. Conversely, a concise proposal can be strong when its claims have visible support and its remaining uncertainties are handled openly.
Connect ECSS preparation and bounded agent assistance
If the tender invokes ECSS material, record the actual documents, editions and project decisions before building your response. ECSS's top-level system publication explains the customer–supplier context. Our practical recommendation is to maintain a traceable obligations register covering product requirements, process work and deliverables, rather than treating the agency name as a complete specification.
Arc supports that organisation by connecting requirements, engineering work, verification, evidence and review decisions. Its configurable model and ECSS project templates can support the initial setup. Its ECSS agents can check relevant clauses and propose edits for review. See Arc's ECSS workflow reference for the product boundary.
For Lark, a bounded task might ask an agent to inspect selected obligations and suggest unclear or unsupported compliance responses. The engineer checks each source and proposed edit before adopting it. A call whose research subject includes AI does not establish that an AI assistant may make contractual commitments or approve engineering work. Those are separate questions, and the final bid still needs its designated reviewers.
Frequently asked questions
Where should I start with Italian Space Agency tenders?
Start from the specific ASI notice and its complete attachment and clarification set. Identify the procedure, applicant conditions, submission method, draft agreement and required response documents before deciding whether the opportunity fits your team. The 2025 call in this guide is a historical example, not an open opportunity.
Is an ASI R&D tender the same as an ESA tender?
No. The historical procedure examined here procured R&D services for ASI and supplied its own call documents. An ESA invitation has its own contracting route and tender package. Use the issuing organisation and specific notice to identify the customer, submission process and applicable conditions.
Which documents did the example ASI call provide?
Its published list includes a draft R&D contract, a technical-management proposal format, economic and costing documents, subcontractor documentation, declarations and SSDC requirements for third-party software. It also publishes clarification responses and a revised deadline. This is the document set for that call, not a universal ASI list.
Does an ASI call about AI approve using AI to prepare the bid?
No such approval is established by the topic. The example call includes AI and robotic systems as research subjects. Our proposed use of an assistant to organise sources or draft questions is a separate working practice, to be checked against the actual project, confidentiality and review arrangements.
How can Arc help after the opportunity is selected?
Arc can connect requirements, engineering work, verification, evidence and review decisions. Its ECSS templates can support project setup, and its ECSS agents can check relevant clauses and propose edits for review. The team still determines the contract scope and reviews the resulting engineering and compliance decisions.
Evaluate Arc
Turn your next space contract into a clear engineering plan.
Connect the technical commitments in your next space tender to a delivery plan. Arc brings flexible programme records, ECSS project templates and compliance agents that check relevant clauses and propose edits for engineer review.