ADDED 15 September 2026 · R2.1 · Proposed implementation; no flight integrations built
Read the investment and R&D memo first. This is a staged extension to the R2 service/evidence platform, not a decision to manufacture an aircraft, sensor or universal flight controller.
Product boundary
The customer commissions a defined observation. Canopy associates the permitted mission, sensor readings, source files, quality review and acceptance with an asset. For supported platforms, it can eventually request a bounded mission through an authorised adapter. The existing flight controller and qualified operator retain their approved responsibilities.
Separate three capabilities in the product UI and commercial contract:
| Capability | First implementation | Promise to avoid |
|---|---|---|
| Telemetry and evidence sharing | Read-only ingest, source identity, timestamps, quality and permissions | Phone location is aircraft telemetry; a missing value is zero |
| Mission coordination | Capability lookup, approved job specification, readiness and operator approval | A mission format means every aircraft can perform it |
| Flight/payload commands | Later, allowlisted functions through tested official interfaces and an explicit control owner | Generic joystick control, unrestricted cloud autonomy, universal compatibility |
MAVLink/MAVSDK, DJI APIs and Auterion/Pixhawk interfaces already cover important portions of this stack. Build on them; do not invent a new radio protocol. The novelty hypothesis concerns semantic consistency, quality assurance and reduced customer work. No patentability conclusion has been established.
Proposed architecture
The loop describes a proposal, not a flight safety architecture. Source permissions, tenant boundaries and the operator's authorisation apply throughout. A common schema does not mean customers share data.
Compatibility contract
Create one row for each tested combination of aircraft, payload, dock/controller, firmware, API version and deployment region. Record read access, available commands, update rate, failure behaviour, timestamp basis, calibration data, licence restrictions and last successful conformance test. Unsupported functions must be explicit. Customer-facing “supported” status requires a completed test; supplier documentation alone is “candidate”.
Begin with a PX4/MAVLink simulation and one supported DJI enterprise integration, conditional on access, customer equipment and OEM terms. They are candidate test targets, not working integrations. ArduPilot needs its own conformance tests: MAVSDK documents implementation differences [S61]. A legacy or closed aircraft may permit only file import; that remains valuable without pretending to provide live control. Fixed-wing, VTOL, spraying and delivery aircraft each require separate capability and operating constraints.
Minimum data and command design
- Evidence envelope: tenant, asset, mission, source device, source type, capture/receive time, clock uncertainty, coordinate frame and altitude datum, value/unit, measurement uncertainty, calibration reference, firmware/version, original file reference, licence and processing history. Unknown values remain unknown.
- Capability record: device/payload identity, supported operations, tested combinations, operating limitations, current health, permission state and quality of telemetry. A capability advertised by a device is not automatically enabled by policy.
- Proposed command envelope: request identity, actor, tenant, selected device, explicit authority owner, expiry, approved mission/version, requested supported action and state. Distinguish request acceptance, execution and completion; acknowledgement alone cannot mark an inspection complete.
- Control safeguards: one authorised command owner per controlled function, explicit handover, access revocation, stale-state rejection and adapter-specific failure handling. Reconcile uncertain outcomes before retrying a non-idempotent action. Never blindly replay stored movement commands after reconnection.
- Deployment: authenticated encrypted transport, separate tenants and data retention, controlled connector credentials, signed/versioned adapters, monitored audit history and a tested rollback. Protocol signing by itself must not be represented as full transport encryption or operational approval.
All names and schemas above are proposals. Do not put cloud round trips in the flight-stability loop. Network loss follows the established platform/operator contingency. A Canopy service outage must not disable onboard safety behaviour. Technical validation and the operator's operating approval are distinct gates.
Sensor development decision
Start with existing supported visible/thermal or other buyer-required payloads. Attach their observations to the common evidence envelope and test comparability. Only investigate a proprietary read-only quality/timing module if existing telemetry and supported sensors cannot supply a buyer-valued measurement.
For each candidate, obtain supplier terms and quotations; define the measurement and accepted error; inspect installation constraints; establish a reference method; test calibration drift and time alignment; measure payload/endurance effects; and confirm the modified configuration's operating basis with the responsible operator. No generic mass, power, accuracy or price specification is justified yet.
The first payload experiment should answer one question such as “Can the customer accept the same thermal inspection record from two supported configurations?” Thermal observations require a qualified interpretation and capture method. Gas observations require a validated sampling approach; a gas-sensor demo is not proof of emissions-rate measurement. Sensor calibration and operating-envelope validation are separate from software acceptance.
R&D work packages
| Work package | Deliverable | Evidence needed to proceed |
|---|---|---|
| Buyer baseline | Accepted output, current method, cost/time and failure categories | Paid sponsor or paid pilot, data permission and named reviewer |
| Integration | Two read-only candidate adapters and capability matrix | Replay records reconcile; missing/stale/incorrectly framed data remain visible |
| Quality research | Coverage, timing and measurement-quality checks | Blind comparison with reference labels; false alarms and missed failures reported |
| Sensor qualification | One existing payload assessed across supported configurations | Reference-method results and installation/operational acceptance |
| Supervised automation | Bounded workflow in simulation, then permitted site tests | Operator approval, tested exception ownership and incumbent comparison |
| Commercialisation | Supported SKU, quote, support scope and next paid order | Contribution after support/field work; partner IP and licensing terms |
Cost every package using named people and supplier quotations. Project plan, owners and resource commitments remain to be agreed. Keep grant-funded work and commercial delivery costs traceable and prevent double funding.
Tests that resolve material risks
Before enabling live mission requests, test incompatible firmware, stale position, coordinate/altitude mismatch, missing calibration, duplicate requests, uncertain acknowledgement, link loss, expired permission, conflicting command owners, wrong-tenant access and incomplete evidence. Verify each adapter's actual behaviour; do not assume identical commands have identical meanings.
Record comparisons against a human-reviewed baseline and the incumbent's supported workflow. Report cost per accepted result, integration/support hours, intervention minutes, rework, field visits and measurement quality. Pre-agree the sample, error tolerances and commercially meaningful improvement. These are product experiment gates, not proof of aviation certification or rare-event safety.
Design-agent instructions
Use the original Canopy visual style. Add a concise idea board, this architecture loop and a staged autonomy/funding slide. Present candidate devices and sensor modules as concepts. The R2.1 working deck includes a vector diagram in public/assets/integration-loop-r2-1.svg; restyle it using the original design tokens. Preserve technical distinctions and keep detailed protocols in this download rather than the main investor narrative.
Do not show a live fleet, fabricated sensor readings, completed grants, universal compatibility, claimed OEM partnerships or military accreditation. Keep homeowner and promotional services in the expanded market story, while making the first commercial experiment and R&D experiment visibly separate. All substantive additions need the next release/date stamp.