Thursday Field Note · Annotated teardown
The Quote Looked Current. The Price Was Not.
A before-and-after teardown separates when price evidence was checked from when a customer quote is released, with a five-entry Validity Slip.
Operating question: does this quote still have valid evidence when it leaves the business?
Practical move: separate the source-check time from the customer-send time.
A proposal generated this morning can still make a promise based on last month's price.
This note uses an explicitly synthetic fabrication-shop scenario. An assistant drafts a customer quote from an approved supplier price sheet. The document looks polished, the arithmetic matches the sheet and the customer name is correct. Between drafting and sending, the supplier changes the material price. The draft has not changed; the decision underneath it has.
The problem is not necessarily a fabricated answer. It is an accurate copy of information whose usefulness for this particular promise needs to be checked again.
Where the weak workflow loses time
Here is the plausible weak version, with the missing checks made visible:
- Find: retrieve a price sheet. Missing callout: its effective date, revision and relevant terms do not travel with the extracted amount.
- Draft: calculate and format the proposal. Missing callout: the fresh document timestamp is treated as if it refreshed the source.
- Send: release the saved draft later. Missing callout: nothing asks whether the source or the authorized offer changed while the draft waited.
There are two clocks. One records when the source was checked. The other records when the business is about to make a promise to its customer. Generating new prose only advances the second document's timestamp; it does not move the first check forward.
Technical freshness is narrower than business validity. HTTP caching, for example, compares a stored response's age with a freshness lifetime. RFC 9111 explicitly limits that freshness model to cache operation. A fresh cached response is not a certification that its underlying price is suitable for a new customer commitment.1

Conceptual before-and-after model. Amber shows copied evidence without a validity checkpoint; teal adds a source and terms check before the outgoing promise.
Repair the promise, not just the answer
I would repair the workflow at the point where a draft becomes an offer. The assistant can carry the source reference and its limitations into the draft, but an authorized process must decide whether the business may still use those terms.
After repair: retrieve the applicable source and record its revision and check time; draft with those facts attached; compare the source and offer conditions again before sending; then release, refresh or hold the proposal with an accountable owner. The extra step belongs at the commitment boundary, not merely at the beginning of the conversation.
Explicit validity is a useful software concept too. Stripe's Quote object has an expires_at value describing when an open or draft quote is canceled. That is one provider's documented behavior, not a universal quoting rule and not a claim that an external supplier price automatically updates a quote.2
For the fictional shop, my proposed Validity Slip has five entries:
- Source: which supplier record and revision support this amount?
- Checked: when was that source verified for this specific quote?
- Terms: what scope, exclusions, validity period and approved exceptions apply?
- Change trigger: what new information requires refresh or review before sending?
- Disposition: who may release, revise or hold the customer promise?
Do not invent a standard number of safe hours. A supplier's explicit terms, a negotiated customer arrangement and the business's own approval policy can produce different decisions. If an earlier offer is already binding, a newer supplier price does not by itself authorize changing what the customer was promised. The responsible owner may need commercial or legal advice.

Synthetic tabletop exercise. No real prices, customer promises or measured financial outcomes are represented.
Rehearse a change before sending
Use fictional records to try three cases: the source remains applicable, the supplier issues a relevant revision, and the source has no clear validity information. Let a draft wait between preparation and release. Check whether the workflow notices the difference without silently changing a customer's already approved terms.
Record unnecessary holds as well as missed changes. A process that blocks every proposal is not a useful estimating service. The practical question is whether someone can explain why this particular promise was released, revised or held using evidence that was appropriate at that moment.
This teardown is not a price forecast, a legal opinion or proof that timestamping prevents every quoting error. It does not establish a supplier's actual validity policy. It provides a small repair to try: keep the age of the evidence visible until the business has finished deciding what it is willing to promise.
Research Record
References and Evidence
The practical artifact is my operating interpretation, not a measured customer result, complete security or assurance audit, legal determination or private CPF implementation. Synthetic examples are labeled. Illustrations are original conceptual artwork, not incident screenshots or evidence of real business outcomes.
- RFC 9111: HTTP CachingInternet standard, bounded analogy · IETF; June 2022; section 4.2; accessed November 5, 2026
Freshness compares response age and freshness lifetime and applies to cache operation. It does not certify accuracy of underlying business facts or validity of a customer offer.
- Stripe Quote object: expires_atProvider-specific technical documentation · Stripe API reference; accessed November 5, 2026
Documents expiration for open/draft quotes. Not a universal quote rule, supplier-feed update contract, legal obligation or VerShep connector claim.