DFY Revisions Policy

1. Purpose

This policy explains how Levqor handles corrections, revisions, and scope changes for Done-For-You engagements.

The governing principle is simple: if delivered work does not match the accepted scope boundary, it enters correction handling. If a requested change goes beyond the accepted boundary, it is treated as new work.

2. Commercial Structure Covered by This Policy

Fixed-Scope Delivery

Premium Delivery

3. What Counts as an In-Scope Correction

An in-scope correction is a change required because the delivered work does not match the accepted scope boundary.

• Delivered behavior differs from the agreed bounded implementation
• A defined integration or flow in the accepted scope is not functioning as delivered
• Documentation, handoff notes, or proof-backed outputs materially fail to reflect the delivered scope
• A bounded implementation detail needs correction to match what was actually agreed

4. What Does Not Count as an In-Scope Correction

The following are treated as scope changes, not included corrections:

• New features not included in the accepted engagement
• Additional workflows, systems, or integrations beyond the accepted boundary
• Replacing the chosen solution with a materially different architecture
• Extending the engagement into broader consulting, redesign, or transformation work
• Changes caused by new customer requirements after scope acceptance

5. Revision and Correction Handling by Package

6. Correction Process

6.1 Delivery

• Levqor delivers the bounded engagement and any associated handoff materials
• You review the delivered work within the stated review window

6.2 Correction Request

• Submit a clear request describing where the delivered work does not match the accepted scope
• Provide relevant evidence, examples, screenshots, or error context where useful

6.3 Scope Decision

• Levqor determines whether the request is in-scope correction or out-of-scope change
• If it is in scope, it enters correction handling
• If it is out of scope, it may be quoted separately, re-scoped, or declined

6.4 Resolution

• In-scope corrections are resolved against the accepted boundary
• When the delivered work matches the agreed scope, the engagement can be marked complete

7. Review Window and Support Boundary

Each engagement includes a defined review window after delivery. During that period, you may raise bounded correction requests where the delivered work does not match the accepted scope.

8. Refund Handling

If Levqor fails to deliver work that matches the accepted scope boundary, refund handling follows the governing contract and refund policy.

• Correction is attempted where appropriate
• If the scope is not met, refund or partial refund handling may apply under the governing terms
• Refund handling depends on engagement state, work completed, and the specific mismatch against the accepted boundary

See the Refund & Cancellation Policy and DFY Services Addendum.

9. Best Practice for Customers

• Keep the original agreed scope boundary visible and referenced
• Raise correction requests clearly and specifically
• Separate real scope mismatch from new desired features
• Provide timely feedback during the review window