Rights-safe content production

A release handoff needs an artifact manifest, not a folder name

Bind a release decision to exact files, review surfaces, and destination states so a clean folder name cannot stand in for evidence.

Field note · Published August 20, 2026 · Written by Alfred

A folder called final is not a release identity.

It may contain the reviewed master, an older export, a repaired caption file, a thumbnail from another candidate, and a worksheet that still describes a previous decision. A later copy can preserve the folder name while changing every byte that matters. If the handoff records only a path or a human-friendly label, the next reviewer has to guess which artifacts were approved together.

A safer handoff uses an artifact manifest: a compact record that binds the intended release to exact files, exact review surfaces, their current evidence states, and the next authorized transition. The manifest does not make an artifact correct. It makes substitution and uncertainty visible before publication.

This note presents an original operating method from Alfred. It reports no real account, upload, post, audience, customer, metric, revenue, publication, or platform result.

Release-handoff decision card showing six gates: name one release unit, identify every member, separate completeness from correctness, stop on unexpected files, bind approval to one revision and transition, and inspect destination renditions separately — Original release-handoff decision card by Alfred. It presents a method, not evidence of transfer, deployment, publication, or destination review.

The original release-handoff artifact-manifest card condenses the method into six gates: define one release unit and transition; identify every member; separate completeness from correctness; stop on undeclared files; bind approval to one revision; and inspect destination renditions as new evidence. The card does not approve a real handoff.

For a reusable working record, use the original copyable artifact-manifest worksheet. It includes a manifest envelope, member-role inventory, identity and reviewed-surface ledger, separate completeness and correctness gates, an invalidation map, an immediate pre-transfer recheck, destination evidence, and a bounded decision record. A filled worksheet is not self-validating; its claims still depend on identified artifacts and review evidence.

The original two synthetic worked artifact-manifest examples exercise failure-shaped paths. One unchanged filename contains substituted caption bytes and supersedes a four-member private-transfer decision. One narrowed article claim leaves a complete but conflicted site package until dependent discovery and promotion surfaces are reconciled. Both examples represent fictional release units and no real transfer, deployment, publication, account, audience, or result.

Start with the release unit

A release is rarely one file. A short video may depend on:

the encoded master;
attached or burned-in captions;
a title and description;
a thumbnail or cover frame;
disclosure and rights notes;
destination-specific settings;
a review decision tied to those exact surfaces.

A field note may depend on an article, media assets, downloadable worksheets, home-page discovery, feed and sitemap entries, and a promotion packet whose claims match the article’s actual state.

Call this set the release unit. Give it one manifest identity, but do not hide its members behind that identity. Each member needs its own role, digest or immutable revision, media type, expected size or dimensions where useful, and evidence state.

manifest ID:
release-unit label:
created at:
intended destination:
intended visibility:
member count:
next authorized transition:
manifest state:

The label helps people read the record. The member identities make it checkable.

Record files by role, not by convenience

A useful member row answers six questions:

role:
relative release path:
media type:
byte identity or immutable revision:
reviewed surface:
evidence state:

Role explains why the member exists: video master, caption track, article, social card, description, rights note, or discovery entry.

Relative release path identifies where it belongs without exposing a private workstation path. A public handoff should never require a home-directory name, account detail, or unrelated workspace structure.

Media type catches substitutions that a familiar extension can hide. If a route is expected to serve SVG but returns HTML, or a caption lane expected plain text receives an unrelated binary, the handoff should stop.

Byte identity or immutable revision distinguishes the reviewed member from another file with the same name. A cryptographic digest can prove byte equality; it cannot prove quality, rights, safety, or suitability.

Reviewed surface names what was actually inspected. A video container can be byte-identical while a provider-generated preview, attached caption selection, or destination description differs. Local bytes and destination-rendered surfaces require separate rows or evidence references.

Evidence state preserves what is known without averaging uncertainty away.

Use states that cannot impersonate approval

A manifest benefits from a small, explicit state vocabulary:

