Change Order Engine

Agencies often agree a project's scope in a signed statement of work, then field new requests through email, chat, and document comments. A request can be an included revision, an ambiguous interpretation, or genuinely additional work; deciding which is which from memory makes both delivery and billing harder to manage.

Four problems shaped the build

Scope is separated from the work: Deliverables, exclusions, revision limits, rates, and assumptions are written into a contract, while each later request arrives out of context.

A classification without evidence is hard to trust: A confident model can still invent or misquote a clause, leaving an owner without a solid basis for a scope conversation.

Estimating extra work does not produce a consistent price: Hours need to be calculated at the rate agreed for that client, in that client's currency.

The money picture is easy to blur: Work still awaiting a decision, an accepted change order, and work the agency chose to absorb represent different commercial outcomes.

A scope ledger tied to the source contract

An operator creates a client record with its currency and hourly rate, then pastes or uploads the signed statement of work. The SOW is parsed into a ledger of deliverables, inclusions, exclusions, and terms, each associated with its source text. Requests can be entered through a paste flow or the seeded demo inbox; the MVP does not connect directly to Gmail, Slack, WhatsApp, or project-management tools.

Each request is classified as in scope, out of scope, or ambiguous, with a confidence, rationale, estimated hours, and a supporting quote. The quote is checked against the original SOW text after normalizing case, whitespace, and common punctuation. If a quote cannot be found, the interface marks it unverified instead of presenting it as contract evidence. Ambiguous requests stay available for a human decision.

For an out-of-scope request, the system can draft an editable change order with line items and a justification. The model supplies estimated hours; the application applies the hourly rate stored on that client's record. An owner can accept, reject, or absorb the request, and the dashboard keeps recoverable, recovered, and absorbed work separate while grouping money by currency.

The MVP connects a Next.js and TypeScript interface to a Drizzle and libsql data layer, a scope ledger, and a provider interface for deterministic demo classification or Claude structured output when credentials are configured. PDF and DOCX extraction support contract intake, and the triage view links a request back to a checked SOW quote.

The supplied screens use three seeded fictional engagements with 26 example requests and five change orders. Names, messages, currencies, rates, balances, and statuses shown in these demo records are illustrative; they do not represent customer revenue recovered or work measured in a live agency.

The model is not allowed to set prices, and an unverified quotation is not treated as proof. The project includes focused tests for money calculations, tally states, quote verification, and the deterministic provider. No live client results or measured billing recovery are documented.

This remains a single-workspace MVP with no authentication and no direct channel connectors. Requests are pasted or seeded rather than received automatically, and change orders are copied out of the product rather than emailed. Demo-mode SOW parsing is structural, not semantic, and scanned PDFs have no OCR support.

The reusable pattern is to connect every scope decision to its contract source, leave uncertain cases for a person, and price extra work from the client agreement rather than model-generated amounts. The next proof point is using real, permissioned client SOWs and requests to assess quote fidelity, classification quality, and the amount of recoverable work owners choose to bill.