diff --git a/docs/appnotes/0011-c2pa.md b/docs/appnotes/0011-c2pa.md
index d38f505e..6b7c6e80 100644
--- a/docs/appnotes/0011-c2pa.md
+++ b/docs/appnotes/0011-c2pa.md
@@ -7,9 +7,8 @@ It uses certificates, cryptographic hashes, digital signatures and a tree of lin
 However, as C2PA's hashing mechanism is intentionally brittle, and currently reliant on the container format, it is not obvious to imagine how to preserve provenance data across workflows involving TAMS.
 Here we will examine some best practices for ingesting and exporting media from TAMS to allow clients to propagate and re-sign provenance without significant data loss.
 
-This note is an initial recommendation on how to work with C2PA in TAMS.
+This note is an initial recommendation on how to work with C2PA in TAMS for both file-based and live streams.
 Implementors are encouraged to feedback and contribute to the recommendation as the workflows and standards develop.
-Notably, it is focussed on file-based Flows and Sources, awaiting further live stream container support in C2PA.
 
 ## Trust Principles
 
@@ -30,7 +29,7 @@ There are a number of ways to handle this, some options are:
 2. The signing organisation works out-of-band with the external organisations to establish their own expectations and trust, and then signs the whole workflow themselves, assuming all the risk
 3. The signing organisation makes a decision to only sign workflows that are in their control, excluding workflows where external organisations are present
 
-## Workflow
+## File-based Workflow
 
 Here's an example workflow to help us understand where C2PA validation and signing can happen.
 
@@ -82,7 +81,7 @@ Fig 2 - Ingest process
 As part of that upload process, the multi-essence Flow being created should be tagged with `c2pa-provenance: embedded`, to ensure the provenance can be found later at export-time.
 
 Alternatively, depending on workflow and performance constraints, the C2PA manifest can be copied out of the file, and subsequently uploaded to TAMS as a child collected data Flow, with a `role` of `c2pa`, and an `essence_parameters/data_type` value of `application/c2pa` and a `format` value of `urn:x-nmos:format:data`.
