# Quickstart: reconstruct your first incident
URL: /get-started/quickstart
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.
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 [#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 [#import-three-sample-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.
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**:
| File | Detected as | Size | Detail |
| ------------------------ | ---------------------- | ------- | -------------------------------------------- |
| `09_58_12.ulg` | PX4 ULog, version 1 | 58.9 MB | PX4 v1.15.4 on PX4\_FMU\_V6X, sys\_id 4 |
| `d04-orin-journal.json` | journalctl JSON export | 3.9 MB | 5 units on the allowlist, boot 9b2e4c1d |
| `d04-orin-samples.jsonl` | Collector JSONL | 2.2 MB | perception\_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.
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.
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 [#follow-the-run-through-parsing]
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."
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.
| Source | Clock | Anchor | Bound | Parser |
| ----------------- | ----------------------------------------- | -------------------------- | ------ | --------------- |
| Flight log | PX4 boot time | GPS time from `sensor_gps` | ±40 ms | `ulog 0.9.2` |
| Companion journal | Companion wall clock | **chrony, synchronised** | ±6 ms | `journal 0.6.0` |
| Process samples | Companion monotonic, same boot as journal | Shared boot ID | ±6 ms | `agent 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.
**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 log | Journal | Processes |
| ---------- | ---------- | ---------- | ---------- |
| Flight log | | ±46 ms | ±46 ms |
| Journal | ±46 ms | | Same clock |
| Processes | ±46 ms | Same 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 [#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.
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.
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**.
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.
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.
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 [#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 [#next]
* [Read the timeline](/investigate/timeline) covers every lane, marker and control on the **Reconstruction** tab.
* [Alignment and event order](/concepts/alignment) works through both pairs in full.
* [Verify a report against the originals](/investigate/verify) shows how a reviewer checks each excerpt.
* [Import files in the console](/collect/import-files) covers your own files, limits and statuses.