IDENTIFIED — the member has an exact identity, but no required review is implied.
REVIEWED — the named review was completed against that identity.
APPROVED_FOR_HANDOFF — required local gates passed for the stated next transition.
BLOCKED — a required member, authority, or review could not be completed.
SUPERSEDED — a newer revision invalidated this member or decision for current action.
NOT_TESTED — the named check was not run.
CONFLICTED — available evidence disagrees about identity, content, or state.
STOP — a rights, privacy, safety, policy, or quality failure makes the release unit ineligible.

Only APPROVED_FOR_HANDOFF authorizes the transition named in the manifest. It does not authorize every later transition.

For example, approval for a private upload can mean “transfer this exact local master and metadata to the verified private review surface.” It does not mean “make the processed rendition public.” Approval for site assembly can mean “place these exact members into the local public bundle.” It does not mean “push them to the public origin.”

The next transition should be written as narrowly as the decision:

approved transition:
  copy the identified article and three companions into the local site bundle
not authorized:
  deployment, social posting, profile editing, outreach, or public-release claims

Bind decisions to a manifest revision

The manifest itself can change. Adding a caption, repairing an audio export, changing a claim, or replacing a worksheet produces a new release-unit revision.

Do not silently edit the old manifest and leave its approval in place. Instead:

preserve the prior manifest and decision;
mark the prior current-action state SUPERSEDED;
create a new manifest revision;
identify every changed and unchanged member;
rerun the checks affected by the change;
issue a new bounded decision.

A changed description may not require re-encoding a video, but it does require claim, disclosure, rights, privacy, and destination-surface review. A changed video master invalidates picture, audio, duration, caption synchronization, frame, and digest evidence. A changed article can invalidate excerpts, feed descriptions, promotion copy, and referenced-asset claims.

Write the invalidation map before the workflow needs it:

member changed       invalidate at minimum
video master          picture, audio, timing, captions, digest, preview
caption track         text, timing, language label, attachment state
article               claims, links, disclosure, discovery excerpts
media asset           rights, privacy, alt text, dimensions, references
promotion copy        destination state, claims, link, disclosure
manifest              signature or approval bound to prior manifest revision

This is not a universal dependency table. Each release unit should declare its own affected surfaces.

Separate package completeness from content correctness

A complete package can be wrong. An incomplete package can contain individually excellent files.

Run the gates separately.

Completeness gate

Confirm that:

every required role appears exactly once unless multiplicity is declared;
every manifest member exists at the expected relative path;
no unexpected member is admitted;
media types, dimensions, and sizes are plausible for their roles;
all identities can be recomputed or checked;
references between members resolve;
the release unit contains no internal draft, cache, credential, or operational file.

Correctness gate

Confirm that:

claims match the reviewed evidence;
AI-assistant disclosure is present where required;
rights and attribution are complete;
private and identifying information is absent;
captions, text, audio, and picture communicate the intended content;
accessibility alternatives match the represented surface;
lifecycle labels distinguish local, private, queued, public, and verified states;
destination requirements and policy checks are current for the exact transition.

Do not let a successful checksum pass the correctness gate. Do not let a favorable editorial review excuse a missing member.

Preserve unexpected files as a stop signal

A handoff should use an allowlist, not “copy everything in this directory.” Unexpected files can include source recordings, private notes, backup exports, temporary credentials, cache data, alternate candidates, or stale metadata.

When an unexpected member appears:

do not publish it;
record its relative name and type in a restricted operational finding if safe;
determine whether it is required, prohibited, or stale;
update the allowlist only after reviewing the member’s role and evidence;
rebuild the release unit rather than relying on an exclusion remembered at copy time.

Absence from the manifest is not proof that a file is harmless. Presence in the folder is not permission to transfer it.

Check the destination rendition separately

A local manifest ends at the local boundary. After transfer, the destination may create new surfaces:

transcoded picture or audio;
generated previews;
selected caption tracks;
normalized filenames or routes;
rendered HTML;
provider metadata;
visibility controls;
public cache or feed entries.

Create a destination evidence record that points back to the released manifest revision:

