How we hardened ZeroLabs visual runtime provenance gates

Last updated: 2026-04-02 · Tested against ZeroContentPipeline v0.2.0

What changed in the workflow owner?

This pass stayed inside ZeroContentPipeline. ZeroCreative still handles rendering and generation, while the pipeline now records more of the handoff before anything is uploaded to ZeroLabs.

The main change was treating runtime-backed assets as first-class records instead of generic files. When a creative result is registered now, the manifest can keep fields such as job_kind, job_id, correlation_id, publish_candidate, engine, provider_model_id, normalized, and expires_at.

We also added visual-policy gates for deprecated code_image_render, conceptual-only proof states, raw-only image-generation output, missing creative provenance, and invalid terminal recording provenance.

runtime_fields = {
    "source_kind": "creative_runtime",
    "job_kind": job_kind,
    "job_id": str(job_payload.get("job_id") or "").strip(),
    "correlation_id": str(job_payload.get("correlation_id") or "").strip(),
    "runtime_artifacts": runtime_artifacts,
    "publish_candidate": bool(primary_descriptor.get("publish_candidate", True)),
}

Why do raw and normalized image assets need separate treatment?

The current Google Gemini image-generation documentation describes image generation controls such as aspect ratio and image size, but it does not describe a native WebP output switch for the preview model used here (Google Gemini image generation docs). In this workflow, ZeroCreative returns provider output and the pipeline registers the normalized publish asset separately.

The conceptual illustration asset registered with normalized: true, while the raw support artifact remained attached under runtime_artifacts with a TTL-backed expires_at value.

For terminal capture, the workflow expects capture_runtime: asciinema when a terminal proof asset is present. That lines up with the asciinema CLI model for recording terminal sessions into .cast files (asciinema CLI manual).

What did the live verification run demonstrate?

The publish-path check for this post used three article visuals: a rendered diagram, a deterministic snippet export, and a conceptual illustration. The conceptual illustration came back from the live runtime as job-35d77a6f05a1, and the registered asset kept job_id, correlation_id, engine, provider_model_id, normalized: true, and the raw runtime artifact with expires_at.

That is the practical point of this hardening phase. The review and publish steps can now look at a real asset record and decide whether it is a truthful publish candidate or only a support artifact.

Final takeaway

The important change is not a new renderer. It is a stricter contract between the workflow owner and the runtime.

When the pipeline can distinguish placeholders, conceptual images, snippet exports, proof captures, raw provider artifacts, and normalized publish assets, the publish gate can make a more informed decision about what reaches the final post.

Want the broader context behind these hardening passes? Read more in Maintenance Mode or browse the library in Resources.