How to record a client's decision to launch with a known issue

Some version of this sentence ends a lot of launch calls: "We know about it. We are launching anyway."

It is usually a reasonable sentence. The client has a campaign booked, a budget that closes on Friday, and a finding that costs less than the delay. Accepting a known issue is a decision an authorised owner may make. An agency that refuses to write it down has protected nobody; it has only made itself the sole party with a memory of it.

So write it down. A launch exception record holds what was observed, what it costs, what stands in for a fix, who decided, on what authority, and the date somebody looks again. It is a document the agency writes and the client signs: not a feature of AgencyProof, not a workflow in the app, not a state the scanner tracks. Everything shown here is illustrative.

Reference and date raised

A reference is what lets the finding, the ticket, the exception and the eventual verification refer to the same thing eleven months later, when the people have changed. Use one id everywhere and never renumber.

The date raised is the day the finding was recorded, not the day the client was told or the day the record was typed. Those three dates diverge, and the gap between them is often the most interesting thing in the file.

The finding

Copy the title the report gives it, unedited. The temptation to soften the wording at this line is strong and it is the beginning of every bad record.

×Confirmed

AgencyProof states that "Findings include a confidence and method label." Carry both. A finding observed at runtime and one inferred from a static signal are different objects, and a client accepting the second is accepting something weaker than they think.

The observation

The observation is the raw material: what was requested and what came back. Nothing else belongs here, because it is the only part of the record nobody can argue with later.

Finding LX-04×Confirmed

POST /contact; response 500; visitor input discarded; two attempts, both captured

The product's own boundary is the right sentence to put beside it: "Evidence shows an observation at scan time. It does not establish cause." What a report gives you is that "Each reported issue shows the observation and available evidence captured by that scan." Cause belongs in the fix, not in the record.

Where the evidence is kept

A record that says "see the report" dies with the report. Give the exception its own location: a folder, a path, an attachment the client can open without asking you. If the evidence lives only in a scan result nobody has opened, the record is a promise rather than a document.

Affected journey and consequence

Two lines that clients read and agencies skip. The journey names the visitor path that breaks. The consequence says what that costs, in the client's own terms and without a severity word in it.

Write the consequence as the sentence the client would say to their own board. If you cannot write it, you do not understand the finding well enough to let anyone accept it.

Mitigation in place

What stands in until the fix lands. A phone number above a broken form, a monitored mailbox, a temporary redirect, a page taken out of the navigation.

Mitigation distinguishes a considered exception from a shrug. It is also the field that most often reveals the finding was cheaper to fix than to work around.

The decision and its owner

Record the decision in the words the owner used, and record it beside the finding rather than in place of it.

◆Intentional

The record now carries two labels, this one and the confirmed defect from three fields earlier, because the second does not erase the first. Note also that the engine reserves intentional_choice for a control working as designed (src/lib/types.ts:81-94), which an accepted defect is not. Your record is claiming a decision, not reclassifying an observation.

The same discipline sits inside the product's own report machinery, an internal operator surface rather than a customer workflow. A correction there is a new revision that "PRESERVES the original value" instead of an in place overwrite, an adjudication of a single finding is "Structurally never-harsher", and a customer dispute is scoped to one finding and actioned by an operator (src/lib/services/review-gate.ts:1-21, :205-215). Nothing there lets a later judgment rewrite what was first observed.

The owner is a person with a name and a role. Not a company, not a team, not an address that forwards to four people.

Basis of authority

One line explaining why that person may accept this on behalf of the organisation: the role, the clause in the scope, the delegation they hold.

Agencies find this field awkward and later find it useful. It also inherits a constraint from how people read anything they sign. Usability research on policy pages reports that only a fraction of the words are read at all, and recommends plain language over completeness. A record nobody reads has recorded nothing. Keep every field to one line.

Verification plan, verification date and status

The plan says what will be checked and how, in terms that let somebody who was not in the room repeat it. The date says when.

Write it as a calendar date, not a period. RFC 3339 exists because "Date and time formats cause a lot of confusion and interoperability problems", and it separates a timestamp anchored to UTC from one whose local offset is unknown. "Next month" carries the same defect at project scale: it is a date nobody can be late for. 2026-08-05 is a date somebody can be late for.

LX-04 · raised 2026-07-22

Finding: contact form returns a server error on submit. Confirmed defect, observed at runtime.

Observation: two submissions to the contact endpoint returned a server error with the visitor's input discarded; both responses captured and stored with this record.

Affected journey: enquiry, the only lead path. Consequence if unresolved: enquiries are lost and the visitor is not told.

Mitigation in place: a monitored phone number sits above the form until the handler is replaced.

Decision: launch with the form live. Accepted by FULL NAME, Marketing Director, under the authority clause in the project scope. The finding is not resolved.

Verification: resubmit and confirm delivery on 2026-08-05. Status: open.

That date is the point of the document, and the reason this record belongs to the same discipline as the recurring check that follows launch. On the day, one of two things happens. Either somebody runs the plan and the record closes with a second observation beside the first, or nobody does and it stays open with a date that has passed, which is itself a finding.

Both are better than the third outcome, which is a record that quietly became true because nobody looked.