-If this is done, the multi-essence Flow's tag should instead be c2pa-provenance: detached.
+If this is done, the multi-essence Flow's tag should instead be `c2pa-provenance: detached`.
 
 ```mermaid
   flowchart LR;
@@ -160,3 +159,140 @@ The resulting file can optionally be re-imported into TAMS as a multi-essence Fl
 Fig 4 - Export / Publishing process
 
 Finally, in our example workflow the file is published to a social media platform, which depending on their support, may render provenance user interface for users, allowing them to inspect the secure provenance history.
+
+## Live Workflow
+
+Live workflows require TAMS 8.2 or later, which supports Init Objects on Flow Segments. The current version of the C2PA specification applies to content packaged using the ISO BMFF standard (including CMAF). It does not support MPEG Transport Streams.
+
+The C2PA specification defines two different methods for segment-based validation. This recommendation uses the 'Per-segment C2PA Manifest Box' method, described in [C2PA Section 19.3](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#using_c2pa_manifest_box). This choice minimises the creation of new init segments - over-use of init segments in TAMS workflows may result in un-needed re-initialisation of decoders which may adversely affect performance and/or playback. It is also straightforward to map to TAMS because every media segment is independently signed, at the cost of carrying a C2PA manifest in every segment.
+
+We may consider adding a recommendation for the 'Verifiable Segment Info' method described in [C2PA Section 19.4](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#verifiable_segment_info) at a later date.
+
+### Per-Segment Signing
+
+For live video, every media segment should contain a C2PA Manifest Store in a top-level [C2PA `uuid` box](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#uuid_box). Its active manifest contains:
+
+* A `c2pa.hash.bmff.v3` assertion that covers the bytes of that segment
+  * Apply the C2PA BMFF exclusion rules, including exclusion of the C2PA `uuid` box itself
+* A `c2pa.livevideo.segment` assertion
+  * A monotonically increasing `sequenceNumber` that provides a unique identifier for the segment. Increasing by exactly one is recommended to simplify loss and replay detection
+  * A `streamId` that provides a unique identifier for the entire video stream. This value can be any string that uniquely identifies the stream, such as a UUID. Persist an association between that value and the TAMS Flow
+  * A `continuityMethod` which indicates the method used to ensure continuity between segments. This should be set to `c2pa.manifestId`
+  * A `previousManifestId` set to the active C2PA manifest identifier of the preceding segment
+* (optionally) Any other assertions relevant to that segment
+
+An example `c2pa.livevideo.segment` :
+
+```
+{
+  "sequenceNumber": 175,
+  "streamId": "123e4567-e89b-12d3-a456-426614174000",
+  "continuityMethod": "c2pa.manifestId",
+  "previousManifestId": "urn:c2pa:F9168C5E-CEB2-4FAA-B6BF-329BF39FA1E4"
+}
+```
+
+Signing must be the final operation that changes the media segment. Store and later validate the exact signed bytes; concatenating, remuxing or otherwise rewriting them creates a different C2PA asset.
+
+### TAMS Representation
+
+The corresponding TAMS representation is one mono-essence video Flow. Each signed media segment is stored unchanged as one Media Object and placed on the Flow timeline by one Flow Segment. The Flow Segment's `object_id` identifies the Media Object; C2PA continuity is carried inside the Media Objects and is independent of the TAMS timeline.
+
+* `container` set to `video/mp4`
+* `essence_parameters.init_segments` set to `true`
+* each init segment stored as an Init Object
+* each Flow Segment's `init_object_id` identifying the Init Object required to decode that media segment.
+* the same Init Object ID reused until the required init bytes change
+
+C2PA requires any init segment to contain its own C2PA `uuid` box, with a BMFF hash that includes the `moov` box to create a cryptographic relationship between the init segment and the media segments. Create a new Init Object when those init bytes change, for example because decoder configuration changes. C2PA claim-signer rotation alone does not require a new init segment.
+
+```mermaid
+flowchart LR
+  initA[Init Object A]
+  initB[Init Object B]
+  seg0[Media Object 0<br/>C2PA manifest 0]
+  seg1[Media Object 1<br/>C2PA manifest 1]
+  seg2[Media Object 2<br/>C2PA manifest 2]
+  seg3[Media Object 3<br/>C2PA manifest 3]
+  initA --> seg0
+  initA --> seg1
+  initB --> seg2
+  initB --> seg3
+  seg0 -- previous manifest --> seg1
+  seg1 -- previous manifest --> seg2
+  seg2 -- previous manifest --> seg3
+```
+
+The solid arrows are TAMS references. The dotted arrow is the C2PA continuity link embedded in the next Media Object.
+
+An Init Object change does not itself start or end a C2PA live stream. If the claim-signing certificate or signing service changes, continue the same `streamId`, sequence and `previousManifestId` chain, and validate the new signer under normal trust policy. A signer change is not a continuity break.
+
+### Writing to TAMS
+
+Follow this procedure, together with the general storage workflow in [Application Note 0024](https://github.com/bbc/tams/blob/main/docs/appnotes/0024-using-init-segments.md):
+
+1. Create a mono-essence video Flow with `container: video/mp4` and tag it with `c2pa-provenance: embedded` as a discovery hint. Set `essence_parameters.init_segments` to `true`.
+2. Start the C2PA signing state with a new `streamId`, initial sequence number and signer. 
+3. C2PA-sign init segments, allocate storage and upload as Init Objects. Supply `content-type` during allocation only when required by the TAMS storage API, as described in Application Note 0024. Retain the returned Object ID.
+4. For each media segment, generate and sign its final bytes, allocate a Media Object without overriding its content type, and upload those exact bytes using the allocated URL and content type.
+5. Register one Flow Segment with the Media Object ID and exact Flow `timerange`. Include the current `init_object_id`.
+6. Reuse that Init Object ID for subsequent Flow Segments. Upload and select a new Init Object before registering the first media segment that requires changed init bytes.
+
+A simplified example Flow Segment registration:
+
+```json
+{
+  "object_id": "media-object-id",
+  "timerange": "[1700000000:0_1700000002:0)",
+  "init_object_id": "init-object-id"
+}
+```
+
+When `init_segments` is true, every media Flow Segment must identify an Init Object. A successful upload does not place an Object on the Flow timeline; the Flow Segment registration does that. Conversely, the registration and its timerange are TAMS metadata and are not authenticated by the embedded C2PA manifest.
+
+### Reading and Validation
+
+A reader validates three separate things: the TAMS representation, each C2PA asset, and continuity between C2PA assets. Validation is stateful even though every media Object is independently signed:
+
+1. Request all Flow Segments covering the desired timerange, following TAMS pagination, and process them in ascending Flow timerange order.
+2. Check Flow timeranges for gaps and overlaps according to application policy. When `init_object_id` changes, fetch that Init Object, validate its C2PA manifest and binding, and initialise the decoder before processing the referencing media segment.
+3. Download each Media Object without concatenating, remuxing, or rewriting it. Apply normal C2PA manifest, signature, credential, assertion and `c2pa.hash.bmff.v3` validation to those exact bytes.
+4. For each media segment after the first one observed, check that `streamId` is unchanged, `sequenceNumber` increases as required, and `previousManifestId` exactly matches the preceding media segment's active manifest identifier.
+5. Report TAMS mapping, C2PA validity, C2PA continuity and signer trust separately. A correctly signed Object can be on the wrong TAMS timerange, and a valid signature from an untrusted credential is not a trusted result.
+
+A media segment may have a valid signature and hard binding while continuity from the intended start of the stream is unproven. This occurs, for example, when validation begins mid-stream and the predecessor is unavailable. The reader should report the segment-level result and the chain-anchoring result separately.
+
+Once a validation failure occurs in a linear playback session, later valid segments do not erase it. The client should retain and expose the failure until an explicit discontinuity, seek, or new validation session establishes a new policy boundary.
+
+### Long-Running Flows
+
+The recommendations in [Application Note 0010](https://github.com/bbc/tams/blob/main/docs/appnotes/0010-long-running-sources-and-flows.md) apply to live C2PA Flows. A validator that follows a growing Flow should persist at least:
+
+* the Flow ID and last validated timerange
+* the `streamId` and last accepted `sequenceNumber`
+* the last active manifest identifier
+* the current Init Object ID
+* the signer and trust result needed by local policy
+
+On restart, recover enough preceding state to validate the next segment's predecessor link. If that state cannot be recovered, report an unanchored restart instead of inventing continuity. Handle pagination, retention windows, late registration, duplicate delivery, and concurrent reads explicitly.
+
+For an intentionally never-ending service, operational policy also needs to cover certificate renewal, revocation checks, time-stamping, monitoring, checkpoint durability, and what constitutes an announced discontinuity. These are deployment concerns beyond merely passing the C2PA wire-format checks.
+
+## Implementation Evidence and Limits
+
+The live recommendation was exercised in an experimental implementation using CMAF-compatible H.264 video, the C2PA Rust SDK implementation from experimental pull request 2562 pinned at commit `8d44625e23794491b312b3984ec49a1b58234a62`, and a TAMS 8.2 service.
+
+This evidence is sufficient for the scoped informative recommendation, but it is not a production interoperability claim. The following remain future work:
+
+* audio and muxed multi-track media
+* adaptive bitrate ladders and switching between renditions
+* the Section 19.4 Verifiable Segment Info and session-key method
+
+## References
+
+* [C2PA Technical Specification, Section 19: Live Video](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html#live-video)
+* [TAMS Application Note 0003: Tag names](https://github.com/bbc/tams/blob/main/docs/appnotes/0003-tag-names.md)
+* [TAMS Application Note 0010: Long-running Sources and Flows](https://github.com/bbc/tams/blob/main/docs/appnotes/0010-long-running-sources-and-flows.md)
+* [TAMS Application Note 0021: Media integrity](https://github.com/bbc/tams/blob/main/docs/appnotes/0021-media-integrity.md)
+* [TAMS Application Note 0024: Using media with initialisation segments](https://github.com/bbc/tams/blob/main/docs/appnotes/0024-using-init-segments.md)
+* [TAMS API documentation](https://bbc.github.io/tams/main/)
\ No newline at end of file