One Derivation, Every Artifact: How the Quote System Prices Work
The second engineering case study. A quote, an agreement, a payment, and a project plan — all derived from one set of answers by named rules, and what the arrangement costs to maintain.
A customer completes an intake questionnaire once. That record goes on to produce a price, a delivery estimate, a justification for every line, a signed agreement, and — once the payment clears — a provisioned project with an onboarding plan.
Language models take part throughout, and none of them can set a rate. That constraint is not a prompt instruction. The price is computed and persisted before the model is called and enforced back over its reply afterwards, and on the negotiation path the changes it proposes are filtered server-side before any of them are applied.
The property worth arguing for is that nothing is authored twice. The delivery estimate is derived from the same component list that produced the price. The contract renders the same sentences the review screen showed. The project plan is gated by the same answers again. A system built that way cannot quote one thing and deliver another, because there is no second place the second thing could have been written.
Thirteen pages, four diagrams, code from the running system, and a section on what the design costs. Read it in the browser, or take the print edition.
One intake record, seven stages. Five customer-visible artifacts, each produced by a named rule reading that record rather than by a separate authoring step.
Explicit selection outranks the computed baseline, and the baseline outranks the model draft. Enforced as one pass in one direction, before the reply is ever trusted.
Storage and hosting capacity resolve against what the intake proves, not only what the customer estimated. “Unsure” is a supported answer rather than a hole.
Each rule records the verbatim answers it read, the requirement it derived, and its own name — including the charges it deliberately suppressed.
A tablet point of sale with signature, location, and terms written as evidence before the card is charged. A decline leaves the evidence and creates nothing else.
Cleared funds create the project. Its onboarding plan is gated by the same answers that priced it, and the agreement snapshot is frozen apart from what is billed now.
Four unrelated situations across two platforms resolve the same way: the record is never written optimistically and reconciled afterwards.
Where the architecture is slow, fragile, or unfinished — the six-file edit cost per service, the untested combinations, and the one guarantee that is procedural rather than structural.
The site crawler was built here as a sales instrument and carried into the receptionist platform unchanged, because it answered a question about a website rather than serving a quoting tool.
One Derivation, Every Artifact
A customer completes an intake questionnaire once. The price, the delivery estimate, the justification for each line, the agreement, the payment record, and the project’s onboarding plan all derive from that one set of answers.
Companion piece to Two Systems, One Caller, which covers the AI receptionist platform. Code excerpts in both documents are taken from the running system.