> ## Documentation Index
> Fetch the complete documentation index at: https://docs.samsa.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Content provenance

> How the Samsa API marks AI-generated and AI-modified images — C2PA signing, invisible watermarking, and the SVG scope-out — and how to verify a file.

Images the Samsa API produces are AI-generated or AI-modified content. This page
explains how those outputs are marked for provenance, how to verify a file, and the
one format the marking cannot cover.

<Info>
  Provenance marking of API outputs is being rolled out. The signing and
  watermarking pipeline is **dark-launched** — built and staged behind a flag — and
  applies to delivered raster files once it goes live. The behavior described here is
  the intended state at go-live; until the flag is flipped, API-delivered files are
  not yet marked.
</Info>

## What gets marked

Once provenance marking is live, every **raster** image the API delivers —
generation, Magic Edit, img2img, variations, resize, upscale, and background removal
— carries two markers:

* **A C2PA manifest.** An industry-standard, cryptographically signed Content
  Credentials record embedded in the file, stating that the image is AI-generated or
  AI-modified and how it was produced.
* **An invisible watermark.** A durable, imperceptible mark carried in the image
  itself, so provenance survives a screenshot or a metadata strip that would remove
  the C2PA manifest.

### AI-generated vs AI-modified

The provenance record reflects **how the image was produced**, derived from the
operation:

| Marker           | Operations                                                                                                      |
| ---------------- | --------------------------------------------------------------------------------------------------------------- |
| **AI-generated** | Image generation from a prompt (`POST /images/generations`)                                                     |
| **AI-modified**  | Operations that transform an input image — Magic Edit, img2img, variations, resize, upscale, background removal |

<Note>
  The visual EU AI Act marking a viewer sees is applied when an image is **downloaded
  in the Samsa app** — it is a presentation-layer label, and it is **not** applied to
  the files the API delivers. The API returns the asset with its embedded C2PA
  manifest and watermark; adding a visible on-image label for your own end users is
  your integration's choice.
</Note>

## Verifying a file

The C2PA manifest is readable with any standard Content Credentials tool — nothing
Samsa-specific is required:

* **Content Credentials Verify** — the web verifier at
  [contentcredentials.org/verify](https://contentcredentials.org/verify): drop in an
  image to inspect its manifest.
* **`c2patool`** — the open-source [C2PA command-line tool](https://github.com/contentauth/c2pa-rs)
  for reading and validating manifests in a pipeline.

Both report the manifest's claims and validate its signature, so you can confirm a
file's provenance independently of Samsa.

## SVG: an Art. 50(2) scope-out

[Vectorization](/api-reference/image-ops/vectorize) produces an **SVG**, which cannot
carry a C2PA manifest or an embedded watermark. SVG output is therefore a documented
**EU AI Act Art. 50(2) scope-out**: vector files are delivered **unsigned and
unwatermarked**.

Because that output cannot be marked, a vectorization request must acknowledge the
scope-out with `svg_acceptance: true`:

<Warning>
  The `svg_acceptance` acknowledgment is **disclosure / audit evidence, not a
  compliance waiver.** It records that the caller was told the SVG is delivered
  unmarked; it does not change the underlying marking duty, which remains the
  provider's and is qualified by technical feasibility.
</Warning>

Two independent gates apply, and both reject **before any credits are charged**:

| Gate              | Requirement                                                                                                                | Failure                                                             |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Acknowledgment    | `svg_acceptance` must be the literal boolean `true`                                                                        | [`422 svg_acceptance_required`](/api-reference/image-ops/vectorize) |
| Policy acceptance | Your organization has accepted the current ToS/AUP (verified server-side — the request flag is never trusted as this fact) | `403 svg_phase1_scope_out_required`                                 |

Accept the current Terms of Service and Acceptable Use Policy, then retry; the
server-verified acceptance record — not the request flag — is what unlocks delivery.

## See also

<CardGroup cols={2}>
  <Card title="Vectorization" icon="bezier-curve" href="/api-reference/image-ops/vectorize">
    The SVG operation and its `svg_acceptance` request contract.
  </Card>

  <Card title="Image operations" icon="wand-magic-sparkles" href="/api-reference/image-ops/overview">
    The six operations behind these outputs.
  </Card>

  <Card title="Errors" icon="triangle-exclamation" href="/guides/errors">
    The error envelope and status codes.
  </Card>

  <Card title="Pricing" icon="credit-card" href="/guides/pricing">
    What each operation costs.
  </Card>
</CardGroup>
