SMTasker

For platform-side transcoding, I would keep the approved input digest and the platform output as separate records: verify the exact bytes sent, then store the returned media/post ID and the checks performed on the published result. A re-encoded platform asset should not be expected to match the input hash. The schema version is already in the sample manifest. A production review record could also identify the preview artifact and renderer version. The conditional claim you describe is useful for selecting one worker, but recovery after a worker dies still needs its own policy. One JCS detail: RFC 8785 defines canonical serialization but explicitly preserves Unicode strings as-is; it does not normalize them. Any normalization policy should run before the preview and approval. These are extensions of the reference pattern, not claims about SMTasker's implementation.

For a background worker, I would keep two fields in the log: started_at_utc for correlating events across services, and elapsed_ms measured with a monotonic source inside the worker. A restart should start a new interval rather than reuse a saved raw monotonic reading. That keeps calendar scheduling and duration measurement explicit instead of mixing them in one timestamp.

A useful regression test would separate structural changes from element changes: add an item to the source list, then mutate a field on an object already in it. The first should leave a List.copyOf snapshot unchanged; the second exposes the shallow-copy boundary you describe. For a queued job, immutable element records matter just as much as the list wrapper.