EPM v1.0 Use Cases

This document is informative. It does not define conformance requirements.

1. Document Write/Read Workflow

A producer system generates a structured payload and embeds it in a PDF using EPM v1.0. A consumer system later discovers the embedded EPM, validates it against the wrapper schema and any declared payload contract, and extracts the payload for downstream use.

EPM v1.0 supports contract enforcement at the payload level. A producer may declare a payload.schema.id pointing to a JSON Schema or other contract definition. A consumer that supports contract validation can apply that contract to the extracted payload before accepting it.

This is the baseline EPM workflow: one PDF, one structured payload, one manifest. The payload and its host document move together as a single file without requiring a separate sidecar.

2. Multi-EPM Discovery and Selection

A single PDF may contain more than one EPM, each with a distinct manifest_id. A consumer discovers all embedded EPM candidates, builds an index of their discovery fields (manifest_id, payload.type, payload.doc_type, payload.schema.id), and selects the target manifest by manifest_id.

If two or more candidates share the same manifest_id, that condition SHOULD be surfaced as a conflict. Valid candidates with distinct identifiers remain accessible regardless of whether other candidates are invalid or conflicting.

This use case covers multi-payload PDFs, versioned payload replacements, and workflows that embed EPMs from more than one producer.

3. Mixed Candidate Behavior

In practice, a PDF may contain EPMs, invalid EPM-like JSON attachments, and unrelated non-EPM embeds such as images or other document types. A conforming consumer MUST NOT treat the presence of invalid or non-EPM candidates as a PDF-level failure.

The expected behavior is per-candidate: valid EPMs are discoverable and selectable; invalid candidates are reported with per-candidate error details; non-EPM embeds are ignored or surfaced as non-EPM candidates. No single bad candidate blocks access to the valid ones.

4. BI-Assisted Reconstruction Workflow

In some environments, a legacy PDF may not already contain structured data. A BI-assisted workflow can attempt to reconstruct structured data from the PDF, after which a human reviewer compares the extracted structure against the document and corrects errors.

Once verified, the structured payload can be embedded with the PDF using EPM v1.0. The resulting document becomes more useful for downstream extraction, indexing, or analytics workflows.

This workflow is an example of EPM v1.0 extensibility. It is not part of the EPM v1.0 conformance model.

5. Payload Size Considerations

Implementations should consider payload size carefully.

Small text-based structured payloads are usually a modest overhead. Large embedded payloads that duplicate images, video, or other rich media may cause significant document growth.

Where appropriate, a payload schema and its producer or consumer may establish separate conventions for referencing existing embedded content in the document rather than duplicating that content inside the payload. Such conventions are outside the scope of EPM v1.0 unless later standardized.