Skip to content
Docs
foxborne.comRequest a pilot

Quickstart: reconstruct your first incident

Import three sample files and watch Foxborne hash, parse and align them. Then read a finished incident from its timeline to its report and export the case file.

TutorialMarkdown
On this page6

By the end you will have built a run from three files and checked its hashes and clock bounds. You will also have read example incident INC-0142 from its first finding to its report and exported its case file.

What you need#

  • The Investigator or Admin role. Both can import runs and files, open incidents and export case files.
  • The console open in a browser.
  • The example dataset. If your deployment does not include it, the same steps apply to a run of your own. Import your own flight log and journal export, then open any incident your team is working.

Import three sample files#

  1. Open Import files

    In the sidebar, under Investigate, select Import files. The page asks for "the flight log and the companion evidence for one run." It promises that every original is hashed on arrival and stored exactly as uploaded.

  2. Add the sample files

    Select Use sample files in the drop zone. Three files appear in the Files panel, and each one moves from Validating to Hashing to Ready:

    FileDetected asSizeDetail
    09_58_12.ulgPX4 ULog, version 158.9 MBPX4 v1.15.4 on PX4_FMU_V6X, sys_id 4
    d04-orin-journal.jsonjournalctl JSON export3.9 MB5 units on the allowlist, boot 9b2e4c1d
    d04-orin-samples.jsonlCollector JSONL2.2 MBperception_node and mavlink-routerd at 1 Hz

    Validation looks inside each file. A flight log must open with the ULog magic bytes 55 4C 6F 67 01 12 35. No file may exceed the per-file limit, which is 250 MB unless an admin has raised it.

    Once a file is hashed, its row adds a shortened SHA-256: the first 12 and last 4 hex digits. Files of your own also read computed in your browser, because a manual upload is hashed before it leaves your machine.

  3. Check the run details

    The Files panel header reads Start time comes from the flight log. Select Run details at the top right of the page. Foxborne has already read the vehicle from the flight log: Vehicle reads UAS-04 with the hint Detected UAS-04 from sys_id 4 in the flight log, because the log's MAVLink system ID matches that vehicle.

    Type a Run label you will recognize in the runs list. Under Where the files go, the drawer adds that flight logs contain positions, and exported reports remove them unless the exporter turns them back on.

  4. Import the files

    Select Import 3 files in the drawer's footer, or the same button at the top right of the page. Foxborne creates the run under the next run number, confirms with a message such as Importing 3 files as R-0937 and opens the run's page.

Follow the run through parsing#

  1. Watch the import job

    While the run parses, a Parsing panel shows the current step and a percentage. The steps always run in the same order: Validating type, size and schema, Hashing originals and Parsing the flight log. Then come Parsing journal and samples, Aligning clocks and Running rules.

    When the job finishes, the Import chip reads Complete and the Clock chip shows the widest bound between two sources, Aligned ±46 ms. Import job, at the top right of the run page, then opens each step with its time, under a subtitle that states the rule: "Deterministic. The same files and parser versions give the same event IDs."

  2. Read the source files

    The Source files panel lists each original with its clock, anchor, bound, SHA-256 and parser version. Its subtitle, "Manual upload. Hashed on arrival and stored unmodified.", says how the files came in and what Foxborne did with them.

    SourceClockAnchorBoundParser
    Flight logPX4 boot timeGPS time from sensor_gps±40 msulog 0.9.2
    Companion journalCompanion wall clockchrony, synchronised±6 msjournal 0.6.0
    Process samplesCompanion monotonic, same boot as journalShared boot ID±6 msagent 0.8.1

    The copy button beside each shortened hash copies the full SHA-256, so you can check it against the file you hold. Values are from the example dataset.

  3. Check the ordering bounds

    Ordering bounds between sources is a matrix of every pair of files, under the subtitle "Two events closer than this cannot be put in order." For these files it reads:

    Flight logJournalProcesses
    Flight log±46 ms±46 ms
    Journal±46 msSame clock
    Processes±46 msSame clock

    The journal and the process samples share the companion clock, so their events are always in order. Against the flight log, two events must be more than 46 ms apart, 40 plus 6, before Foxborne says which came first.

