Appearance
LT Work statuses
needs verificationAn LT Work is the video project you create in the mobile app. Its status tells you how far it has progressed and whether someone needs to act. This guide covers Publication and Profile Video, the two types created in the app. Publication Plus follows a separate editorial process.
Look for the status on the work in your Workspace, then open the work to see its details and available actions. The labels below match the current app and backend definitions. Your build may use updated wording.
About the status reference
This guide was checked against the team’s Whimsical status board, including its status definitions, actions, notifications and two flow diagrams, on 10 September 2026. The board describes the intended product journey. Where current app behavior differs, this page explains the difference. You do not need access to Whimsical or the code to use this guide.
The usual journey
The creator prepares the recordings, the system processes them, and the researcher checks the finished video. When a coordinator creates the work, the subject researcher also approves it before processing starts.
The final arrow represents the publication action in lt-core. Automatic delivery to the public website is still being verified. Publishing... means the researcher has confirmed the video; it does not mean a public page already exists.
Preparing the work
These statuses belong to the Draft stage. The creator is the researcher recording their own work or the coordinator preparing it on their behalf.
| Status in the app | What it means | What happens next |
|---|---|---|
| New Draft | The work has been created, but content preparation has not started. | The creator continues the work and adds its content. |
| In Progress | Some preparation has started, but the work is not ready to submit. | Complete the missing recordings, cover and other requirements shown in the work. |
| Ready to Submit | The normal draft meets its readiness requirements. It has not been submitted yet. | The creator reviews it and submits. |
| Review Required | The work has returned to preparation for another recording attempt after a processing problem. | Review what needs attention, record again and resubmit once the requirements are met. |
| Revision Wanted | The researcher declined the finished video at the final review and wants changes. | Revise the work and submit it for processing again. |
For a Publication, preparation includes source papers, all required chapter recordings and a cover. A Profile Video does not require source papers. Researcher-created works also require a linked Open Researcher and Contributor ID (ORCID) account. Coordinator-created works currently have a different identity requirement; see ORCID and identity proof.
Review Required and Revision Wanted describe why a draft is being revised. They can remain visible while its content is being completed. Do not expect every revision to change back to In Progress or Ready to Submit before resubmitting.
Follow the video creation walkthrough for the recording steps.
Submitted and being processed
These statuses belong to the Submitted stage.
| Status in the app | What it means | Who acts next |
|---|---|---|
| Needs Approval | A coordinator submitted a work about a researcher. Processing is waiting for that researcher's approval. | The subject researcher approves the work. An invited researcher without an account can receive an emailed approval link. |
| Processing Video... | The Media Processing Engine (MPE) is preparing the playable video from the recordings. | The system processes the work. The creator can view its progress. |
| Processing Issue | Processing failed, so there is no successful finished video ready for final confirmation. | Open the work and review the reported problem. The researcher can choose Record Again to return to preparation. |
The coordinator's submission and the researcher's approval are different actions. A coordinator cannot replace the subject researcher's final confirmation. The complete mobile experience for coordinator-led approval still needs verification across builds.
Processing has no verified completion-time promise in this guide. If a work stays at the same processing status unexpectedly, ask the team for help and include the work title and status. Do not assume that a phone notification will arrive; push notifications remain an open implementation gap.
Reviewing and publishing
These statuses belong to the Approved and Published stages.
| Status in the app | What it means | Who acts next |
|---|---|---|
| Ready for Publishing | Processing succeeded and the finished video is ready for the researcher's final review. | The subject researcher uses Review & Publish, watches the result and confirms it or requests revision. |
| Publishing... | The researcher has confirmed the finished video. Publication itself is still pending. | The publication process must complete. The production trigger and automatic website handoff remain under verification. |
| Published | lt-core has recorded the work as published and fixed its publication attribution. | Check the actual public page when its link is available. A backend status alone does not verify that the website handoff has completed. |
The word Approved is the name of a stage. It does not mean an LT editor has manually reviewed the video. Human editorial review is disabled in the current minimum viable product (MVP); successful processing makes the work eligible for the researcher's final check.
Final confirmation requires the subject to have a real researcher account. Someone who initially approved through an invitation link must have their account resolved before this final step. Coordinator-created work also depends on an active researcher connection.
For a Publication, the intended outcome is a public video page on lt.org with a digital object identifier (DOI). Automatic DOI registration and public links returned to the app are still incomplete. Profile Video is not DOI eligible. Read how a video gets published and DOIs for the current limits.
When a video needs another attempt
Record Again after a processing failure clears the current chapter recordings from the active work, so the next attempt needs new recordings. Processing history is retained separately. A revision requested at final review returns the work to Draft and resets the processing outcome; the requirements are checked again on submission.
Canceling, restoring and deleting
These statuses belong to the Archived stage.
| Status in the app | What it means | Available next step |
|---|---|---|
| Canceled | An eligible unpublished work has been set aside. | Use Restore to resume it, or request deletion if it is no longer needed. |
| Deleting... | Deletion has been requested for a canceled work. | The work is no longer a normal editable draft. This label does not prove physical cleanup has already finished. |
Cancellation is available for drafts, Processing Issue and Ready for Publishing. It is not the normal action while approval or processing is pending, after confirmation, or for a published work.
Restoring a draft recalculates its status from the saved content and revision information. Restoring a work that had a processing issue returns it for revision. Restoring a work awaiting final confirmation returns it to that review step.
The Whimsical design calls for automatic deletion of canceled works after 30 days. The app currently contains Deleting in 30 days text, but a real countdown and automatic deletion deadline are not verified. Do not rely on that text as a retention guarantee. Published videos are retained and cannot use this draft cancellation and deletion route.
Where the Whimsical design and current app differ
The board includes 17 status definitions. The current app and backend define 13. Four design statuses, Upload Failed, Uploading..., Featured and Unpublished, are not separate implemented statuses today. Some labels and actions also differ:
| Older wording or concept | How to read it today |
|---|---|
| New Project | The current label is New Draft. |
| Uploading... and Upload Failed | Upload activity can affect preparation, but these are not current standalone LT Work statuses. |
| Awaiting Approval for a coordinator | The current shared fallback label is Needs Approval. Role-specific wording needs verification. |
| Featured | Not a current separate LT Work status. |
| Unpublished | Not a current separate LT Work status or an implemented public unpublish workflow. |
| Removing project... | The current label is Deleting..., which marks a deletion request rather than proof of completed cleanup. |
The board also describes behavior that needs product and implementation reconciliation:
| Design in Whimsical | Current behavior and what to rely on |
|---|---|
| LT review can request changes. | Human editorial review is disabled. Record Again after processing failure is an implemented route to Review Required. |
| Coordinators can approve or reject at final confirmation in the actions table. | Final confirmation is restricted to the subject researcher. |
| Cancel while awaiting researcher approval; some diagram arrows also cancel published work. | The implemented cancellation action allows drafts, processing failures and works awaiting final confirmation. Published work is excluded. |
| Canceled work is deleted automatically after 30 days. | This is a design requirement. The displayed countdown is static, and automatic expiry is not verified. |
| Canceled work offers Create new and View in the actions table. | The app also implements Restore, with the return paths shown above. |
| Admin deletion arrows leave published states. | Current published videos are retained; the implemented work-deletion route starts from a canceled unpublished work. |
| Email and in-app notifications announce submission, approval, revisions and publication. | Treat this as the notification design, not a guarantee that all messages are delivered today. Check the work in Workspace. |
The board contains both Flow Diagram v1 and Flow Diagram v2, and their actions are not identical. The team needs to confirm the intended revision and reconcile these differences. See the open questions.
For maintainers: source references
These references require repository access. The reader-facing explanations above are self-contained.
- Current mobile status labels and actions and presentation.
- Status enum and status calculation and readiness.
- Submit requirements, processing results and Record Again.
- Final confirmation and decline and publication.
- Cancel, restore and delete.
- Saved business status definitions and curated lifecycle specification. These preserve business intent but differ from the current implementation as described above.