Self-Describing Logs
Copper already records the application's version and Git provenance. Recovering that exact application is essential for resim and deterministic replay as you need the exact same binary to replay the stack anyway.
But rebuilding an old application is a lot of work when you only need to read its data. It can also be inconvenient to share a useful recording when you do not want to share the project's source code and history.
The new `cu29/self-describing-logs` feature embeds a versioned schema describing the payload encoding, field names, storage units (ie m.s⁻¹ etc.), and mission layouts. Generic readers can decode those recordings without the producing source or build. The log carries the decoding contract for its original data.
This preserves Copper's native recording path. The catalog is built at startup; ordinary recording continues to use native payload encoding, including on `no_std` targets.
`cu29-logextract` can inspect the catalog, export JSON, JSONL, or CSV, and perform deep validation. From its standard API, your python reader can return ordinary dictionaries without requiring registration of the producer's Rust payload types. That makes a recording much easier to use in a generic log management tool.
Data inspection and full application replay remain distinct operations but self-description makes the recorded payloads accessible.
Try the [self-describing log example](https://github.com/copper-project/copper-rs/tree/master/examples/cu_self_describing_logs) to see the catalog and generic readers in action.
Log Rollover
A useful recording system must fit the robot's storage budget. Copper 1.3 adds log rollover: keep recording within a fixed allocation, reclaiming older data sections while retaining application metadata and payload catalogs. Run selection lets you inspect a particular restart or mission run even when its startup data has rolled out.
Live twins also gain configurable receiver, replay, display, and archive budgets, including rollover for ground-station storage. Their archives preserve the sender's run and mission identity through late joins and rollover. A matching generated twin can also write a self-describing catalog.
That gives you a practical way to retain recent evidence onboard and archive it elsewhere, with the information needed to understand where the data came from.
## Try Copper 1.3
The [Copper 1.3 release notes](https://github.com/copper-project/copper-rs/wiki/Copper-Release-Notes) cover the complete changes and upgrade details. Start with the [PGS workflow](https://github.com/copper-project/copper-rs/blob/master/doc/profile-guided-scheduling.md), the [clock synchronization example](https://github.com/copper-project/copper-rs/tree/master/examples/cu_clock_sync), or the [self-describing logs example](https://github.com/copper-project/copper-rs/tree/master/examples/cu_self_describing_logs), depending on what you want to explore first.
