ADDED 15 September 2026 · R2 · Design proposal, not a deployed operations system
This extends the R1 job and evidence design. Agriculture becomes one service template. The common entity is an asset or site, not necessarily a field. No live aircraft control, emergency dispatch or payment handling is implemented by the investor prototype.
Three customer experiences
| Experience | Intake | Result | Commercial object |
|---|---|---|---|
| Capture | Address/site, desired photos/video, date window, access and rights | A scoped quote, operator assignment and approved media | Job with explicit deliverables, revisions and cancellation terms |
| Portfolio | Organisation, sites/assets, cadence, capture specification, reviewer and destination | A scheduled programme, exception queue and asset evidence history | Separate software entitlement and agreed capture service orders |
| Assured programme | Named sponsor, purpose, procurement reference, permitted equipment, data classification and deployment boundary | Controlled project workspace and acceptance evidence | Approved statement of work, milestones and funded support obligation |
Expose the relevant workflow after the service is selected. Avoid presenting pesticide approvals on a photography job or creative music rights as an engineering acceptance criterion. Eligibility remains mission-specific and human reviewed before committing capacity.
Service-template contract
Every versioned template defines buyer outcome, required inputs, evidence fields, qualifications, deliverable formats, reviewer role, acceptance checks, rights, retention, pricing unit and cancellation rules. A quote fixes the template version and records exceptions.
| Template | Additional fields | Acceptance owner |
|---|---|---|
| Home/property image | Shot list, aspect ratio, edit allowance, owner access, personal/commercial use rights | Buyer or listing agent |
| Promotional production | Storyboard, music/brand rights, cut length, formats, revision rounds | Named creative approver |
| Roof condition capture | Asset IDs, required viewpoints, inaccessible areas, raw files, specialist interpretation scope | Qualified reviewer where technical opinion is contracted |
| Construction progress | Baseline date, repeat viewpoints, location/time evidence, customer project reference | Project manager |
| Survey / utility inspection | Sensor and calibration records, coordinate system, control/accuracy method, limitations | Qualified survey/engineering reviewer |
| Civil / assured programme | Authority, permitted team/equipment, deployment and data policy, escalation owner | Contractually authorised reviewer |
| Agricultural application | Parcel, crop/product/use authority, agronomy inputs, application record | Relevant qualified agronomy/operator and buyer roles |
Core records and extensions
Core: organisation, account, site, asset, service-template version, request, quote, mission, operator qualification, evidence file, finding, review, acceptance, invoice reference, payout reference and incident. Keep service-specific payloads versioned; preserve the raw source and units. Link each record to a tenant and immutable ID. Commercial references do not establish payment settlement.
Evidence must capture source type, acquisition time, upload time, asset/site, permissions basis, file hash, format, processing version and uncertainty/limitations. Photos, operator logs, device telemetry and manual statements are distinct source types. Corrections create a new version rather than rewriting history. AI-derived findings reference the exact source, method version and human review status.
Routing and review
Aircraft operation remains in the qualified operator's approved process. The application records readiness; it does not issue an aviation permission. Commercial flight in the UK/EU can be within the Open category when the operation meets the rules. Specific operations and US Part 107 missions require the relevant current conditions [S38–S41].
Architecture and data boundaries
Reuse code and service schemas where suitable; do not assume all customers share a data plane. An assured deployment needs its own approved infrastructure, identity, keys, logs, support access, supplier policy and recovery process as required by contract. Cross-boundary transfers require an explicit permitted export. Sensitive evidence must not flow into commercial analytics or model training by default.
For ordinary commercial work, use authenticated evidence access, scoped roles, signed expiring download URLs, tenant-level isolation, encrypted storage, retention jobs, restore verification and audit logs. Public portfolio publication requires explicit rights. Privacy assessment, minimisation and notices are particularly relevant to residential and public-space capture; ICO's reviewed guidance is marked under revision [S42].
API and workflow additions
Proposed resources: /service-templates, /sites, /assets, /programmes, /quotes, /missions, /evidence, /reviews, /acceptances. Use idempotency keys for writes, explicit state transitions and optimistic concurrency for quote approval. Model line items separately for capture, production/editing, reviewer work, travel, software and taxes. Store original quote currency and tax basis; do not silently convert.
Introduce an append-only decision record for a pivot: prior hypothesis, cohort evidence, decision date, owner, approved experiment, customer impact and budget evidence. This is a management record, not an automatic algorithm that changes pricing or cancels customers.
MVP scope and acceptance
- Two launch templates: property media and construction progress. Asset/site intake, quote versioning, operator qualifications and scheduling windows.
- File upload and offline queue, source metadata, delivery checklist, named reviewer, corrections and buyer acceptance. Do not mark a job complete solely because a flight log exists.
- Portfolio import, repeated job scheduling and evidence history. Customer exports before specialist analytics.
- Quote/invoice references and contribution measurement. Operational payments require a separately implemented and tested payment integration.
- Pilot review dashboard: first-pass acceptance, delivery-window performance, repeat buyers, support time, rework, gross service value, earned Canopy fees and collected cash.
Acceptance criteria include cross-tenant access denial, duplicate upload handling, source preservation, expired qualification holds, offline retries, partial delivery, revision limits, cancelled-weather windows, data deletion/export rights and invoice reconciliation. A new sector is ready only after its template, operator qualification, reviewer responsibility and unit economics are validated.
The investor deck adds an interactive service-specification demonstrator. All selections describe proposed workflows; no request is transmitted and no price is represented as a Canopy offer.