Expose Microsoft InvisMark removal signal

docs/module-internals.md

@@ -399,7 +399,9 @@ decoder or registry entry. `com.microsoft.invismark.1` uses that value as the
 pixel-watermark identifier in Microsoft Paint output. An InvisMark soft binding
 keeps the invisible-removal gate fail-safe even when the C2PA asset binding has
 since become invalid, because metadata damage does not prove the pixel carrier
-disappeared. Content-fingerprint soft bindings do not trigger pixel regeneration.
+disappeared. `identify` retains the generic `soft_binding` signal for schema-1
+compatibility and adds `invismark` as the stable pixel-removal signal.
+Content-fingerprint soft bindings do not trigger pixel regeneration.
 
 The SDK default enables trust verification but supplies no production trust
 anchors. Consequently, an installation without an explicitly maintained C2PA

docs/python-api.md

@@ -233,6 +233,11 @@ the schema 1 serializer remains available for rolling upgrades. Asking a release
 an unsupported schema raises `ValueError` rather than silently returning another
 shape.
 
+Microsoft InvisMark declarations emit both the compatible generic `soft_binding`
+signal and the additive `invismark` signal. Consumers should use `invismark` to route
+the image through pixel removal; the generic signal also covers content fingerprints
+that must not trigger regeneration.
+
 A record carries metadata regions, not the primary coded-pixel stream: marker
 segments before the JPEG scan, every PNG chunk except `IDAT`, RIFF chunks except the
 coded image, the ISOBMFF provenance boxes, the container's trailer, the parsed EXIF tags the

docs/supported-signals.md

@@ -140,15 +140,17 @@ is still inconclusive.
 
 Microsoft Paint can name `com.microsoft.invismark.1` in a C2PA soft-binding
 assertion. Inspection reports both that exact algorithm and its signed `value`,
-which Paint uses as the identifier carried by the pixel watermark. Photos has a
-parallel local writer path, but no public output sample was available for this
-work. Metadata stripping removes the embedded manifest, not the pixel carrier.
-The project has no validated local InvisMark decoder. Microsoft's official
+which Paint uses as the identifier carried by the pixel watermark, and emits an
+additive `invismark` signal so callers can select pixel removal without parsing
+the generic `soft_binding` detail. Photos uses a parallel local writer path.
+Metadata stripping removes only the embedded manifest; `invisible` and `all`
+guarantee the supported InvisMark removal contract by regenerating the pixel
+layer as well. The project has no validated local InvisMark decoder, so local
+inspection cannot independently verify the output. Microsoft's official
 [Content Provenance Detection API](https://learn.microsoft.com/en-us/azure/ai-services/content-safety/how-to/how-to-provenance-detection)
 is the external oracle: it reports pixel `Watermark` and embedded `C2PA` results
-separately. The diffusion profiles have not been broadly certified against that
-oracle, so a control-positive, output-negative pair is still a per-file result,
-not a universal guarantee.
+separately; a control-positive, output-negative pair is the available per-file
+verification path.
 
 For MP4, MOV, and M4V, `video invisible` or the explicit
 `video all --invisible` option can regenerate the video through a VAE and strip