@giveitsmaller/contracts 0.70.0 → 0.73.0

package/availability/availability.json

@@ -1,6 +1,6 @@
 {
   "capabilities_profile": "baseline",
-  "capabilities_version": 185,
+  "capabilities_version": 190,
   "endpoints": {
     "DELETE /api/auth/account": {
       "auth": "required",
@@ -526,8 +526,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -690,8 +689,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -718,9 +716,9 @@
       "sole_op": true
     },
     "audio_to_video": {
-      "availability": "stable",
+      "availability": "planned",
       "default": false,
-      "description": "Produce a video from an audio input plus an OPTIONAL still image\noverlay. Use cases: podcast \u2192 YouTube uploads, audio-only tracks\nthat need a video container for platforms requiring it, branded\naudio releases with a static cover image.\n\n**Role asymmetry.** First role-based operation on the contract\nwith an OPTIONAL role \u2014 REQUIRED `base` (audio source) +\nOPTIONAL `overlay` (still image, 0..1). When `overlay` is\nomitted, the video uses a solid `background_color`. The\nmachine-readable cardinality lives in `per_role_cardinality`\non this schema.\n\n**Input vs output asymmetry.** The single `mime_groups.audio`\nblock keys the INPUT MIME family (the `base` role input is\naudio). The OUTPUT is always video \u2014 `output_format` controls\nthe container; `mime_groups` is NOT the output type. Mirrors\nthe `audio_overlay.video` group pattern (input-keyed).\n\nRe-encode required (audio \u2192 video composition always re-encodes).\nA lower framerate plus still-image tuning keeps file size tiny\nwhen the overlay is a still image (the common case).\n\nActivated to `availability: beta`: the backend is live (API\naccepts + publishes), so this is shape-stable + opt-in for callers\nand MUST NOT return `feature_not_available` \u2014 it may still change\nwith notice while beta.\n",
+      "description": "Produce a video from an audio input plus an OPTIONAL still image\noverlay. Use cases: podcast \u2192 YouTube uploads, audio-only tracks\nthat need a video container for platforms requiring it, branded\naudio releases with a static cover image.\n\n**Role asymmetry.** First role-based operation on the contract\nwith an OPTIONAL role \u2014 REQUIRED `base` (audio source) +\nOPTIONAL `overlay` (still image, 0..1). When `overlay` is\nomitted, the video uses a solid `background_color`. The\nmachine-readable cardinality lives in `per_role_cardinality`\non this schema.\n\n**Input vs output asymmetry.** The single `mime_groups.audio`\nblock keys the INPUT MIME family (the `base` role input is\naudio). The OUTPUT is always video \u2014 `output_format` controls\nthe container; `mime_groups` is NOT the output type. Mirrors\nthe `audio_overlay.video` group pattern (input-keyed).\n\nRe-encode required (audio \u2192 video composition always re-encodes).\nA lower framerate plus still-image tuning keeps file size tiny\nwhen the overlay is a still image (the common case).\n\n`availability: planned` \u2014 withdrawn 2026-09-15. Measured encode cost is\n0.300 s per second of output PLUS A 7 s FIXED COST, so the advertised PT2H\nneeds 2167 s against a 900 s platform maximum. \u26a0\ufe0f The 7 s is not a rounding\ndetail: 0.300 x 7200 alone is 2160, and a consumer dividing 600 by 0.300\nderives a 2000 s in-flight boundary where the real one is ~1976 s. Workflow-create returns `feature_not_available` (422).\n\n\u26a0\ufe0f An already-accepted workflow is NOT cancelled \u2014 availability is checked at\ncreate \u2014 and it is NOT thereby doomed. \u26d4 DO NOT READ THIS AS \"in-flight work\nfails\": the 60 s and 120 s cells behind this withdrawal both COMPLETED WITH\nOUTPUT, which is precisely why the evidence is arithmetic rather than a kill.\nWhat fails is an accepted workflow whose OUTPUT DURATION exceeds ~1976 s\n\u26a0\ufe0f ON THE INPUT THE RATE WAS MEASURED WITH \u2014 a real photographic 1080p STILL\nplus looped real audio \u2014 the point at which 0.300 s/s plus the 7 s fixed cost\nreaches the 600 s cap. \u26d4 THE DRIVER IS THE STILL'S RESOLUTION, NOT THE\nDURATION ALONE: a 4K still is roughly 4x the rate (recorded as UNMEASURED),\nwhich would put the boundary near a quarter of that figure, and this schema\nplaces NO constraint on the overlay's resolution. Other still resolutions and\nother output settings are likewise unmeasured, and the contract does not\nclaim which direction they move \u2014\nand what the caller then sees is NOT SETTLED \u2014 see the CHANGELOG entry for\n2.203.0; this contract does not pin a worker's error classification. Measured figures and the conditions for re-listing are in the\nCHANGELOG entry for 2.203.0 \u2014 the only one of the two records that is\nPUBLISHED (`schemas/manifest-divergence-register.yaml` is working material\nfor the drift gate and is not in the npm tarball).\n",
       "input_model": "multi",
       "max_inputs": 2,
       "mime_groups": {
@@ -2125,8 +2123,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -2660,8 +2657,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -2678,7 +2674,7 @@
     "custom_luma": {
       "availability": "planned",
       "default": false,
-      "description": "Apply a caller-uploaded luma matte (transition-mask) over a base\nvideo to produce a custom luma-matte transition effect. Inspired\nby Cloudinary's deprecated luma-matte custom transitions and\nintended as a paid-tier (`pro`+) creative feature.\n\n**NOT** related to the `xfade=custom` expression-mode transition\nparameter. The `merge.transition.custom` value is tagged `planned`\nas an advisory that points callers at this dedicated operation for\ncaller-uploaded luma-matte transitions.\n\nMulti-input: exactly one input with `role: base` (the source\nvideo being transitioned) + exactly one input with\n`role: transition_mask` (the luma matte \u2014 a video whose pixel\nluminance drives the transition reveal \u2014 bright = revealed,\ndark = held). Each input is imported\nexternally, referenced from a vault connection, or an upstream\n`job_output` (uploads are NOT referenced directly inside inputs[]).\nAn uploaded base or mask enters via a `passthrough` source job\nreferenced by `{ type: job_output, from: <id> }` (per ticket\n4som89Uh).\n\n`planned` \u2014 not yet supported.\n",
+      "description": "Apply a caller-uploaded luma matte (transition-mask) over a base\nvideo to produce a custom luma-matte transition effect. Inspired\nby Cloudinary's deprecated luma-matte custom transitions and\nintended as a creative feature, metered by credits like every\nother operation (no tier gate \u2014 decision 26, 2026-09-23).\n\n**NOT** related to the `xfade=custom` expression-mode transition\nparameter. The `merge.transition.custom` value is tagged `planned`\nas an advisory that points callers at this dedicated operation for\ncaller-uploaded luma-matte transitions.\n\nMulti-input: exactly one input with `role: base` (the source\nvideo being transitioned) + exactly one input with\n`role: transition_mask` (the luma matte \u2014 a video whose pixel\nluminance drives the transition reveal \u2014 bright = revealed,\ndark = held). Each input is imported\nexternally, referenced from a vault connection, or an upstream\n`job_output` (uploads are NOT referenced directly inside inputs[]).\nAn uploaded base or mask enters via a `passthrough` source job\nreferenced by `{ type: job_output, from: <id> }` (per ticket\n4som89Uh).\n\n`planned` \u2014 not yet supported.\n",
       "input_model": "multi",
       "max_inputs": 2,
       "mime_groups": {
@@ -2738,8 +2734,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -2747,8 +2742,7 @@
                 "max_input_duration": "PT5M",
                 "max_input_size_bytes": 524288000,
                 "max_output_size_bytes": 524288000
-              },
-              "required_tier": "pro"
+              }
             }
           }
         }
@@ -2764,7 +2758,6 @@
           "min": 1
         }
       },
