Project Delivery & Revisions

Project intake and production readiness

Production begins only after the project scope is accepted, required payment has cleared, and the client has supplied the materials and decisions needed for the first stage. The intake package should identify the business objective, intended audience, desired runtime, preferred structure, mandatory inclusions, prohibited material, delivery deadline, distribution environment, brand requirements, and authorized reviewer.

We may request representative sample files before finalizing a quote. A project marked “ready” based on incomplete or inaccurate information may be returned to intake if the actual footage materially changes the workload. Time spent diagnosing, repairing, relinking, transcoding, or organizing undisclosed issues may require an updated scope.

Only the authorized client contact may give final instructions or approval. The client should identify all reviewers before work begins and consolidate their views internally.

Source-file requirements

Clients must provide complete, readable source media using the agreed transfer method. Files should retain original quality and should not be compressed through messaging applications unless we approve that workflow. Folder names, camera sources, audio sources, dates, takes, and version numbers should be labeled clearly enough for a reasonable editor to understand.

The client should provide all separate audio, logos, fonts, brand guides, lower-third copy, captions or transcripts, licensed music, stock assets, release information, reference videos, and delivery specifications relevant to the project. Passwords should be sent through an approved secure method and not embedded in a public link.

Framevista Edit may flag corrupt, duplicate, incomplete, unreadable, unsupported, visibly damaged, or apparently off-brief files. We do not guarantee recovery of damaged media. If a file can be repaired or converted, that work is included only when stated in the scope.

Production schedule and dependencies

A quoted delivery window assumes timely receipt of all required materials, feedback, access, approvals, and payments. The schedule starts from the later of the stated start date or satisfaction of the final prerequisite. Business-day calculations exclude weekends and U.S. federal holidays unless the written project scope says otherwise.

We arrange projects by production stage and reserved capacity. A client-requested pause or missed feedback date can affect later stages because the original slot may no longer be available. We will provide a revised good-faith estimate when the client returns. Rush work is subject to availability and may carry an additional fee disclosed before work proceeds.

Delivery targets are estimates unless expressly identified as firm in a signed project document. When a deadline is firm, the client must disclose all platform, approval, legal-review, and third-party dependencies that could affect readiness.

Review versions and their permitted use

Review versions are provided so the client can evaluate structure, pacing, content selection, titles, audio, visual consistency, and compliance with the brief. They may include timecode, watermarks, reduced resolution, temporary music, draft graphics, incomplete color work, or other indicators that the file is not a final master.

Review versions must not be publicly distributed, broadcast, submitted as final, used in paid advertising, or delivered to an end customer unless we authorize that use in writing. Publishing a review version can expose draft content, unlicensed placeholders, and incomplete technical work. Framevista Edit is not responsible for issues caused by unauthorized publication of a marked draft.

The client should review the entire version, not only changed areas. An adjustment can affect timing, transitions, captions, music alignment, and export behavior elsewhere in the sequence.

What counts as a revision round

A revision round is one complete and consolidated set of comments submitted in response to a specific review version. The number of included rounds is stated in the accepted project scope. Unless otherwise stated, an included round covers reasonable adjustments within the approved direction, using the existing source materials and deliverable definition.

Comments arriving in separate batches before the next version is delivered may be combined into one round when they are compatible. Comments arriving after implementation has begun, comments that contradict earlier instructions, and new directions from additional reviewers may require another round. We will identify a likely additional charge before performing out-of-scope revision work.

A correction required because Framevista Edit did not implement a clear approved instruction is not counted as a new creative round. A correction to inaccurate client-supplied copy, spelling, dates, credits, or specifications may be treated as a client revision.

Feedback format and review windows

Feedback should be specific, actionable, and time-referenced. For example, identify the timestamp, current content, requested change, replacement asset, and reason when context matters. Statements such as “make it pop” or “fix the flow” should be accompanied by an example or intended outcome so they can be implemented consistently.

The client must consolidate input from all stakeholders and resolve internal contradictions before submission. We may request clarification and pause the affected change until a single direction is provided. Comments should be submitted through the agreed review platform, document, or email thread so the record remains traceable.

Unless the project scope states another period, the client should provide feedback within five business days of each review delivery. If no response is received, the project may be paused. A short review window may apply to rush projects, but it must be disclosed in the scope.

Changes outside the revision allowance

The following commonly require a change order: replacing the approved concept; adding footage after the sequence has been assembled; materially changing the intended runtime; creating new cutdowns, aspect ratios, language versions, or deliverable packages; adding advanced effects or cleanup; re-editing approved sections; rebuilding titles from new brand direction; and exceeding included rounds.

A change order may identify an added fixed fee, hourly rate, new milestone, and revised delivery window. We will not treat a material change as approved solely because a client asks whether it is possible. Work begins after clear authorization under the Payment & Billing Policy.