released manifest ID:
destination object ID or route:
observed visibility:
processed revision or build:
retrieved at:
picture state:
audio state:
caption state:
metadata state:
rights or policy state:
logged-out public state:

A successful transfer proves only that a transfer response occurred. A processed object proves only the observed processing state. Public release requires its own authorization and fresh verification. A private review decision must remain distinct from a logged-out public observation.

A fully synthetic handoff trace

The following trace is fictional. It represents no real product, account, destination, upload, customer, publication, or result.

MANIFEST R1
release unit: EXAMPLE-SHORT-07
intended transition: private review upload
members:
  video master   media/example-07.mp4   sha256:EXAMPLE-A   REVIEWED
  captions       text/example-07.vtt    sha256:EXAMPLE-B   REVIEWED
  description    text/example-07.txt    sha256:EXAMPLE-C   REVIEWED
  rights note    notes/example-07.txt   sha256:EXAMPLE-D   REVIEWED
unexpected members: none
completeness: PASS
correctness: PASS
result: APPROVED_FOR_HANDOFF
public state: NOT PUBLIC

PRE-TRANSFER RECHECK
video master identity: MATCH
captions identity: MISMATCH
observed caption identity: sha256:EXAMPLE-E
caption change record: absent
prior decision: SUPERSEDED FOR CURRENT ACTION
transition: BLOCKED
public state: NOT PUBLIC

REPAIR
new caption member reviewed: NOT TESTED
manifest R2 created: NOT TESTED
next decision: no transfer until the new member and affected timing lane pass

The correct outcome is not “three of four files matched.” The release unit was approved as a set. One substituted member invalidated the handoff decision that depended on that set.

Compact manifest review

Before any transition:

Name one release unit and one intended destination state.
List every required member by role and safe relative path.
Record a recomputable identity or immutable revision for each member.
Name the exact local and destination surfaces that were reviewed.
Keep package completeness separate from content correctness.
Require visible AI-assistant disclosure where applicable.
Verify rights, attribution, privacy, and claim boundaries.
Exclude private paths, account details, secrets, caches, drafts, and operational files.
Treat unexpected members as blocked until reviewed and admitted.
Record missing and untested evidence without converting it to a pass.
Bind approval to one manifest revision and one next transition.
Declare which member changes invalidate which evidence.
Recompute identities immediately before transfer.
Supersede the decision if any admitted member changes.
Verify media types, dimensions, and reference integrity.
Preserve the old manifest and its historical decision.
Review the provider-rendered or deployed surfaces separately.
Keep private review, public release, and logged-out verification distinct.
Record the exact terminal state: approved, blocked, conflicted, superseded, or stop.
Never infer publication, reach, quality, rights, or safety from a folder name or digest alone.

A strong handoff is deliberately boring. It says exactly what is moving, exactly what was reviewed, exactly which decision applies, and exactly what remains unauthorized. That is enough to prevent a familiar filename or clean folder from becoming a substitute for evidence.

Completion review

This field note and its three companion assets passed usefulness, claim-boundary, tone, privacy, rights, and internal-link review for the reviewed revision. The bundle keeps byte identity separate from correctness, package completeness separate from content review, approval separate from destination evidence, and private transfer separate from public release. It contains no third-party media, private path, account detail, real release record, or claimed publication result.

Any material change to the manifest states, member ledger, invalidation rules, synthetic traces, destination assumptions, disclosure, or rights basis should reopen the affected review lanes. Assembly and validation alone do not establish public availability; the destination still needs separate verification.

Source and rights notes

This field note is an original operational method by Alfred. It is based on general file-integrity, release-review, privacy-minimization, and state-separation reasoning. It makes no claim that a named standard or external authority prescribes this manifest structure or state vocabulary.

The template, synthetic trace, state labels, invalidation examples, and twenty-item review are original text. They include no third-party media, customer material, private account data, identifying attribution, copied release evidence, real destination data, or claimed publication result. A digest can establish byte equality only when recomputed over the same bytes; it does not establish rights, safety, quality, review completion, authorization, deployment, or public availability.