Read an incident#

INC-0142 in the example dataset sits on another run, R-0931: the return leg of a Q4 recon quad, UAS-04, on Route Iron. An investigator opened the incident on the window 14:31:53 to 14:32:16 UTC, where the rules had produced six findings.

  1. Open INC-0142

    Select Incidents in the sidebar. The list opens on Active, every incident that is not closed. Type 0142 in Filter by title, vehicle or ID, then select Telemetry gap after perception.service was killed.

    The header shows the status, In review. The context strip gives the platform, the place, the run, the 23 s incident window and the clock, Aligned ±46 ms across 4 sources.

  2. Find the pair whose order is unknown

    Above the timeline, the clock note reads All 4 sources are on one timeline. It gives the widest bound between two sources, ±46 ms, and counts the pairs of events closer than their combined clock error.

    Select Show the first pair. The timeline zooms in on the last obstacle_distance sample in the flight log and the kernel's kill in the companion journal. It hatches the stretch where their intervals overlap and labels it Order unknown.

    The evidence inspector opens on Last obstacle_distance sample before a 7.5 s stall. Under Order against nearby events, the kill reads Order unknown: 39 ms apart, inside ±46 ms combined. The exit of perception.service, 54 ms after the sample, clears the bound and reads 54 ms later.

  3. Inspect the kernel kill

    In that list, select Kernel killed perception_node (out of memory). When gives 14:32:04.118 ±6 ms, on the companion wall clock with a chrony offset of −1.8 ms. Source gives the file (uas04-orin-journal.json), the journal line, the SHA-256 and the parser, and Original record shows the entry exactly as exported.

    Select Open event for the full event page. Kernel report lays out the kernel's out-of-memory report: which thread asked, what was killed and how much it held.

    Unit history lists what systemd logged for the units involved. It also says what the journal cannot show: "The journal records the order; it does not record why the router unit stopped."

    Press ← or → to step to the previous or next event.

  4. Read the report

    Open the Report tab. It reads like the page it becomes: the marking and designation indicator, the incident's details and six numbered sections.

    • 1 Finding is the investigator's paragraph, marked Hypothesis: the router unit may be bound to the perception unit. It ends "The binding is a hypothesis until the unit files are checked."
    • 2 Sequence walks through eight events. E2 and E3, the sample and the kill, read Order unknown. E2's note says "Order against E3 is unknown: 39 ms apart, inside ±46 ms combined."
    • The telemetry gap, E6, reads Correlated: "Due 0.76 s after mavlink-router.service stopped. Bound ±0.43 s including link latency."
    • 3 Evidence quotes each event with its file, location, SHA-256, parser and event ID.
    • 4 Limitations, 5 Open questions and 6 Next check say what the evidence cannot settle and which test would.

    Select Review and history at the top right. In the drawer, Before you export confirms that every sequence line cites its source and that no order is claimed inside a clock bound. It also warns that two questions are still open.

  5. Export the case file

    Select Export in the incident header, or Export case file at the foot of the Review and history drawer. The Export INC-0142 dialog opens with PDF case file with CUI markings ticked, at class L1, and the Exports bucket as its destination.

    Approval reads "No approval needed. L1 stays inside the enclave." It also says whether the case file carries the reviewer's sign-off: INC-0142's report is still in review, so its pages are stamped DRAFT. Remove coordinates follows your redaction policy, and Marking shows the banner and designation the pages will carry.

    Select Export. The toast names the export ID and its manifest hash, and the export is recorded in the incident's Activity tab, the delivery ledger and the audit log.

What you have now#

  • A run built from three hashed originals, with each file's clock, bound and parser version on record.
  • A pair of events Foxborne will not order, 39 ms apart inside 46 ms, and a pair it will, 0.76 s apart against 0.43 s.
  • A case file, hashed and listed in the delivery ledger, that another engineer can check against the originals.

Next#