By MARDE Inc. · Published
Updated
Prepared by MARDE Inc. as an editorial synthesis of the linked primary sources and a proposed evaluation framework. MARDE’s contribution is the claim-to-evidence questions and hypothetical exercises, not original experimental or clinical findings.
Key answer
Start with the agency’s problem, then ask what exists, what has been tested and which claims remain objectives. Agree on a bounded exercise, roles and success criteria before testing. MARDE currently invites requirements feedback as a concept-stage developer, not procurement of a deployed product.
Start by identifying the development stage
An early-stage company can contribute ideas and engineering work without offering an operational product. An agency should ask what exists today, what has been tested and what remains a design objective. A clear answer is more useful than a polished demonstration that leaves the configuration and limits unstated.
MARDE is pre-seed, pre-prototype and pre-revenue. Its immediate goal is an integrated human-in-the-loop V1 demonstration. There are no announced commercial pilots or validated full-system results. A conversation with MARDE should therefore begin with research questions and requirements rather than procurement of a ready emergency-response service.
Define the agency problem independently
Write the operational problem before adopting the vendor's proposed architecture. Identify the relevant setting, receiving role, access barriers and existing alternatives. A useful problem statement explains what improvement would matter and which constraints cannot be changed. It also identifies situations where the concept would not be appropriate.
Requirements discovery can use de-identified scenarios and general conditions. Patient records, sensitive access details and production-system credentials are not necessary for a first discussion. Agencies should preserve their own information-governance requirements as the conversation becomes more specific.
Ask for a claim-to-evidence map
For each proposed capability, ask whether it is a goal, an observed bench result, an integrated exercise result or an operational outcome. Request the configuration, conditions, number of attempts and intervention record. A video can illustrate an event but rarely supplies the full denominator or repeatability information.
The company should be able to identify which conclusions change if hardware, payload, software or environment changes. External literature can inform the concept but should not be presented as evidence that the company's own system works. An agency can make this distinction a routine part of review rather than an adversarial demand.
Design a small, bounded exercise
An early exercise should answer a limited question under controlled conditions. Agree on success criteria, stopping rules, roles and reporting before the test. Include cases in which an operator declines or interrupts the mission. Record failures and recovery so the result describes the workflow rather than a selected successful attempt.
NIST response-robot methods can help frame repeatable task evaluation. The actual method selection needs to match the proposed use case. A test inspired by a published method should not be represented as formal certification, and a subsystem result should not be promoted into clinical or deployment readiness.
Keep responsibilities and approvals explicit
A future evaluation may involve aircraft operation, ground control, payload receipt and clinical responsibility. Identify who owns each decision and what happens if the system is unavailable. The agency should understand the staffing and training assumptions rather than discovering them during an exercise.
Any eventual operational pilot requires separate review of applicable permissions, safety, data handling and institutional obligations. FAA resources are a starting point for aviation questions, not approval of a vendor or mission. A research conversation should not silently create a promise of dispatch integration, equipment purchase or clinical use.
Use a decision record instead of a vendor score alone
An agency can keep a short record of the decision being considered, the evidence available and the reason for the next step. The decision might be whether to continue requirements discovery, observe a controlled demonstration or decline a proposed configuration. These are different commitments and should not be compressed into a general positive assessment of the company. A record can identify unresolved questions without demanding that every early-stage uncertainty be solved immediately. It also gives future reviewers context when personnel change or when a later proposal differs from the one initially discussed. Keep private institutional information under the agency's own controls.
The company can maintain a corresponding public claim register that identifies what it is willing to say and what remains unvalidated. The two records need not contain the same confidential details to support a clear conversation. A useful outcome is agreement on the next question and the evidence that would answer it, including a reason to stop if the approach proves unsuitable. MARDE's initial conversations should be framed this way. Participation in discovery should not be described as a sale, partnership endorsement or operational pilot unless the organization has separately agreed to that relationship and its public description.
A hypothetical first requirements meeting
An agency and an early-stage team can begin with one de-identified access scenario. The agency explains where useful equipment would need to arrive and what currently prevents that arrival. The company explains which parts of its concept might address the problem and which are still unknown. Neither side needs to promise procurement or clinical use for the discussion to produce a meaningful requirements document.
At the end of the meeting, write down the proposed receiving point, responsible roles and the conditions that would make an exercise inappropriate. Identify the existing alternative and the improvement that would matter. Then list the evidence required before considering another stage. This prevents a broad statement of interest from being represented publicly as a partnership or a deployment commitment.
A follow-up exercise should be narrow enough that both parties understand what its result means. If the question is whether an operator can deliver an inert payload through a defined route, do not add clinical claims to the report. If the result reveals an access barrier the concept cannot address, that is a useful finding. A requirements program should be able to conclude that a proposed configuration is not suitable.
Review the report before moving to another stage
Ask whether the report includes all attempts, the assistance provided and changes made during testing. Compare its conclusions with the agreed success criteria. Distinguish a documented observation from an explanation of why the team believes it occurred. Both may be useful, but only the observation directly describes what the exercise established. An agency can request clarification without asking the company to disclose unrelated proprietary details.
Before expanding the evaluation, agree on the next unresolved question and why it matters to the operational problem. Increasing realism is not automatically useful if a more basic assumption remains unsupported. For example, moving to a larger site may add complexity while leaving the receiving role unclear. A staged program should spend effort on the uncertainty that affects the next decision.
Public communication also deserves review. An agency's participation in a requirements conversation is different from endorsement, customer status or permission to use its name. MARDE should obtain appropriate authorization before describing another organization in an update. A transparent record can still describe the work performed and its limitations without inventing institutional support. That discipline strengthens credibility for future readers and potential evaluators.
Look for honest reporting and a useful next step
A credible early-stage partner reports what it could not demonstrate and changes its claims when evidence changes. Ask how revisions are dated, how unsuccessful attempts are described and how agency feedback changes requirements. Progress is more informative when the company identifies the next unresolved question rather than repeating a fixed launch promise.
For MARDE, the appropriate starting point is a requirements discussion through the Contact page. Share the institutional role and the access or coordination problem you want to explore. Any later evaluation would need a separately agreed scope. This page does not list existing partners, endorsements or availability for live emergency response.
MARDE remains at concept/pre-prototype stage. Its proposed outdoor supply-delivery and scene-communication system has not been built or validated; the exercises here are proposals, not completed tests.