flightopsDocumentation
Reference: recording

Reduce a recorded-data failure

3 min readdocs/reference/recording-reduction.md (source repository)

The Standard flightops reduce-recording command selects one finalized catalog segment and shrinks surrounding time and dispensable topic groups while keeping the original fixed assertion windows intact. It requires current retention permission for the selected source and each upstream source, plus a configured bounded retention policy before publishing a protected result.

The command supports 1โ€“8 success bag_assert checks with explicit finite window.start_s and window.end_s. Choose one target check that fails; the other checks are fixed prerequisites and must pass. A target ERROR, missing topic, empty interval, failed prerequisite, changed evaluator or insufficient samples cannot count as the intended failure. Source code, launch configuration, event removal inside the oracle window, ROS replay, simulation and physical reproduction are not supported.

sh
flightops reduce-recording --database catalog.sqlite3 \
  --allow-source recording-segment:SEGMENT_ID plan SEGMENT_ID \
  --checks checks.json --expect-checks-digest FROZEN_CANONICAL_CHECKS_SHA256 \
  --target speed-limit --prerequisites prerequisites.json --snapshot snapshot.json \
  --t0-ns ORIGINAL_T0_NS -o reduction-plan.json

flightops reduce-recording --database catalog.sqlite3 \
  --allow-source recording-segment:SEGMENT_ID run reduction-plan.json \
  --expect-plan-digest FROZEN_PLAN_SHA256 -o new-reduction-directory

Repeat --allow-source for any required upstream source. The permission flags never override denied catalog source policy. The plan records canonical checks, normalized oracle parameters, the exact source SHA-256, configuration snapshot, supplied original t0, evaluator source/dependency identities, candidate specifications and budgets. Keep the expected plan digest independently from an imported plan. The snapshot, declared units, clock and prerequisite choices remain caller bindings; the tool does not infer or verify capture-time hardware configuration.

Prerequisites use flightops.replay-prerequisites/0. Required topics, recorded static-transform edges and warm-up history are supported. The source must cover the entire oracle window and warm-up. Every candidate keeps fixed-check topics, selected prerequisite topics, their warm-up messages and recorded static state through the selected end. Timestamps, schemas and original t0 are preserved. External resource files and live runtime prerequisites are explicitly unsupported here; missing recorded prerequisites refuse the trial. Declared clock provenance does not establish a shared sensor clock or a runtime mapping.

Plans contain at most 14 candidate reductions, with at most 16 total trials and 300 seconds. Defaults are 16 trials and 180 seconds. Each child process has a 30-second wall, 20-second CPU, 768 MiB address-space and 64 MiB output-file limit. Inputs are limited to 64 MiB, 250,000 messages and 256 topics. Candidate creation preserves 256 MiB free disk. The private source copy uses a held file descriptor, the finalized catalog digest and a retention read lease. No user command or ROS process is launched.

The new output directory contains the frozen plan and an atomic trial ledger. Every started, invalid, interrupted, uninteresting and unrun candidate remains visible. Permission is rechecked before and after each worker and before final publication. A failed or withdrawn publication deletes its MCAP and strips payload-derived trial details from the ledger. Ordinary source withdrawal after a completed export still requires the caller to remove its owned output; this command does not run a persistent output-file deletion service.

Candidates are ranked by actual bytes, then messages, with deterministic tie breaking. The exact final file is hashed before and after a fresh child evaluates it. Only a repeated target failure with passing prerequisites becomes status: reproduced. The final record includes an evidence receipt and source-policy derivation and an active retention dependency that protects its original segment within the configured pin budget. Release that derivative reference when its dependency is no longer needed using the final record's dependency_id; deleting the output file alone does not release it. Every owned output copy has its own dependency reference. Its stable artifact_id policy remains shared: a retry requires current permission for an existing derived artifact and never overwrites an earlier deny. An absent retention policy is checked before creating output lineage, so the same plan can be retried after configuring a budget.

The claim is smallest found among these recorded-data candidates and this budget. A successful offline numeric check does not establish global minimality, live initialization, measurement truth, root cause, physical behavior or safety.