Mission Companion is a vendor-neutral, browser-only workflow for recording mission confirmations and evidence references before and after a drone operation. Release v0.1.0 is a planning aid. It does not plan routes, control aircraft, parse native flight logs, determine legal compliance, approve an operation, or prove that supplied evidence is authentic or sufficient.
The release exists because mission records are often split across checklists, ground-control screenshots, log files, messages, and corrective-action notes. Mission Companion gives those references one consistent index without replacing the flight stack that created them.
The controlled workflow
The current release uses five steps:
- Define the mission identifier, purpose, owner, aircraft, payload, software baseline, site, and operating boundary.
- Confirm the human-reviewed preflight conditions and record unresolved items.
- Reference the files or systems that hold the mission evidence.
- Review outcomes, deviations, anomalies, and follow-up actions.
- Export a browser-generated record for retention and further review.
All mission facts are user-entered. The application does not independently verify the aircraft configuration, operator authority, weather, airspace status, or file contents.
Why it sits beside the flight stack
PX4 and ArduPilot provide autopilot capabilities, configuration, mission functions, and logs within their respective ecosystems. MAVLink defines a message and mission protocol used across many tools. Mission Companion does not compete with these projects. It provides a thin governance layer for the questions that may fall between systems: which baseline was intended, who confirmed the release conditions, where evidence is stored, what deviated, and who owns the follow-up.
Use the official PX4 documentation, ArduPilot documentation, and MAVLink Mission Protocol for the current behavior and limits of those projects. A local checklist must never override the approved manuals, operating rules, authority decisions, or safety procedures that apply to a real mission.
Evidence fields in v0.1.0
| Field group | What it records | What it does not prove |
|---|---|---|
| Mission identity | User-entered mission and configuration reference | That the configuration matches the aircraft |
| Human confirmations | Who recorded each confirmation | That every required authorization exists |
| Evidence references | Where a log, image, report, or record is held | File authenticity or evidentiary sufficiency |
| Deviations | What changed from the intended plan | Root cause or corrective-action effectiveness |
| Export record | A portable summary of entered data | Certification, approval, or immutable audit status |
Apache-2.0 source package
Download the versioned source archive, published August 31, 2026. The UAMKT-authored TypeScript engine, regression tests, synthetic sample, README, notices, package metadata, and license are distributed under the Apache License 2.0. The archive does not include an authority decision, a validated operational procedure, or third-party flight-stack source code.
Release boundaries
The application is intentionally browser-first and does not require a live aircraft connection. That makes it useful for demonstrations, tabletop exercises, procurement workshops, and evidence-pack design. It also means the user must control data retention, access, backup, and the relationship between exported records and the authoritative system of record.
Synthetic sample data, when provided, is labeled as demonstration material. It is not an operational result. Users should not enter sensitive, export-controlled, personal, or mission-critical information unless their own information-governance rules permit it.
Suggested evaluation
Evaluate the release with a completed historical or synthetic mission, not a live operation. Ask an independent reviewer to locate the mission boundary, configuration reference, human confirmations, evidence links, deviations, owner, and reopen trigger. Record any missing field before considering the workflow for a controlled pilot.
The public release page states the current scope and limitations. Future changes should preserve that boundary unless a separate validation and authority path is established. The useful claim is narrow: Mission Companion helps organize user-entered mission evidence references into a reviewable record. It does not make the operational decision.
Change-control note
Version 0.1.0 is the baseline described by this release note. Any later version should publish the changed fields, migration implications, known limitations, and validation status before the public scope statement is widened. A new interface or additional export field is not evidence that the tool has been validated for live operations. Reviewers should compare the version named in an exported record with the version of the public documentation they used, and retain both when the record supports a procurement, training, or pilot decision.