If a requested change would compromise technical quality, violate a third-party license, create a legal or safety concern, or be impossible with the supplied media, we may propose an alternative or decline that change.

Approval and project acceptance

Approval should be given in writing by the authorized client contact. Instructions such as “approved,” “finalize,” “export,” “send to distribution,” or an equivalent unambiguous statement count as approval of the reviewed stage. Publishing, broadcasting, distributing, or commercially using a review version may also demonstrate acceptance of that version.

Approval confirms that the client has reviewed creative content and factual details, including names, titles, credits, dates, prices, claims, captions, logos, and required notices. We remain responsible for accurately implementing the approved instructions, but the client remains responsible for the correctness and lawfulness of the information it supplied.

After a stage is approved, reopening it may be a scope change. Rights that cannot legally be waived and valid claims for hidden technical corruption are not eliminated by routine creative approval.

Final export specifications

Final deliverables are exported according to the written specification, which may include container, codec, resolution, frame rate, aspect ratio, bitrate or quality target, audio layout, caption format, naming convention, and number of versions. If specifications are not provided, we may use reasonable settings for the stated intended use, but platform requirements remain the client’s responsibility.

Different displays, players, browsers, applications, social networks, and streaming services can change color, loudness, cropping, subtitle appearance, frame interpolation, and compression. A final master that meets the stated export specification is not defective merely because a third-party platform recompresses or displays it differently.

The client should test platform-specific uploads before a launch deadline. Additional re-exports resulting from a platform rule disclosed after final delivery may be billable unless the scope included platform validation.

Delivery method, access, and download

Files may be delivered through a secure download link, approved cloud folder, client-provided platform, or physical media when stated in the scope. The client is responsible for supplying the correct recipients and access permissions. We may refuse to send large or confidential files through an insecure or unapproved channel.

Delivery links may expire. The client must download and independently back up all final files within the communicated access period. If no period is stated, the client should download files within fourteen calendar days. Restoring an expired delivery may be impossible after the retention period and may require a retrieval or re-export fee if the files remain available.

Transfer speed is affected by file size, client connection, geographic location, provider conditions, and local network controls. Delivery occurs when access to the complete file is made available, not when every client recipient finishes downloading.

Final inspection and defect reporting

The client must inspect final files promptly. Unless the project scope states another period, a specific technical defect should be reported within five business days after delivery. The notice should identify the filename, timestamp, device, software, and observable problem and include a screenshot or short sample where useful.

If a final file materially fails to match the agreed technical specification, we will reproduce the issue and, where verified, correct or re-export the affected file within a reasonable period. The client should preserve the original file until the investigation is complete. Altered, renamed, re-encoded, or platform-downloaded copies may not accurately show the condition of the delivered master.

Minor differences caused by calibrated-display variation, third-party compression, unsupported software, or client modification are not defects in the original master. We will nevertheless provide reasonable diagnostic assistance within the project scope.

Project files, timelines, and working assets

Final rendered media is distinct from editable project files. Timelines, bins, proxies, caches, templates, linked assets, software-specific project documents, intermediate renders, unused concepts, and working notes are delivered only when expressly listed in the accepted scope.

Editable files may depend on specific software versions, plugins, fonts, codecs, hardware, licenses, and folder structures. If project-file handoff is included, we will organize and transfer the stated files with reasonable care, but we cannot guarantee compatibility with a different environment or continued availability of third-party dependencies.

Reusable Framevista Edit systems, templates, scripts, workflows, methods, and pre-existing tools are not transferred merely because a project file contains or references them. Third-party licenses may require substitution, flattening, removal, or separate client purchase.

Working-file retention and archive services

Unless a written scope includes archive service, Framevista Edit does not promise permanent storage. Working files, proxies, caches, source copies, and review exports may be removed from active systems beginning thirty calendar days after final delivery or project termination. Final delivery copies may also be removed after sixty calendar days. Technical backups may expire on a separate rotating schedule.

These periods are operational targets, not a guarantee that every file will remain recoverable for the full period. Security events, corruption, provider limits, or other technical circumstances can affect availability. The client’s own backup is the authoritative archive.

If archive preparation is purchased, we will organize and deliver the archive described in the scope. Archive preparation does not include indefinite hosting unless a storage period, capacity, retrieval process, and price are expressly stated.

Paused and inactive projects

If the client does not provide required feedback, assets, access, approval, or payment, the project may be paused. After fourteen consecutive days of inactivity, it may be removed from active scheduling. After thirty consecutive days, we may issue a closeout notice, invoice completed work, and begin the normal retention timeline.

Restarting an inactive project is subject to current availability. We may need to relink media, recreate caches, reinstall dependencies, or repeat technical checks; if so, any restart fee or revised scope will be disclosed before work resumes. Changes in software, licenses, storage, or team availability may prevent exact continuation after a long pause.