Field note
Decide what blocks a launch before the findings arrive
Every launch argument is the same argument: is this a blocker or a note? Held after the findings land, that conversation is a negotiation. Held before, it is a policy. Here are the six questions that turn a label into a decision, and who answers each one.
A row on the screen says the contact form returned a server error, and the label beside it reads critical. The developer says the scan hit a rate limit and the form works. The account manager says a client cannot open a new site with a contact form nobody can trust. Same row, and neither of them has said anything about evidence yet.
That argument runs on every project and is usually settled by whoever is more senior or more tired. The way out is not a better label. It is agreeing what blocker means here, before any findings exist. Everything below is illustrative rather than reported.
AgencyProof derives its launch tier from severity: critical becomes a
launch_blocker, high and medium should_fix, low and enhancement
post_launch (src/lib/audit/classify.ts:39-53). The comment above it
records the looser rule that came before: promoting every high finding to
blocker "inflated blocker counts" and made the held verdict "cry wolf"
(classify.ts:9-17). The canonical account of severity is equally blunt:
"severity ratings from a single evaluator are too unreliable to be trusted."
A scanner is one evaluator.
The product's own claim is narrow, and worth quoting exactly. AgencyProof
produces an "AgencyProof Launch Readiness Score and a rules-based Hold,
Conditionally ready, or Ready verdict." The third label carries a
qualification wherever it appears: "Ready under the AgencyProof scoring model
as of the scan timestamp." The limit is stated plainly: "Ready" is the result
of the AgencyProof scoring model for the site as observed at scan time, not a
guarantee of business, legal, security or launch outcomes. An open launch
blocker holds the verdict at Hold however high the score climbs
(src/lib/audit/verdict.ts:1-27).
So the definition of blocker belongs to people. The six questions below are this publication's editorial framework, not a product feature.
| Factor | The question | Answer that makes it a blocker | Answer that makes it a note | Evidence required |
|---|---|---|---|---|
| Evidence | How completely was this observed? | Directly observed, sufficient alone | Inferred, or the probe was blocked | Request and response, captured |
| Affected journey | What the client sells breaks? | Enquiry, booking, purchase | A route no visitor reaches | The path, walked by a person |
| Exposure | Who meets it, and how soon? | Every visitor, from hour one | Authenticated, or linked from inside | Inbound links, indexability |
| Reversibility | What does undoing it cost? | A release, migration or correction | An edit anyone with access can make | Who deploys, how fast |
| Ownership | Who can change the condition? | Nobody named, or nobody agreed | A named person, dated task | Name, discipline, date |
| Consequence | What does shipping it cost? | Revenue, an untrue statement, misrouted data | Untidiness nobody notices | One sentence the client would use |
What evidence do we actually have?
Severity is a property of the label. Disposition is a property of the finding,
and the engine keeps them apart on purpose. The comment on the disposition
type puts the split in one line: verification_status answers "how confirmed
is the observation?", while disposition answers "is this actually a defect
for THIS org?" (src/lib/types.ts:74-80).
Three findings can carry the same severity and belong in those three places.
The pipeline makes the first hard to reach: a detector must propose it, and
the finalizer falls back to needs_confirmation under a comment reading
"NEVER a defect from provenance alone" (src/lib/audit/classify.ts:414-431).
Validation may only move a disposition down the defect scale, and a
confirmed_defect survives only where the evidence contract came back
complete (classify.ts:433-487, src/lib/types.ts:157-161).
Borrow the discipline, not the machinery. When the answer to what was observed is a captured request and its response, you have evidence. When it is a static signal standing in for behaviour nobody watched, you have a question wearing a red label.
Which journey does it break?
A finding without a journey attached is a fact about a page. With a journey
attached it is a fact about the business, and only the second kind holds a
launch. The product's high band is defined by that test: it "Moves revenue,
trust, or launch readiness directly" (src/lib/constants.ts:375).
The client is the only reliable source, and the question is smaller than it sounds. Not "is this page important" but "if this stopped working on Monday, what would the business notice by Friday".
Who is exposed if it ships?
This factor is usually answered by how alarming a finding looks. A refused administrative route reads like a fire. Most of the time it is a door working.
GET /admin HTTP/1.1; response 403 Forbidden; anonymous request, no authenticated session attemptedEstablishesAn anonymous request to that route was refused by the origin server.
Does not establishWhether an authorised user can reach the page, and whether the resource exists at all.
Illustrative capture.
The two codes an automated check reads most confidently are both permitted to mean other than they appear. RFC 9110 defines 403 as a server that "understood the request but refuses to authorize it", adding that an origin server wishing to hide a forbidden resource "MAY instead respond with a 404 (Not Found) status code". The 404 definition carries the same escape hatch: the server "did not find a current representation for the target resource or is not willing to disclose that one exists."
Which is this test's honest limit from outside. It can say who is exposed anonymously, not whether an authorised person completes the journey. Until someone with an account walks the rest, the exposure row is an estimate and belongs in the record as one.
Can this be undone after launch?
Reversibility has no counterpart in the engine and should not have one. It is a fact about your release process, not about the site, and the distinction is between a thing you edit and a thing you retract. A wrong price in a content block is an edit. A wrong price a visitor acted on is a conversation. An email that fired because a form pointed at the wrong list has left the building.
Who owns the fix?
Two questions hide inside ownership, and the engine separates them because
conflating them produces tasks nobody can do. Controllability records who
can realistically change the condition, across customer_controlled,
developer_controlled, platform_controlled and third_party_controlled,
warning against handing a customer "a task their platform won't allow"
(src/lib/types.ts:146-155). ActionRequirement records what is asked for,
including confirm, an item that "deducts nothing but still asks for a
runtime check" (src/lib/types.ts:116-125).
An unowned finding is not a note. It is a blocker with the argument still in front of it, because the first thing anyone does next meeting is rediscover it.
Contact form returns a server error on submit
FILED ON · /contact
Illustrative. Two submissions returned a server error with the typed message discarded; both responses captured. Journey: enquiry, the only lead path. Reversible: no, the handler ships with the release. Owner: named developer, dated.
What does it cost if we ship it anyway?
The last question is the one clients answer best and agencies ask least. It asks what the finding costs in the currency the client keeps score in. Sometimes they accept that cost, which produces a different document: a launch exception record stating what was observed and what was decided, without pretending the finding was resolved.
| Finding | Evidence | Journey | Exposure | Reversible | Owner | Call |
|---|---|---|---|---|---|---|
| Contact form returns a server error | Two responses captured | Enquiry, the only lead path | Every visitor, hour one | No | Developer, dated | Confirmed blocker |
/admin returns 403 anonymously | No authorised attempt | None a visitor uses | Nobody outside the team | Not applicable | None needed | Intentional control |
| Page states an award we have not seen | Copy captured, no document | Credibility, converting page | Every reader | Yes, an edit | Client marketing lead | Needs confirmation |
| Retired campaign URL returns 404 | Link live in an email footer | Return visits, paid campaign | Anyone holding the link | Yes, a redirect | Developer, dated | Scheduled correction |
| Analytics request precedes the notice | Load order, fixture capture | Every page view | All visitors | Yes, configuration | Client, decision recorded | Accepted exception |
One severity label sits behind several of those rows and they end in five different calls. Nothing past the second column comes from a scan.
Put the test in the scope document, where the client signs it:
A finding holds the launch when the evidence is complete, it breaks a journey the client sells, and undoing it after release costs more than fixing it now. Everything else ships with a named owner and a date.
Both halves are load bearing. The first is what you will stop for. The second is the promise that everything you did not stop for is still somebody's job on Monday.
Provenance
- Written by
- Balaji PonnambalamFounder, AgencyProof
- Technical review
- Written and self-reviewed against the codebaseAgencyProof is a one-person engineering team; there is no second reviewer to claim.
- Published
- Evidence basis
- Examples are illustrative and are labelled where they appear.
Every product claim in an article is checked against the AgencyProof source tree before publication, and traced to the code path that implements it. Where the article describes a method rather than a shipped behaviour, it says which it is.
Related reading
Agency Field NotesHow to record a client's decision to launch with a known issue
Sometimes the authorised owner ships with a known issue. Record the evidence, the consequence and the check date.
Audit LabHow to report a Lighthouse score without overstating it
A Lighthouse score is one lab result under one device profile and network setting. Report it with those conditions.
Launch ManualWhat to inspect before sending a website to the client
The best time to find a defect is before the client's attention shifts from the design to the mistake. A one-hour inspection for the first “finished” link.