Version and Rights Review

Content files are versioned records linked to a content item. A file has its own version label, attachment, upload date and approving person. The approval workflow resolves the content item and its project before accepting a review decision. It checks the acting reviewer through the person’s linked user identity, the source identity, current revision, lifecycle state and a covering rights agreement.

That makes the decision specific. An approved earlier file is not a blanket approval for a later revision of the same story. When the Reporter replaces a file, the Rights Reviewer should inspect the new revision and its permitted use before the Editor publishes. The workflow also returns the original saved result when the same operation is retried; a changed input for that operation is a conflict.

• Version record. Each attached file keeps its version and upload date with the content item.
• Rights coverage. An agreement records the party, allowed uses, start and end dates, contract and linked content.
• Reviewer identity. The approving person connects to a user identity for the approval check.

Review the allowed use as well as the date range. A current agreement that covers one use should not be treated as permission for an unrelated use. Keep the contract attachment with the agreement so the Rights Reviewer can inspect the source of the permitted use. The Editor can then rely on a named decision for the revision being published.

Define version labels that make the current revision obvious. Decide who may upload a replacement file and who may approve it. Prepare people and user records so reviewers have the right identity link. Enter rights agreements against the specific content item, with start and end dates that cover the intended publication. Agree who checks a revised agreement when an edition moves to a later date.

Use a real piece of content to rehearse a re-upload. The Editor and Rights Reviewer should be able to tell which file was approved and whether its rights still cover the release date. Do not move the story on the strength of an approval for a different revision.

Upload a first revision of a feature and enter its agreement with the permitted print use and dates. Let the Rights Reviewer inspect the file and contract, then approve that revision. Upload a second revision before publication. Check that the team reviews the second file rather than carrying forward the first decision. Try the approval again with the same operation key, then with changed input, and confirm the retry and conflict outcomes are distinct.

Before the Editor publishes, review the agreement once more against the current date and intended use. The publication workflow checks active rights again, so the approval and final release share the same coverage rule.

• Version Log — Inspect each uploaded revision and its approving person.
• Rights Register — Review linked agreements, use terms and dates.
• Content Pipeline — Find approved stories for the Editor’s release decision.

Use rights and approval for the decision and publication for the final release.