-      "required_tier": "pro",
       "sole_op": true
     },
     "image_watermark": {
@@ -3788,8 +3781,7 @@
                 "max": {
                   "max_total_input_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form_concat": {
               "availability": "stable",
@@ -3912,6 +3904,7 @@
       "mime_groups": {
         "audio": {
           "availability": "beta",
+          "input_size_bound": "processing_time",
           "mimes": [
             "audio/mpeg",
             "audio/aac",
@@ -3973,7 +3966,7 @@
             },
             "precision": {
               "default": "fast",
-              "description": "Cut precision. Under `fast`, audio cuts are\npacket-boundary approximate (drift bounded by codec\npacket size \u2014 typically <= 23ms for AAC, <= 26ms for\nMP3). Under `exact`, the server re-encodes to align cuts\nprecisely at the requested timestamps (slower, larger\noutput, but sample-accurate).\n",
+              "description": "Cut precision. Under `fast`, audio cuts are\npacket-boundary approximate (drift bounded by codec\npacket size \u2014 typically <= 23ms for AAC, <= 26ms for\nMP3). Under `exact`, the server re-encodes to align cuts\nprecisely at the requested timestamps (slower, larger\noutput, but sample-accurate).\n\n\ud83d\udd34 **THE TWO VALUES HAVE DIFFERENT DURATION LIMITS, AND ONLY\nONE OF THEM REFUSES.** This is stated here, on the option a\ncaller chooses, because the group declares\n`input_size_bound: processing_time` and no\n`max_input_duration` \u2014 there is no per-value constraint\nprimitive to carry it.\n\n\u26d4 **NEITHER VALUE GIVES A PRE-FLIGHT SIGNAL. BOTH FAIL AFTER\nTHE JOB IS ACCEPTED AND BILLED.** No duration ceiling is\ndeclared on this group, so the API cannot enforce one at\ncreate; the worker's own check reads a probe result, which\nmeans the input has already been uploaded, accepted and\ndownloaded.\n\n- **`exact`: refused when its computed time budget does not\n  fit** \u2014 but WORKER-SIDE, after download and probe. The job\n  returns a terminal `OperationResult` with `error_code:\n  invalid_options`. \u26a0\ufe0f It is NOT an HTTP 422 and it is not a\n  create-time rejection: a worker cannot emit a status code.\n  The boundary does not move with `count` \u2014 once the cap\n  binds, the per-output term stops mattering.\n- **`fast` (the default): no boundary and no refusal at\n  all.** Past the point where its deadline saturates, the time\n  budget stops growing while the work does, so the job fails\n  as a **TIMEOUT** rather than with any reason a caller can\n  act on.\n\n\ud83d\udd34 **TWO LIMITS EXIST AND THE SMALLER ONE BINDS.** The worker\ncarries an internal time budget and the Lambda function\ncarries a platform timeout; **the effective boundary is the\nLOWER of the two**, and the internal budget sits ABOVE the\nplatform timeout.\n\n\u21d2 **`exact`'s refusal threshold is calibrated to a limit that\nis not the one that ends the job.** Its check does fire, and\nfires early \u2014 it reads the probe result before any re-encode\nstarts, so a long-but-small input is refused within seconds.\nBut there is a band of inputs it judges FINE which the\nplatform then hard-kills mid-encode, with no named cause. **So\n`exact` refusing is a reliable signal; `exact` NOT refusing is\nnot a promise the job will finish.**\n\n\u26d4 **NO SECONDS FIGURE IS GIVEN HERE, DELIBERATELY.** v2.205.0\npublished figures keyed to the crate constant \u2014 the larger\nlimit, the one that does not bind. The effective number lands\nonly when that derivation settles AND a job is measured near\nit. **A published number a caller pre-validates against is\nworse wrong than absent**; the shape above is what a caller can\nactually act on today, which is: do not rely on either value\nfailing gracefully.\n\n\u21d2 `exact` at least names a cause when it is reached; `fast`\nnever does. **Both are the accept-then-bill-then-fail shape**,\nwhich is the very thing this group's `input_size_bound`\ndeclaration exists to stop happening silently on the BYTE\naxis. On the DURATION axis it is stated here and not yet\nfixed.\n\n\u26a0\ufe0f Read from `compression_lambdas` `crates/split`. **NOT\nmeasured** \u2014 their audio fixtures reach 145 s, a small\nfraction of any candidate cap, so this describes what the code\nwill do rather than observed behaviour at the boundary.\n",
               "type": "enum",
               "values": [
                 "fast",
@@ -4149,8 +4142,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "beta",
@@ -4812,8 +4804,7 @@
                 "max": {
                   "max_input_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "stable",
@@ -4963,8 +4954,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -4982,7 +4972,7 @@
     "video_text_watermark": {
       "availability": "planned",
       "default": false,
-      "description": "Render a text overlay onto a base video using bundled Liberation\nSans (SIL OFL). Single-input \u2014 the text and its styling come from\noptions, not from a file input.\n\n**Dedicated operation, not an extension of `text_watermark`.**\n`text_watermark` renders onto images (single-pass); per-frame video\ntext rendering requires a re-encode (overlay = pixel modification,\nno stream-copy escape). Different runtime.\n\n**Audio passthrough.** The base video's audio stream is preserved\nunchanged (stream-copied) \u2014 the watermark applies to the visual\ntrack only.\n\nTwo rendering modes (mirrors `text_watermark`):\n- `single`: one label rendered at the anchor + margin position.\n- `tiled`: text tiled across the source frames at the rotation\n  angle.\n\n`availability: planned` until the cross-repo backend support ships;\ndispatch returns `feature_not_available` (422) until then.\n",
+      "description": "Render a text overlay onto a base video using bundled Liberation\nSans (SIL OFL). Single-input \u2014 the text and its styling come from\noptions, not from a file input.\n\n**Dedicated operation, not an extension of `text_watermark`.**\n`text_watermark` renders onto images (single-pass); per-frame video\ntext rendering requires a re-encode (overlay = pixel modification,\nno stream-copy escape). Different runtime.\n\n**Audio passthrough.** The base video's audio stream is preserved\nunchanged (stream-copied) \u2014 the watermark applies to the visual\ntrack only.\n\nTwo rendering modes (mirrors `text_watermark`):\n- `single`: one label rendered at the anchor + margin position.\n- `tiled`: text tiled across the source frames at the rotation\n  angle.\n\n`availability: planned` \u2014 withdrawn 2026-09-15. A real 1080p source at the\nadvertised PT5M could not finish inside the worker's 600 s encode cap.\nWorkflow-create returns `feature_not_available` (422).\n\n\u26a0\ufe0f An already-accepted workflow is NOT cancelled \u2014 availability is checked at\ncreate \u2014 and it is NOT thereby doomed. \u26d4 The withdrawal rests on ONE measured\npoint: a 435 MB / 300 s real 1080p source KILLED at 604 s with no output.\nWork far enough inside the 600 s cap still completes, and NOTHING MEASURED\nSAYS WHERE THE BOUNDARY IS. What a caller sees when a job crosses it is NOT\nSETTLED \u2014 see the CHANGELOG entry for 2.203.0; this contract does not pin\na worker's error classification. Measured figures and the conditions for re-listing are in the\nCHANGELOG entry for 2.203.0 \u2014 the only one of the two records that is\nPUBLISHED (`schemas/manifest-divergence-register.yaml` is working material\nfor the drift gate and is not in the npm tarball).\n",
       "input_model": "single",
       "mime_groups": {
         "video": {
@@ -4993,7 +4983,7 @@
           "options": {
             "anchor": {
               "default": "bottom_right",
-              "description": "9-grid anchor position. For `watermark_mode: single`, the\ntext label is placed at this anchor + margin_x/margin_y\noffset on each frame. For `watermark_mode: tiled`, anchor\nis ignored (tiles fill the frame).\n",
+              "description": "9-grid anchor position. For `watermark_mode: single`, the\ntext label is placed at this anchor + margin_x/margin_y\noffset on each frame. For `watermark_mode: tiled`, anchor\nis ignored (tiles fill the frame).\n\n\ud83d\udd34 **`center` IGNORES `margin_x` / `margin_y` rather than\nrejecting them. THE REJECTION AS WRITTEN CANNOT SURVIVE A\nNON-ZERO DEFAULT; IGNORING IS THE REPLACEMENT THAT WAS CHOSEN.**\nThe sibling operations still reject a non-zero\nmargin at `anchor: center` as `invalid_options` (422), and\nthat rule is sound THERE because their margin default is\n`0px`: a client that materialises the default sends `0px`,\nwhich is not non-zero, so only a caller who actually asked\nfor an offset is ever refused.\n\n\u26d4 **Here the default is `2%`, and that makes the rejection\nrule unusable as written.** Schema-driven clients fill contract\ndefaults BEFORE sending, so a request with `anchor: center`\narrives carrying `margin_x: \"2%\"` whether the caller chose it\nor never mentioned margins at all. **After default\nmaterialisation an explicit value and a defaulted one are\nINDISTINGUISHABLE on the wire**, so a rejection cannot\nseparate the mistake it exists to catch from the overwhelming\nmajority of requests that simply accepted the default. It\nwould 422 almost every centred watermark.\n\n\u26a0\ufe0f **Rejection is not the only alternative, and this text does\nnot claim it was forced.** A reject-if-it-differs-from-the-\ndefault rule would survive materialisation exactly as the zero\nrule does for the siblings. **Ignoring is the behaviour CHOSEN**\nunder hub decision 465, because margins are meaningless when the\nlabel is centred and a no-op is kinder than a 422 on a request\nthat renders correctly. The cost is stated: a caller who\ndeliberately passes a margin with `anchor: center` gets silence\nrather than a correction.\n\n\u26a0\ufe0f **DO NOT \"align\" `text_watermark` or `image_watermark` to\nthis on the strength of the operation NAME.** Their rejection\nstill works because their default is still `0px`. Changing one\nof THOSE defaults to non-zero is what would force the same move\nthere \u2014 the trigger is a non-zero default, never the operation\nname. (`video_watermark` moved with this operation because its\ndefault moved too, under the same decision.)\n",
               "type": "enum",
               "values": [
                 "top_left",
@@ -5029,14 +5019,14 @@
               "type": "float"
             },
             "margin_x": {
-              "default": "0px",
-              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\").\nAnchor-relative. Ignored when `watermark_mode: tiled`.\n\n**`anchor: center` exception** (watermark_mode: single\nonly). Non-zero `margin_x` combined with `anchor: center`\nis rejected by the API at workflow-create time as\n`invalid_options` (HTTP 422).\n",
+              "default": "2%",
+              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\").\nAnchor-relative. Ignored when `watermark_mode: tiled`.\n\n**Defaults to `2%`, i.e. INSET from the frame edge**, because\na watermark flush against the edge is the wrong default for\nvideo: player chrome, safe-area cropping and letterboxing all\neat the outermost pixels. **A true flush remains available by\npassing `\"0px\"` explicitly** \u2014 the default is a default, not a\nfloor.\n\n**`anchor: center`: margins are IGNORED** (watermark_mode:\nsingle only). They are meaningless when the label is centred,\nand this is deliberately a silent no-op rather than a\nrejection. See the `anchor` description for why rejection is\nnot available here.\n",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "type": "string"
             },
             "margin_y": {
-              "default": "0px",
-              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Ignored when `watermark_mode: tiled`.\n\n**`anchor: center` exception** (watermark_mode: single\nonly). Same rejection rule as `margin_x`.\n",
+              "default": "2%",
+              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Ignored when `watermark_mode: tiled`.\n\n**Defaults to `2%` (inset), for the reasons on `margin_x`**;\n`\"0px\"` still gives a true flush. **`anchor: center`: ignored**,\nsame as `margin_x`.\n",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "type": "string"
             },
@@ -5095,8 +5085,7 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
               "availability": "planned",
@@ -5112,9 +5101,9 @@
       "sole_op": true
     },
     "video_watermark": {
-      "availability": "stable",
+      "availability": "planned",
       "default": false,
-      "description": "Apply an image overlay onto a base video\nasset. Multi-input role-based:\nexactly one input with `role: base` (the source video) + exactly\none with `role: overlay` (the watermark image). Each input is a\na multi-input source \u2014 an external_import handle, a vault connection,\nor an upstream `job_output` (uploads are NOT referenced directly\ninside inputs[]). To use an uploaded base or overlay, feed it through\na `passthrough` source job and reference it via `{ type: job_output,\nfrom: <id> }` (per ticket 4som89Uh).\n\n**Dedicated operation, not an extension of `image_watermark`.**\n`image_watermark` handles image-on-image overlay only.\n`video_watermark` requires an overlay + re-encode (no stream-copy escape \u2014 overlay = pixel modification).\n\n**Audio passthrough.** The base video's audio stream is preserved\nunchanged (stream-copied) \u2014 the watermark applies to the visual\ntrack only.\n\nActivated to `availability: beta` (Wave A, ticket\n[`c3uthIP4`](https://trello.com/c/c3uthIP4)): the cross-repo backend\nis live (API accepts + publishes via the operations SNS\ntopic), so the operation and its `short_form` processing class are\nshape-stable + opt-in and MUST NOT return `feature_not_available`.\n`long_form` stays `planned` (its long-form path is not yet\nprovisioned) and the `multi_overlay_stack` feature stays `planned`\n(backend support unconfirmed); requesting those planned sub-features\nDOES still return `feature_not_available` until they are separately\nactivated.\n",
+      "description": "Apply an image overlay onto a base video\nasset. Multi-input role-based:\nexactly one input with `role: base` (the source video) + exactly\none with `role: overlay` (the watermark image). Each input is a\na multi-input source \u2014 an external_import handle, a vault connection,\nor an upstream `job_output` (uploads are NOT referenced directly\ninside inputs[]). To use an uploaded base or overlay, feed it through\na `passthrough` source job and reference it via `{ type: job_output,\nfrom: <id> }` (per ticket 4som89Uh).\n\n**Dedicated operation, not an extension of `image_watermark`.**\n`image_watermark` handles image-on-image overlay only.\n`video_watermark` requires an overlay + re-encode (no stream-copy escape \u2014 overlay = pixel modification).\n\n**Audio passthrough.** The base video's audio stream is preserved\nunchanged (stream-copied) \u2014 the watermark applies to the visual\ntrack only.\n\n`availability: planned` \u2014 withdrawn 2026-09-15. A real 1080p source at the\nadvertised PT5M / 500 MB could not finish inside the worker's 600 s encode\ncap. Workflow-create returns `feature_not_available` (422).\n\n\u26a0\ufe0f An already-accepted workflow is NOT cancelled \u2014 availability is checked at\ncreate \u2014 and it is NOT thereby doomed. \u26d4 The withdrawal rests on ONE measured\npoint: the same source plus a PNG overlay, KILLED at 606 s with no output, on\n3008 MB \u2014 47% more memory than `video_text_watermark` and dead at the same\nsecond, which is what rules out resizing the function as the remedy. Work far\nenough inside the 600 s cap still completes, and NOTHING MEASURED SAYS WHERE\nTHE BOUNDARY IS. What a caller sees when a job crosses it is NOT\nSETTLED \u2014 see the CHANGELOG entry for 2.203.0; this contract does not pin\na worker's error classification. Measured figures and the conditions for re-listing are in the\nCHANGELOG entry for 2.203.0 \u2014 the only one of the two records that is\nPUBLISHED (`schemas/manifest-divergence-register.yaml` is working material\nfor the drift gate and is not in the npm tarball).\n",
       "features": {
         "multi_overlay_stack": {
           "availability": "planned",
@@ -5132,7 +5121,7 @@
           "options": {
             "anchor": {
               "default": "bottom_right",
-              "description": "9-grid anchor position on each video frame. Same vocabulary\nas `image_watermark.image` and `text_watermark.image`.\n",
+              "description": "9-grid anchor position on each video frame. Same vocabulary\nas `image_watermark.image` and `text_watermark.image`.\n\n\ud83d\udd34 **`center` IGNORES `margin_x` / `margin_y` rather than\nrejecting them. The rejection as written cannot survive a\nnon-zero default; ignoring is the replacement that was CHOSEN.\nThe trigger is the DEFAULT, not this operation.** Schema-driven\nclients materialise contract\ndefaults BEFORE sending, so with a non-zero default a centred\nrequest arrives carrying `margin_x: \"2%\"` whether the caller\nchose it or never mentioned margins. **After materialisation\nan explicit value and a defaulted one are indistinguishable on\nthe wire**, so the old `invalid_options` (422) rule would\nrefuse nearly every centred watermark.\n\n\u26a0\ufe0f Rejection is not the only alternative \u2014 a\nreject-if-it-differs-from-the-default rule would also survive\nmaterialisation. **Ignoring is the behaviour CHOSEN** under hub\ndecision 465, because margins are meaningless when the label is\ncentred. The cost is stated: a caller who deliberately passes a\nmargin with `anchor: center` gets silence, not a correction.\n\n\u26a0\ufe0f **The trigger is a NON-ZERO DEFAULT, never an operation\nname.** `image_watermark` and `text_watermark` keep their 422\nbecause their defaults are still `0px`, where a materialised\ndefault is not non-zero and only a deliberate offset is\nrefused.\n",
               "type": "enum",
               "values": [
                 "top_left",
@@ -5147,14 +5136,14 @@
               ]
             },
             "margin_x": {
-              "default": "0px",
-              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\"). Direction\nis anchor-relative \u2014 positive moves toward the frame\ncentre.\n\n**`anchor: center` exception.** When the anchor is `center`\nthe centre is the centre \u2014 there is no anchor-relative\ndirection. Non-zero `margin_x` combined with\n`anchor: center` is rejected by the API at workflow-create\ntime as `invalid_options` (HTTP 422). Same rule as the\nother watermark operations.\n",
+              "default": "2%",
+              "description": "Horizontal offset from the anchor as pixels (e.g. \"40px\")\nor percentage of video frame width (e.g. \"5%\"). Direction\nis anchor-relative \u2014 positive moves toward the frame\ncentre.\n\n**Defaults to `2%`, i.e. INSET from the frame edge**, because\na watermark flush against the edge is the wrong default for\nvideo: player chrome, safe-area cropping and letterboxing all\neat the outermost pixels. **A true flush remains available by\npassing `\"0px\"` explicitly.**\n\n**`anchor: center`: margins are IGNORED.** The centre is the\ncentre \u2014 there is no anchor-relative direction \u2014 so this is a\nsilent no-op rather than a rejection. See the `anchor`\ndescription for why a rejection is not usable with a non-zero\ndefault.\n",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "type": "string"
             },
             "margin_y": {
-              "default": "0px",
-              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Anchor-relative; positive moves toward\nthe frame centre.\n\n**`anchor: center` exception.** Same rejection rule as\n`margin_x`.\n",
+              "default": "2%",
+              "description": "Vertical offset from the anchor as pixels or percentage of\nvideo frame height. Anchor-relative; positive moves toward\nthe frame centre.\n\n**Defaults to `2%` (inset), for the reasons on `margin_x`**;\n`\"0px\"` still gives a true flush. **`anchor: center`: margins\nare IGNORED**, same as `margin_x`.\n",
               "pattern": "^\\d+(\\.\\d+)?(px|%)$",
               "type": "string"
             },
@@ -5188,11 +5177,10 @@
                   "max_input_size_bytes": 50000000000,
                   "max_output_size_bytes": 50000000000
                 }
-              },
-              "required_tier": "pro"
+              }
             },
             "short_form": {
-              "availability": "stable",
+              "availability": "planned",
               "constraints": {
                 "max_input_duration": "PT5M",
                 "max_input_size_bytes": 524288000,
@@ -5216,7 +5204,7 @@
       "sole_op": true
     }
   },
-  "schema_version": "2.201.0",
+  "schema_version": "2.208.0",
   "source_commit": null,
   "user_tier": null,
   "workflow_features": {